App Store phased release: what it does and doesn't
Shipping without a releaseExplainer4 min readMiniwall team
A phased release on the App Store hands your update to a growing random share of people over seven days, and you can pause it. It can't take the update back from phones that already have it, it doesn't touch the web, and it doesn't change what's already inside the build. Everything below about Apple's rules is from their help page, as of 2026-10-28.
The schedule
You switch it on when you submit a version update. Apple's wording is that the update goes out gradually over 7 days, to "a random sample of users with automatic updates on eligible devices"[1]. Those people aren't told they're part of it.
| Day | Share of users |
|---|---|
| 1 | 1% |
| 2 | 2% |
| 3 | 5% |
| 4 | 10% |
| 5 | 20% |
| 6 | 50% |
| 7 | 100% |
Swipe sideways to see every column.
The page names iOS, macOS and tvOS. You need the Account Holder, Admin or App Manager role to set it up.
Two things that surprise people
The percentage isn't a gate. Apple says apps and updates in phased release "can be manually downloaded from the App Store by anyone at any time"[1]. Someone who opens the store page and taps Update gets the new version on day 1. So the schedule shapes who is pushed the update. It doesn't cap who can have it.
Pausing is the only brake. You can pause for up to 30 days in total, with no limit on the number of pauses. If you pause for 10 days, you have 20 left. When you resume, it picks up on the day where it stopped[1]. You can also release to everyone at any time. The page also notes that removing the app from sale stops the phased release for that version, and that when the app comes back it is available to everyone immediately[1].
Notice what the page describes: pausing and resuming. It doesn't describe a way to pull the update back from devices that already installed it. If there's a bad build out there, pausing stops it spreading and that's all.
Where it stops
It doesn't undo. The fix for a bad phased release is another version update. That one goes through review and then needs its own spread. Phased release limits how many people meet the bug while you find out. I'd count that as useful, and still not a rollback.
It doesn't change shipped content. A price label, a line of copy, the order of two buttons: if it's compiled into the binary, changing it means a new version. Phasing the new version out slowly doesn't make the first one editable.
It doesn't apply to the web. It's a feature of App Store Connect. A website has no store between you and the visitor, so whatever you deploy is what the next visitor loads unless you add your own gate, like a flag. Deploy is not release is about building that gate on purpose.
Google Play is a separate system. It has its own staged rollouts, and this post doesn't describe them. Read Google's documentation before you plan around a Play release, and don't assume it matches Apple's.
What to pair it with
Use phased release for what it's good at: limiting the blast radius of a new build. Then ask a different question for each change you want to make afterwards. Does it need new code? Then it's a build, and phasing is a sensible way to ship it. Is it only a value, a flag or the content of a screen? Then waiting for a store release, phased or not, is the slow path.
There are several ways to change those without a build, each with trade-offs. Ways to change a live app without shipping a release lays them out, and flags, remote config and a CMS separates three that get mixed up. One caution: remote content has its own rollout and rollback problem, and Apple's page doesn't cover it. When not to use server-driven UI lists five cases where the answer is to keep the screen in the app.
Sources
- Apple, Release a version update in phases (App Store Connect help) (opens in a new tab)developer.apple.com · accessed
