The Build Is the Easy Part: Our 10-Step App Store Release Checklist

Getting a build to compile is the part of a release everyone plans for. What stalls a release is usually everything around it: the new age rating questions, the encryption question, a privacy label that has to cover every SDK in the app, a demo account for the reviewer. You touch most of these a few times a year, which is how they get missed.

We make ShipHappens, the Mac app we use to lay out screenshots, translate listings and send them to App Store Connect for our nine apps. This is the checklist around it: ten steps from a build to a live version, after a one-time setup. Every requirement comes from Apple’s own pages, checked on September 25, 2026. Three of the rules took effect this year, so compare the dates with your last release.

The App Store submission checklist at a glance

Step	What to check
1. Build	Xcode 26 SDKs, iOS 13 or later, a new build number, a privacy manifest
2. Encryption	ITSAppUsesNonExemptEncryption, plus documents if needed
3. TestFlight	Upload, processing, testing on devices
4. Product page	Name, subtitle, description, keywords, What’s New, URLs, copyright
5. Screenshots	1 to 10 per required display size
6. Privacy	Policy URL, App Privacy answers, tracking, account deletion
7. Age rating	The updated questionnaire
8. In-app purchases	The first of each type ships with a version
9. Review information	Contact, demo account, notes
10. Submit	Build, release option, phased release

Before your first release: the one-time setup

Agreements. Free apps only need the Apple Developer Program. To sell an app or offer In-App Purchases, the Account Holder must sign the Paid Apps Agreement, and when Apple updates it, you can’t create a new app or In-App Purchase until the new version is accepted.

EU trader status. Under the Digital Services Act, every developer has to declare whether they’re a trader, even without EU distribution; making money from the app and being registered for VAT point toward yes. Traders verify their contact details with two-factor codes and a business document, and those details appear on their EU product pages. Since February 17, 2025, apps without a trader status have been removed from the EU App Store until one is verified.

The app record. The bundle ID must match your Xcode project and locks once you upload a build; the SKU can’t be changed at all. Apps available in the EU, the UK or the US with Health & Fitness or Medical as a category also need a regulated medical device declaration.

Step 1: Build with the current SDK

As of September 2026, Apple’s upcoming requirements page lists these rules for uploads:

• Since April 28, 2026: apps must be built with Xcode 26 or later, using the iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK. macOS isn’t on that list.
• Since September 9, 2026: iOS and iPadOS apps must target iOS 13 or later.
• Since February 18, 2025: no file inside a Mac app may carry the com.apple.quarantine attribute.
• Since May 1, 2024: apps need approved reasons for certain APIs, including ones called by third-party SDKs.

Those reasons go in a privacy manifest, a file named PrivacyInfo.xcprivacy. “Required reason” APIs are ones that could be misused to fingerprint a device, and on iOS, iPadOS, tvOS, visionOS and watchOS, App Store Connect won’t accept an app that uses one without an approved reason. Each SDK declares its own calls in its own manifest. The categories include user defaults, file timestamps and disk space, so an app that keeps its settings in UserDefaults needs this entry, where CA92.1 is the reason for data only the app itself can read and write:

<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array>
      <string>CA92.1</string>
    </array>
  </dict>
</array>

Also bump the build number on every upload, since the build string identifies each build, and give any API that accesses sensitive user data a purpose string in the Info.plist, which Apple requires of every app that accesses user data.

Step 2: Settle export compliance

Builds upload to a server in the United States, so an app distributed outside the US and Canada falls under US export rules wherever its developer is based, and using encryption counts as exporting it. For most apps the answer is one Info.plist key. Set ITSAppUsesNonExemptEncryption to NO if the app and its third-party libraries use no encryption or only exempt encryption, such as HTTPS through URLSession, which is built into the operating system. Without the key, App Store Connect asks the export compliance questions every time you upload a new version.

If you do need documents, Apple’s table sets out which:

Your app’s encryption	Documents in App Store Connect
Only what’s built into Apple’s operating systems	None
A standard algorithm the operating system doesn’t provide	A French encryption declaration, if you distribute in France
A proprietary algorithm that standards bodies such as the IETF haven’t accepted	A US classification (CCATS), plus the French declaration for France

