1. Identify the version you tested
Create a release record with the version, build number, source commit and test date. Install that version through TestFlight on a real device. You should be able to answer a simple question: do these checks apply to the binary you will select in App Store Connect?
Compare the production settings with what you expect: service URLs, enabled features and available content. A demo using a local server or prepared data does not establish that a fresh installation works for another person.
- Version and build number recorded.
- Fresh installation tested with new data.
- Required services accessible outside the development network.
- No debug screens or sample content presented as real user data.
2. Check the complete journey and its interruptions
Give the main task to someone unfamiliar with your interface. Observe without pointing out the buttons. Repeat the task with one condition removed: a denied permission, no network, an incomplete form or an expired session.
For each failure, check that the message makes sense, the data remains consistent and the user can recover. If you save drafts, close and reopen the app to establish what was actually preserved. Record the starting state so you can repeat the test after a fix.
- Main task completed without spoken instructions.
- Loading, empty and error states handled.
- Recovery after an interruption tested.
- Readable text and usable controls on supported screen sizes.
3. Compare the store listing with the build
Read your title and description with the app open. Each promise should correspond to behaviour in this version. Check screenshots for the devices and localisations you support; Apple documents the required screenshot specifications.
Open every submitted URL in a private window, including support and privacy pages. A successful HTTP response is only part of the check. The destination must contain the right information, working contact details and a usable mobile layout.
- Screenshots represent the submitted version.
- Planned features are not described as available.
- URLs and content checked in every active localisation.
4. Check the data answers against the app
List the data used by the app and its services, including account details, diagnostics, analytics and any payment functionality. Compare the inventory with your App Privacy answers. Apple’s instructions also cover the practices of partners whose code you integrate.
Follow one feature’s data from entry to storage or transmission. This can reveal a service added during development but omitted from the documentation. The absence of a visible form does not establish that no data is collected.
- Integrated services and SDKs inventoried.
- Privacy declarations match actual use.
- Public policy accessible from the required locations.
- Permissions requested with a clear explanation at an appropriate point.
5. Rehearse the reviewer’s access
Apple asks for full review access, with an active demo account or a fully featured demo mode when account-based features are involved. Required backend services need to remain available during review.
Try your instructions on a device without an existing session. Explain how to reach a less obvious feature and provide any resources needed to operate it. If you have to manually send a login code every time, you have not yet established that the reviewer can access the app independently.
- Review access tested outside the developer’s session.
- Short notes give steps and expected results.
- Contact details checked.
6. Make the release decision explicit
Mark each item as passed, needs correction or not applicable with a reason. Keep simple evidence for important checks: build, scenario, outcome and date. Resolve blocking crashes, data loss and unusable review access before submitting.
Then select the intended build and complete the submission in App Store Connect. Uploading a binary is not the same as requesting review. This checklist organises practical checks; it does not replace requirements specific to your app or guarantee approval.