App Store launch checklist.

The short version: eight release checks

1. Install the intended release build and complete the main flow from a fresh state.
2. Check privacy answers, permission prompts and public support links.
3. Verify screenshots and metadata against the actual build.
4. Test purchases and restore against App Store sandbox products where applicable.
5. Give reviewers working access and clear setup instructions.
6. Add the app version and any required purchase items to the review submission.
7. Confirm the submission was actually sent, then track the review outcome.
8. After release, verify the public listing and run the installed App Store build.

Use the detailed checks below before each release. Some checks apply only if the app uses the relevant feature.

Product readiness

• The first-run experience explains the value without relying on test data.
• Every primary flow has empty, loading, failure and retry states.
• Links to privacy, support and terms open real public pages.
• If users create accounts, account deletion is available where required.
• Placeholder text, debug menus and development credentials are removed.

Technical release

• The production bundle identifier, signing team and capabilities are correct.
• The archive uses the intended production environment and API endpoints.
• Crash reporting and essential diagnostics respect consent and privacy choices.
• Push notification, universal link, background mode and associated-domain entitlements match the shipped features.
• The app was tested on the smallest supported screen and current iOS versions.

Privacy and permissions

Permission prompts need clear usage descriptions and should appear only when the user starts a feature that needs access. App Privacy answers must match the actual SDKs and data flows in the binary. Review third-party analytics, advertising, login and payment libraries rather than describing only your own code.

Subscriptions and purchases

• Product identifiers, pricing, availability and review details match the app’s StoreKit configuration.
• For the first purchase of a given type, include the required new app version. For a first subscription group, include the group and its subscriptions in the same draft submission.
• Prices, billing periods, trial terms and renewal language are visible before purchase.
• A real sandbox or TestFlight purchase and restore have been completed. A local StoreKit configuration test alone does not verify App Store product setup.
• Expired, refunded and revoked entitlements produce a sensible state.
• A reviewer can reach and test the paywall without hidden setup.

Store listing

• App name, subtitle and description explain the real use case.
• Keywords do not repeat the app name unnecessarily.
• Screenshots show shipped screens and readable benefits.
• The support URL reaches a page with a working contact method.
• Category, age rating, copyright and content rights are accurate.

Review access

If sign-in is required, provide a stable review account and explain any non-obvious path. If the product depends on hardware, location, a paid service or a specific role, add concise notes and a demonstration video when useful. Reviewers should not have to guess how to reach the core feature.

Release strategy

Choose manual release when timing matters or when marketing and support teams need coordination. Phased release reduces exposure for automatic updates, but it does not replace monitoring. Prepare a rollback or hotfix decision path before the release becomes urgent.

After approval

• Run a production smoke test from the public App Store build.
• Watch crashes, authentication, purchases and the core API flow.
• Confirm analytics events arrive without collecting unnecessary data.
• Capture user friction for the first maintenance release.

Uploaded, tested, submitted and released are different states

Common launch questions

Does TestFlight mean the app is approved for the App Store?

No. Beta distribution and App Store review are separate stages. Verify the status of the intended App Store version and its actual public availability.

Do my first subscriptions need an app version?

Apple requires the first purchase of each type to accompany a new app version. A new subscription group must be submitted with at least one subscription. Check that all required items are in the same draft before submission.

Can review time be guaranteed?

No. Plan the launch around a review outcome rather than a promised approval date. Manual release gives you a separate decision after approval.

Official references and practical examples

Checked against Apple’s documentation on 27 October 2026: submitting an app, submitting purchases and subscriptions and sandbox testing.

See DAY’S and its current release screens for a shipped utility, or plan the wider project using the iOS development cost guide.

Taking over an app that is already live? Run the iOS app audit checklist to verify the build and release access first.