AppReviewX Log in

iOS release checklist: from TestFlight to App Store

Final checks, metadata, review notes and phased release for iOS apps.

updated ·3 min read

In this guide

This checklist covers the last stretch: a build that has been through TestFlight and is about to go to the App Store. Each item says why it matters and how to check it. Tick them in order.

1. The build

  • Test the exact build you will submit. Why: a rebuild can differ from the one testers used. How to check: compare build number and version in TestFlight and in App Store Connect.
  • Run your top flows on a real device. Why: simulator passes miss hardware and network problems. How: install from TestFlight, then run sign-in, purchase, notifications. See simulator or real iPhone.
  • Check that the TestFlight build is still valid. Why: Apple states a build can be tested "for up to 90 days" and becomes unavailable to testers after that. How: look at the build's expiry in TestFlight.
  • Close or consciously accept open bugs. Why: a known crash is cheaper to fix now than after a one-star review. How: sort your feedback list by severity and decide on each.

2. The listing

  • Version text ("What's new") matches the build. Why: wrong notes confuse users and reviewers. How: read it against the changes since the last version.
  • Screenshots show the current UI. Why: outdated screens cause refunds and bad reviews. How: compare each screenshot with the live app.
  • Privacy answers and policy match what the app does. Why: Apple's App Review Guidelines (5.1.1) require a privacy policy link in the App Store Connect metadata and within the app, and the policy must say what data the app collects and uses, including data shared with third-party SDKs. How: list every SDK and data type, then compare with your answers and policy. This is not legal advice; check the current guidelines.

3. Notes for App Review

  • Give App Review a working demo account if sign-in is required. Why: reviewers cannot test what they cannot open. How: log in with those exact credentials on a clean install. Apple's guidelines (2.1) say to include demo account info if your app has a login, and its submission help points to the "App Review information" section for context you want reviewers to have.
  • Explain anything non-obvious in the notes. Why: hardware, region locks or hidden features raise questions, and Apple's guidelines ask you to keep your backend services live during review. How: ask someone outside the project to read the note and tell you what is unclear.

4. Submit and release

  • Know that submissions may not be reviewed in order. Apple says: "Submissions may not be reviewed in the order you submit them." Plan a buffer before any fixed date.
  • Choose how the release happens. Why: manual release lets you wait for a good moment. How: check the release option on the version page.
  • Consider phased release. Apple describes it as releasing the update "gradually over 7 days" to a random sample of users with automatic updates. The steps are 1%, 2%, 5%, 10%, 20%, 50%, 100%. Anyone can still download manually at any time. You can pause for up to 30 days in total.

5. After release

  • Watch crashes and first reviews for the first days. Why: a phased release only helps if you look. How: check your crash reports daily.
  • Pause the phased release if a serious bug appears, then ship a fixed version.
  • Reply to early reviews politely. See review replies.

Want private, structured feedback on your build before you submit? AppReviewX works on credits: one feedback you write earns one credit. Get started on AppReviewX.