Once Apple approves them, you get a code for the ITSEncryptionExportComplianceCode key. Apple also notes that exempt encryption can still require a year-end self-classification report to the US government. If you’re unsure which row applies, ask an export lawyer.

Step 3: Upload and test in TestFlight

Upload with Xcode, Transporter, altool or the App Store Connect API; Apple emails you when the build has processed. TestFlight takes up to 100 internal testers from your App Store Connect team and up to 10,000 external testers. The first build you add to an external group goes to App Review, later ones may not need a full review, and each build can be tested for 90 days.

Test on real devices running the latest OS. On Apple’s figures, more than 40% of unresolved review issues fall under guideline 2.1, App Completeness: crashes, placeholder content and incomplete information.

Step 4: Write the product page

Most of the listing is text with hard limits, set out in Apple’s platform version and app information references:

Field	Limit	Worth knowing
Name	2 to 30 characters	After the first submission, it changes only with a new version
Subtitle	30 characters
Promotional text	170 characters	Editable without a new submission
Description	4,000 characters	Plain text, no HTML
Keywords	100 bytes	Each keyword over two characters; don’t repeat your app or company name
What’s New	4,000 characters	Not on a first version; required on every version after
Support URL	Required	Must lead to real contact details
Marketing URL	Optional
Copyright	Required	The year and the rights holder; Apple adds the ©

Three guidelines to check every release: no trademarked terms, popular app names or prices packed into metadata (2.3.7); screenshots, previews and icons fit for 4+ even if the app is rated higher (2.3.8); and a What’s New that names significant changes, as only simple fixes can get a generic line (2.3.12). Our guides to App Store keywords and localizing your listing go further.

Step 5: Add screenshots and previews

Upload one to 10 screenshots per display size, as JPEG or PNG without transparency. iPhone apps need a 6.9-inch set, or a 6.5-inch set if there’s no 6.9-inch one. iPad apps need a 13-inch set, and Mac apps need Mac screenshots. Smaller displays get scaled-down copies. App previews are optional, up to three per localization and device size.

Screenshots must show the app in use, not just title art, a login page or a splash screen (2.3.3), and Apple asks that they match the device type they’re uploaded for. Our screenshot sizes reference lists every accepted size.

Step 6: Update your privacy details

A privacy policy, in two places. Every app needs a privacy policy URL in App Store Connect and an easy-to-find link inside the app (5.1.1(i)). It must say what the app collects, how and why, confirm that anyone you share data with protects it equally, and explain retention, deletion and withdrawing consent.

The App Privacy answers. These build your privacy label and are required for new apps and updates. They cover your code and your third-party partners, such as analytics tools, ad networks and other SDKs. “Collect” means sending data off the device and keeping it longer than it takes to serve the request. Recheck the answers whenever you add an SDK; guideline 2.3 asks you to keep privacy information current.

Tracking and AI. Linking your app’s data with other companies’ data for targeted ads or ad measurement, or sharing it with a data broker, is tracking, and it needs explicit permission through the App Tracking Transparency APIs (5.1.2(i)). The same guideline requires you to disclose where personal data is shared with third parties, including third-party AI, and to get explicit permission first.

Account deletion. If people can create an account in your app, they must be able to start deleting it inside the app. Deactivation alone isn’t enough, automatically created guest accounts count, and apps using Sign in with Apple should revoke the user’s tokens through its REST API.

Step 7: Answer the new age rating questions

Apple moved every app to a new age rating system and asked developers to answer its updated questions by January 31, 2026 to avoid an interruption when submitting updates. The ratings are now 4+, 9+, 13+, 16+ and 18+, calculated from what you declare about your app’s content, in-app controls and capabilities, and an app that comes out Unrated can’t be published on the App Store. Some features land higher than you might expect. In Apple’s base ratings, used wherever a region doesn’t add its own:

If your app includes	Lowest possible rating
Ads, user-generated content, or messaging and chat	4+
Health or wellness topics, such as calorie tracking or exercise recommendations	9+
Social media features	13+
Unrestricted web access, such as a built-in browser	16+
Gambling with real money	18+

Answer honestly: guideline 2.3.6 warns that a mis-rated app can surprise customers or draw an inquiry from regulators. And choosing Made for Kids can’t be undone once App Review approves the app.

