What is the path from an archive to users: TestFlight internal and external testing, review, release options, phased release and expedited review?
Predict first
A phased release starts and the crash rate doubles on day two. What is the best first action?
// A: wait to see if it settles
// B: pause the phased release, check the cause, ship a fixed build and use a flag or kill switch if one exists
// C: delete the app from the store- A
- B
- C
Mental model. Release is a staged rollout of a new road: close it to the public, let a few drivers test it, open one lane, then all lanes, with a barrier ready to close it again.
The path is: archive a Release build, validate and upload it to App Store Connect (from Xcode, xcodebuild and the API, or CI), wait for processing (which also runs automated checks and can reject a build for missing privacy strings or invalid signing), then distribute through TestFlight. Internal testers are members of your team account and can get a build as soon as it is processed; external testers are invited by email or a public link, organised in groups, and the first build of a version goes through a lighter Beta App Review. TestFlight builds expire (after 90 days), testers can send feedback and crash reports, and you can target groups with different builds. When a build is ready, you attach it to a version in App Store Connect, fill the metadata, answer the compliance questions and submit for App Review.
After approval you choose the release option: automatically, manually (you press release when ready, which suits coordinated launches) or on a date. For updates, phased release for automatic updates rolls the version out to automatic-update users over seven days (about 1%, 2%, 5%, 10%, 20%, 50%, then 100%); you can pause it for up to 30 days if monitoring shows a problem, or release to everyone immediately, and users who update manually can still get the new version at any time, so phasing limits exposure but does not make it zero. If a serious bug ships, you can request an expedited review for a fix, which is granted for critical issues but is not guaranteed, so do not plan around it. Watch crash-free sessions, hang and launch metrics and support signals during the first hours (Q432), and keep the previous version’s .xcarchive so a fix branch can start from known code. Plan release timing around review time (usually quick, but allow margin) and around holidays.
Pausing limits how many people receive the bad build while you fix forward; waiting exposes more of them.
Common traps
- Assuming phased release protects manual updaters. Users who tap Update get the new version immediately.
- Planning a hotfix around expedited review. It is a courtesy for critical issues, not a service level.
They might follow up with
- What is the difference between internal and external TestFlight testers? Internal are your team and need no review; external testers need the first build of a version to pass Beta App Review.
- What can you do mid-rollout? Pause the phased release, then fix and submit a new build.
Related questions
- 25.3.2 How does App Review work, what causes common rejections, and what are export compliance, the privacy labels…
- 25.3.3 What can and cannot be rolled back after release, and how do you respond to a bad release: pause, flags…
- 25.4.2 How do you run a release train for many apps: cadence, branch cuts, ownership, go/no-go criteria, hotfix…
- 21.3.2 How do you build a performance culture on a team: budgets, regression gates, ownership and release guardrails?
How does App Review work, what causes common rejections, and what are… →