An App Store submission checklist should verify one release, not just one binary. Before you submit, check the exact build, its App Store Connect record, public metadata, reviewer access, backend services, purchases, privacy declarations, and the final draft submission together.
Run the checklist in that order. A green check beside every required field does not prove that the reviewer can sign in, reach a paid feature, or reproduce what your screenshots promise.
The short version
- Freeze the version and build you intend to submit.
- Test the reviewer’s path on that build from a clean install.
- Match every public claim and compliance answer to the release.
- Use Add for Review, inspect the draft, then use Submit for Review.
1. Freeze the release candidate
Start by naming the exact candidate: app version, build number, bundle ID, release commit, and backend environment. If you cannot point to one immutable candidate, the rest of the checklist can be completed against the wrong build.
Test the distribution build rather than relying on a debug run from Xcode. At minimum, check:
- clean install and first launch;
- onboarding and permissions;
- sign-up, sign-in, sign-out, and account recovery;
- the core task your product promises;
- purchases, restore, and entitlement changes when applicable;
- empty, offline, loading, and error states;
- support, privacy, and account-deletion links.
Record the result beside the build number. If a blocking defect requires code or bundled assets to change, upload a new build. If only editable metadata is wrong, you may be able to correct the App Store Connect record without rebuilding. Do not assume which path applies until you identify where the defect lives.
For the complete submission sequence, keep the first iOS App Store submission guide open beside this preflight.
2. Match the app record to the build
The App Store Connect record and uploaded binary must describe the same app. Confirm the bundle ID, marketing version, build number, and supported platforms before selecting the build.
Apple’s build selection instructions explain that one build can be associated with an app version at a time and that you can change it before submission. This is useful, but it also creates a quiet failure mode: two processed builds can look similar in the picker.
Check the selected build after every meaningful App Store Connect edit. If you replace it, rerun the reviewer path. A note written for build 18 can become misleading when build 19 moves the feature or changes the demo data.
Also clear any processing or compliance prompt attached to the build. An upload appearing under Builds is not the same as that build being selectable for review.
3. Complete the public product page
Public metadata should describe what a customer can actually find in this release. Read the app name, subtitle, description, keywords, promotional text, screenshots, support URL, privacy policy URL, and release notes as one claim set.
Ask three questions for every statement or image:
- Is this feature present in the selected build?
- Can a normal user reach it under the stated conditions?
- Does the screenshot show the real interface rather than a future design?
Apple’s App Review Guidelines require complete and accurate metadata. Guideline 2.1 says submissions should be final versions with necessary metadata and functional URLs; Guideline 2.3 covers accurate metadata and representations.
Open every URL in a signed-out browser. A privacy page that works only for your admin session is not public. Use the technical screenshot rules separately from this release-level check; the guide to App Store screenshot requirements covers files, display sizes, and review-safe claims.
4. Give App Review a complete access path
If the app includes account-based features, provide an active demo account or a fully featured demo mode. Apple’s current App Review guidance also asks for any hardware or resources needed to review the app, such as login credentials or a sample QR code.
Test the credentials outside your own device and network. Confirm that the account:
- does not require a one-time code sent only to you;
- does not force an expired password reset;
- already contains the data needed to inspect the main workflow;
- has access to the correct role, region, and subscription state;
- remains active throughout review.
Write Review Notes as a route, not a pitch: starting state, login, taps, expected result, and any dependency. If Apple needs a second account, special hardware, a location state, or another resource, name it and explain how to access it before the reviewer encounters the block.
5. Verify services, purchases, and related items
A review build can be technically sound while its production environment is not ready. Check that APIs, authentication, media, email links, remote configuration, and feature flags are live for the reviewer account.
For in-app purchases and subscriptions, verify the product identifiers used by the selected build. Check agreements, tax and banking status, product metadata, pricing, review screenshots, localization, and attachment to the intended submission. Then run purchase and restore flows in the appropriate test environment.
Do not add unrelated items to the review draft. Apple’s submission instructions state that all items submitted together must be accepted for the submission to complete. Inspect the draft as a package.
6. Reconcile privacy, compliance, and age answers
Answer declarations from the production app and its SDKs, not from memory or an earlier version. Recheck App Privacy data types and purposes, tracking behavior, encryption/export compliance, content rights, advertising identifiers, and age-rating answers.
This is a reconciliation task: app behavior, privacy policy, App Store labels, permission prompts, and SDK configuration should tell the same story. If you cannot explain why an SDK transmits a data type, investigate before submitting rather than guessing at the questionnaire.
For legal, health, finance, kids, or gambling features, use current Apple documentation and obtain appropriate professional advice. This checklist is submission guidance, not legal advice.
7. Inspect the final submission, then send it
App Store Connect currently separates preparation from sending. Select Add for Review on the app version to add it to a draft submission. Its status becomes Ready for Review, but Apple has not received it yet. Open the draft, inspect every included item, and then select Submit for Review.
Apple documents this two-action flow in Submit an app. After submission, the version moves to Waiting for Review and then In Review when review starts.
Before the final click, compare these four identifiers one last time:
| Surface | Value to verify |
|---|---|
| Xcode archive | version and build |
| App Store Connect version | public version |
| Selected build | exact tested build number |
| Review Notes | route and state for that build |
Take a private release record of what you sent. It will make any App Review message easier to diagnose without relying on memory.
FAQ about the App Store submission checklist
Does a complete App Store Connect page mean the app is ready?
No. It means required record fields are present. You still need to test the selected build, reviewer access, backend services, purchases, links, and the claims made by metadata.
Should I submit immediately after uploading a build?
Wait until processing is complete, select the intended build, and test a distribution-equivalent release. Uploading successfully is not a review-readiness test.
Do metadata changes require a new build?
Not always. Editable App Store metadata can often be corrected in the record. Code, bundled content, entitlements, or behavior changes require a new build. Check the status and field before deciding.
Is Add for Review the final submission action?
No. Add for Review creates or updates a draft submission. Submit for Review sends that draft to Apple.
Conclusion
The useful checklist is the one that keeps the build and its evidence together. Freeze the candidate, test the reviewer’s route, reconcile the public and compliance records, then inspect the complete draft submission.
Your smallest next action is to write down the version and build number you intend to send. Every remaining check should point back to that release.