Apple's phased release reaches 1%, 2%, 5%, 10%, 20%, 50% and then 100% of automatic updaters over seven days. Check one or two named signals each day, compare against the previous build, and pause if a signal crosses the limit you set before release.
The schedule
Apple publishes the daily shares, so you can plan around them.
| Day | Share of users with automatic updates | What to look at |
|---|---|---|
| 1 | 1% | Launch crashes, sign in, first run |
| 2 | 2% | Crash free sessions against the previous build |
| 3 | 5% | The feature that uses the upgraded SDK |
| 4 | 10% | Support tickets and store reviews mentioning the change |
| 5 | 20% | Battery, memory, slow screens |
| 6 | 50% | Backend errors from the new client version |
| 7 | 100% | Final comparison, then record the result |
The shares apply to a random sample of users with automatic updates on eligible devices, and users are not told. Anyone can still download the update manually, so a small number of people may be ahead of the schedule.
Why small numbers still matter
At 1%, a studio with a modest user base may see very few sessions on the new build. That is fine for catching a crash on launch, but too thin to judge a subtle regression. Use the early days for loud failures and later days for quiet ones. If a day has too little data to say anything, say so and wait, rather than reading noise.
Set limits before you start
Write these on the release ticket, before day one.
- A crash rate on the new build that triggers a pause.
- A failure rate for the key flows, such as login and purchase.
- Who watches, and who is allowed to pause. Apple restricts the pause to the Account Holder, Admin or App Manager roles.
- What you will do after pausing: investigate, fix and resubmit, or resume.
How pausing works
You can pause for a total of 30 days, across any number of pauses, and the rollout continues from the day you stopped. If you remove the app from sale, the phased release ends for that version, and when the app returns it is available to all users at once. Apple says to make the version unavailable and submit a new update to get a controlled rollout again.
Android in parallel
If you ship the same SDK change on Android, remember its rollout does not rise by itself. Align your Play percentage with Apple's day so you compare like with like. The post on Apple and Google rollout differences has the table.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how changes are flagged over time, which is the habit this plan builds by hand.
Safeguard scans dependencies and records an SBOM per build, which makes it simple to check which SDK version each day's cohort has. A free scan is available.
Quick check
Does day 7 mean everyone has the update?
It means 100% of users with automatic updates on eligible devices are eligible. Others update when they choose.
Can I skip ahead of the schedule?
Yes. Once the version is Ready for Distribution, choose Release to All Users.
Sources
Last reviewed: 19 October 2026.
