The App Store Submission Checklist for 2026

This checklist follows the order in which you actually work in App Store Connect, from account setup to pressing "Release". Copy it into your ticket system, assign owners, and tick items off. Each item names the most common way it goes wrong.

Phase 1: Account and agreements

• Apple Developer Program membership active (USD 99 per year). Organizations need a D-U-N-S number; see Apple developer accounts for companies.
• Agreements accepted in App Store Connect. When Apple updates the Program License Agreement, uploads and submissions can be blocked until the Account Holder accepts it.
• Paid Apps agreement, tax and banking completed if the app has a price or in-app purchases.
• EU trader status declared if you distribute in the European Union. Under the Digital Services Act, Apple asks whether you are a trader, and traders' contact details are shown on the product page.
• Team roles set so that the people preparing the release have the access they need without sharing the Account Holder login.

Phase 2: The build

• Bundle ID registered and matching the app record.
• Built with the required Xcode and SDK. Apple raises the minimum each spring; check the current requirement on the Apple Developer news page before your release.
• Signed for distribution with a valid certificate and App Store provisioning profile. Our iOS code signing guide covers certificates, profiles and keys.
• Version and build number incremented. A build number can be used only once per version.
• App icon in all required sizes, including the 1024 x 1024 px marketing icon without transparency.
• Privacy manifest (PrivacyInfo.xcprivacy) present if your app or its SDKs use APIs that require declared reasons. Third-party SDKs often ship their own; keep them updated.
• Permission usage strings for every permission you request (camera, photos, location, microphone, contacts, tracking), written in plain language that explains why.
• Export compliance answered. If you use only standard HTTPS, setting ITSAppUsesNonExemptEncryption in Info.plist avoids the question on every upload.
• Tested on real devices via TestFlight, including the smallest and largest supported iPhone and, if declared, iPad. Apps that support iPad are reviewed on iPad.
• IPv6-only networks supported; App Review tests in such an environment, and hard-coded IPv4 addresses break.

Phase 3: Metadata and screenshots

Screenshot size requirements change with new iPhone models; App Store Connect shows the currently required sizes when you upload. Add a support URL that actually leads to contact options and a privacy policy URL that covers the app.

Phase 4: Privacy and data

• Privacy labels ("App Privacy") filled in for all data collected by you and by third-party SDKs such as analytics, crash reporting and ads. Our guide to privacy labels and the data safety form explains each category.
• App Tracking Transparency prompt implemented if you track users across other companies' apps or websites.
• Account deletion available inside the app if users can create accounts (Guideline 5.1.1).
• Login options compliant with Guideline 4.8 if you offer third-party or social login.
• Age rating questionnaire answered honestly. Apple revised the age rating system in 2025, so re-check existing answers for older apps.

Phase 5: Notes for App Review

1. Demo account with realistic data that does not expire and does not require 2FA codes sent to your team's phones.
2. Explanation of non-obvious features: hardware needed, region-locked content, how to trigger a purchase or a push notification.
3. A short video link if a feature is hard to reach in review (for example, a device pairing flow).
4. Contact details of someone who will answer within a day.

Reviewers work through many apps; a clear note can save you a full rejection cycle. If your app is mainly web content inside a native shell, use the notes to list the native features, such as push notifications, offline handling and native navigation, so the reviewer does not have to hunt for them.

Phase 6: Release settings

• Manual or automatic release after approval. Manual is safer when marketing or backend changes need to go live at the same time.
• Phased release for updates, which rolls out automatic updates over seven days and can be paused.
• Availability per country and, where relevant, pre-orders.
• Backend ready for review traffic and production users before you submit, not after approval.

Before you click "Submit for Review"

Do one last pass with fresh eyes: install the exact build from TestFlight on a device that has never had the app, create a new account, and walk through the main flow as a reviewer would. If anything feels unfinished, it will to App Review too; the most common outcomes are listed in App Store rejection reasons and fixes. If you'd rather hand off the signing, submission and review back-and-forth, appsubmitter.io does it in your own developer accounts, and an independent UX check from UXreviewer.io can catch polish issues before a reviewer does.