Step 8: Attach in-app purchases

The first In-App Purchase of each type (consumable, non-consumable, auto-renewable subscription or non-renewing subscription) must be submitted with a new app version, and a new subscription goes in with its subscription group. After that, more of the same type can go on their own. Guideline 2.1(b) asks that every purchase be complete, visible to the reviewer and working; if one can’t be found in the app, explain why in your review notes.

Step 9: Fill in the App Review information

This part of the version page is for the reviewer only:

• Contact. A name, email address and phone number. The phone must be in international format with a plus sign, such as +852 for Hong Kong; digits alone are refused.
• Sign-in. If the app needs a login, a demo username and password that won’t expire. Guideline 2.1(a) adds: turn on your back-end service. If legal or security reasons rule out a demo account, a built-in demo mode is allowed with Apple’s prior approval.
• Notes. Up to 4,000 bytes, in any language. Describe new features specifically, because generic descriptions will be rejected (2.3.1(a)). If a feature needs special hardware or a hard-to-recreate setup, be ready with a demo video or the hardware.

Step 10: Choose the build and release option, then submit

Release option. Release the version yourself after approval, automatically as soon as it’s approved, or automatically but no earlier than a date you set.

Phased release. An update to an iOS, macOS or tvOS app can be released in phases over 7 days, to a random sample of people with automatic updates turned on:

Day	1	2	3	4	5	6	7
Share of users	1%	2%	5%	10%	20%	50%	100%

Anyone can still download it manually. You can pause for up to 30 days in total, or switch to Release to All Users at any point.

Submit. Check the right build is attached in the version’s Build section, click Add for Review (the status becomes Ready for Review), then open the draft submission and click Submit for Review. Anything else in the same submission, such as an In-App Event, must also be accepted for it to complete.

After you submit

On average, 90% of submissions are reviewed in less than 24 hours, and Apple emails you at each status change; incomplete submissions take longer or fail. With a manual release, an approved version waits in Pending Developer Release until you click Release This Version, and it can take up to 24 hours to appear on the App Store after that.

If the review fails, App Store Connect shows which guidelines the submission didn’t meet, and you can reply to App Review there before resubmitting. You can file one appeal per submission with the App Review Board, and ask for an expedited review for a critical bug fix or a release tied to an event. Our guide to App Store rejection reasons covers the common ones.

App Store submission FAQ

How long does App Store review take?

Apple says 90% of submissions are reviewed in under 24 hours on average. The first build you send to external TestFlight testers is reviewed too, so allow for both before a launch.

Do I need a privacy policy if my app collects no data?

Yes. Every app needs a privacy policy link in App Store Connect and inside the app. If you collect nothing, the policy can say exactly that.

What is export compliance for an iOS app?

US export law applied to the encryption in your app. Most apps only use the operating system’s own encryption, such as HTTPS, and settle it with one Info.plist key, ITSAppUsesNonExemptEncryption, set to NO.

How we made this

We checked every requirement against Apple’s own pages on September 25, 2026, including App Store Connect Help, the App Review Guidelines (last updated June 8, 2026) and the Upcoming Requirements page, and quote limits as Apple states them. The order of the steps is ours. The ShipHappens details come from its source code: it handles most of steps 4 and 5 for us, creating the version in App Store Connect if needed and uploading each locale’s name, subtitle, keywords, description, What’s New and screenshots through Apple’s App Store Connect API, and it won’t touch a version that’s waiting for review, in review or already approved. The rest of this list happens outside it. The photos are from Wikimedia Commons.

References

• Apple Developer: Upcoming Requirements; App Review Guidelines, last updated June 8, 2026; App Review; App privacy details on the App Store; Offering account deletion in your app.
• App Store Connect Help: Sign and update agreements; Manage European Union Digital Services Act trader requirements; App information; Platform version information; Screenshot specifications; Upload builds; TestFlight overview; Export compliance documentation for encryption; Age ratings values and definitions; Submit an In-App Purchase; Select an App Store version release option; Release a version update in phases; Submit an app.
• Apple Developer Documentation: Complying with Encryption Export Regulations; Describing use of required reason API; NSPrivacyAccessedAPITypeReasons.