Promote TestFlight build to App Review checklist
A beta build should become a review build only after evidence is frozen and the team knows what changed since testing.
Create a beta-to-review promotion gate before submission. Apple documents distributing apps for beta testing and releases and submitting apps for review. AppReviewReady interpretation: the promoted build should have resolved beta findings, synchronized metadata, and a reviewer path that matches the tested artifact.
Identify the promotion candidate
Record the TestFlight build, commit, workflow, tester groups, feedback window, known issues, and changed server configuration. Do not promote a build just because it is the newest upload.
If a build was tested with feature flags or beta-only content, confirm the App Review environment matches the tested state.
Freeze promotion evidence
- Critical beta feedback resolved or accepted with owner.
- Crash, hang, purchase, login, permission, and support paths retested.
- Metadata, screenshots, What’s New, privacy details, and support URLs synchronized.
- Review Notes updated with gated paths and accounts.
- Release mode and rollback owner recorded.
Check what changed after beta
Any code, server, metadata, pricing, or entitlement change after the beta window can invalidate tester evidence. Small changes near purchase or login deserve fresh testing.
AppReviewReady interpretation: promotion is a release decision, not an App Store Connect button.
Submit with a clean reviewer path
- Install the candidate from the submitted artifact path.
- Run the reviewer script from fresh install.
- Confirm demo account, purchase state, and feature flags.
- Attach only relevant Review Notes.
- Monitor review status and be ready to answer with exact build evidence.
Build promotion record
The record stops the team from losing track of which beta evidence supports which submitted build.
After approval, compare production incidents with beta feedback. If a tester reported the issue earlier, fix the promotion gate.
Promotion should have a negative checklist as well as a positive one. Confirm no temporary debug banner, test payment route, beta-only entitlement, fake data seed, broad logging flag, or experimental server rule remains active in the build that reaches review.
If post-beta changes are unavoidable, make them visible instead of pretending the beta fully covered the final build. A copy-only change may need metadata review, while a server flag, entitlement, purchase configuration, or privacy behavior change should trigger targeted retesting before submission.
Make the reviewer path match the user promise on the product page. If screenshots advertise a report, purchase, upload, collaboration, or subscription flow, the promoted build should let the reviewer reach that value with the supplied account and without hidden beta-only setup.
Freeze the support plan at the same time as the build. Support should know which known issues are accepted, which workarounds are safe, and which reports require release-owner escalation during review and the first production hours.
Promotion record: TestFlight build: [number] Review build: [number] Feedback resolved: [summary] Post-beta changes: [list] Metadata synced: [yes/no] Reviewer path: [steps] Owner: [release lead]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check build promotion
Review beta evidence, post-beta changes, metadata sync, and reviewer path before submission.
Open the tool