iOS App Store submission checklist: build, review and release
Prepare an iOS App Store submission with a build worksheet, metadata checks, review-account instructions, purchase submission rules and release decisions.
Submitting an iOS app means delivering a specific build, its product-page information and enough review context for Apple to assess it. Uploading a binary is one step. Selecting it for a version, completing metadata, submitting the review draft and choosing release behavior are separate decisions.
This guide provides an App Store Connect submission worksheet based on Apple's documentation reviewed on October 7, 2026. It focuses on the technical handoff rather than a marketing launch plan. Treat the checklist as preparation: it cannot guarantee approval or a review date.
Record the app, version and build you intend to submit
Start with a small release record shared by the people handling engineering, product-page assets and review questions. The following example is fictional; replace every value with your app's actual identifiers.
| Field | Illustrative value | Check before submission |
|---|---|---|
| App and bundle ID | Reading app, com.example.reader | The App Store Connect record and signed app target identify the same app |
| Marketing version | 1.0 | The version being prepared matches the uploaded binary |
| Build string | 42 | This is the exact tested build, not an earlier successful upload |
| Release owner | Named team member | They can submit, answer review questions and release the approved version |
| Purchase scope | Annual subscription, if included | The product and any required subscription group are in the intended submission |
| Release choice | Manual after approval | The team understands what action makes the approved app available |
Apple's app information reference distinguishes identifiers from editable metadata. The bundle ID must match Xcode and cannot change after a build is uploaded. The SKU cannot change after the app is added. The name can change when the version's status permits it, and the primary language can change. Do not treat every field as either permanently fixed or freely editable.
Test the candidate before handing it to review
Use the build recorded in the worksheet to exercise installation, launch, sign-in, primary actions and recovery from expected failures. Include the devices, account states and backend configuration relevant to your app. Keep evidence with the candidate rather than assuming a previous build's result still applies.
For an app with subscriptions, verify that the displayed product matches checkout, cancellation is handled, an existing purchase can be restored and the correct account receives access. Test with the store's appropriate test accounts and environment. The separate paywall rollout checklist supplies a device matrix and ownership worksheet; the subscription management guide covers the underlying access and recovery design.
Keep the review path reproducible. If a feature needs a particular account state, provide a dedicated review account with that state and instructions for reaching it. Check that the backend and required content will remain available while review is pending. These are operating decisions your team must verify, not evidence that an uploaded app has already passed review.
Upload and wait for processing
Follow Apple's build upload guide for the supported workflow and current toolchain requirements. It distinguishes the Xcode version used to build an app from the tooling used to upload it. Recheck those requirements for each release rather than relying on a generic instruction to use whichever version is installed.
The uploaded bundle ID and version associate the binary with its App Store Connect record; the build string identifies the build. Apple must process the upload before it appears for selection. Inspect delivery warnings, errors and processing results. An upload receipt is not a review submission.
Once the build is available, open the intended platform version and choose it in the Build section. Apple's build selection instructions allow one build to be associated with a version at a time, with changes before submission. Verify the build string and upload time, then save. If the build has Missing Compliance status, resolve the prompted export-compliance questions or documentation before submitting.
Reconcile metadata with the actual app
Work through Apple's required and editable property tables for the app, platform version and purchases you are submitting. Check the applicable regional and app-specific fields in App Store Connect. A generic article cannot determine every declaration for your app.
Prepare screenshots, description, support information, privacy disclosures and the other required fields against the behavior in the candidate build. If an asset promises a feature or offer, verify that reviewers and customers can reach it under the stated conditions. Use the data-inventory worksheet to reconcile your app and SDK behavior with the disclosures your team reviews.
Metadata does not share one edit rule. Apple's platform version reference, for example, permits promotional text updates without a new submission, while other properties depend on version status. Check the specific field before promising that descriptions, keywords, screenshots or previews can all change at any time.
Give App Review a working route through the app
The platform version reference describes review contact details, notes and demo credentials when login is required. The demo account must not expire. Give Apple the information needed to reproduce the relevant flow, and keep ordinary customer credentials out of the submission.
A useful review-note outline is:
- Where to sign in with the dedicated review account and which starting state it has.
- The steps to reach a feature, subscription offer or integration that is not obvious from first launch.
- Any app-specific setting, sample content or additional account needed for the test.
- The contact who can answer questions and the release record identifying the candidate.
Try those instructions with a teammate who did not implement the feature. If they need undocumented help, improve the notes or the app before submission. Keep the notes factual; they should explain working behavior rather than make an approval argument.
Include purchases in the correct submission
Apple's purchase submission guide requires the first item of each In-App Purchase type to accompany a new app version. After that type's first approval, additional items can be submitted without a new version when the app has an approved version. Check the rule for the type you are adding rather than assuming every new product follows the same path.
For a new subscription, account for its subscription group. Apple instructs developers to include the app version, group and purchase items intended for joint review in the same draft submission. Review that item list before sending it. A product that exists in the catalog is not necessarily part of the submission you are about to send.
Send the review draft, then track its status
Apple's app submission instructions distinguish two actions. Add for Review places the version into a draft submission; it does not send that draft to Apple. Open the draft, inspect its contents and use Submit for Review to send it.
Confirm that the person performing the submission has the required role and app access. Then record the submitted version and items, monitor App Review messages and respond with the relevant evidence if Apple identifies a problem. If a fix changes the binary, treat it as a new candidate that needs its own build selection and verification.
Plan launch communications around observed status. Do not turn an average review time, an earlier app's experience or an upload success into a deadline promise for this submission.
Choose how approval becomes availability
Apple's release settings offer manual release, automatic release after approval, or automatic release no earlier than a selected date. The date option does not bypass review. With manual release, the approved version reaches Pending Developer Release and still requires the release action.
Record the choice and the person responsible for it. Before release, confirm the intended pricing and territory availability. After release, verify the actual product page and installation path in the markets you support, then check launch, sign-in, purchases and support contact routes on the distributed app. Keep that evidence separate from the pre-submission test.
The result is a traceable handoff: a known build, reviewed metadata, an explicit submission and a deliberate release decision. Use the broader launch plan for acquisition and announcements, and return to this worksheet whenever a new app version is submitted.