An App Store phased release gives you 1 percent on day one and 100 percent on day seven, with a pause button in between.
The App Store phased release schedule is fixed and published: day 1 is 1 percent of users, then 2, 5, 10, 20, 50, and 100 percent on day 7. Only a random sample of users with automatic updates switched on is included, and anyone at all can still download the update by hand on day one. You switch it on in the Phased Release for Automatic Updates section of the version page in App Store Connect, by selecting Release update over a 7-day period using phased release, and it needs the Account Holder, Admin or App Manager role. That checkbox is one of the decisions waiting for you after you submit.
Every percentage, field name and menu path below comes from App Store Connect Help and Google Play Console Help, both opened on 3 October 2026. The page covers the schedule, what pausing does and does not do, the three ways a phased release ends early, and why a Google Play staged rollout is a different instrument rather than the same one with another name.
See where a pause leaves youThe short version
Seven days, seven percentages, and 30 pause days to spend as you like.
The ramp is not configurable. There is no slower curve, no faster one, and no way to hold at 10 percent for a week. The only controls Apple documents are pause, resume, and Release to All Users, which abandons the rest of the schedule and hands the version to everyone with automatic updates on.
Pausing is the part worth understanding before you need it. You get 30 pause days in total for a release, with no limit on how many separate pauses you spend them in, and a resumed release picks up on the day it stopped instead of restarting at 1 percent. What it will never do is take the version back off a phone that already has it.
The published schedule, and who is actually in it
Here is the whole thing, as App Store Connect Help states it: day 1 serves 1 percent of users, day 2 serves 2 percent, day 3 serves 5 percent, day 4 serves 10 percent, day 5 serves 20 percent, day 6 serves 50 percent, and day 7 serves 100 percent. Apple describes the recipients as a random sample of users with automatic updates on eligible devices, receiving the update with no notification that they are part of a phased release.
Two details in that description cause most of the confusion. The sample is drawn from automatic updaters only, so a person who updates apps by hand is in neither your 1 percent nor your 50 percent. And Apple says plainly that apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time. A phased release throttles who gets pushed the update. It does not hide the version from anyone who goes looking.
You select it on the version page, and the help page lists the statuses it is available from: Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected, and Metadata Rejected. Once review approves the build, the version reads Ready for Distribution with Phased Release appended beside it, and every user with an Admin or App Manager role who has access to the app gets a notification when the phased release completes. Apple's page carries platform badges for iOS, macOS and tvOS.
It is an update-only feature on both stores. Apple's App Store Connect API documentation for the appStoreVersionPhasedReleases resource says it is not available for the first version of an app, only for subsequent releases. There is no gradual rollout for a launch, which is worth knowing before you plan one.
App Store Connect Help, Release a version update in phases, read 3 October 2026
What pausing does, and what it cannot undo
Pausing stops the ramp and nothing more. No new users are served the version, the percentage stays where it is, and the people who already updated keep the build they have. Apple's page does not discuss reverting them, and there is nothing to discuss: the App Store has no mechanism for moving an installed app backwards. Apple's own instruction for a released version with a legal or usability issue is to submit an app update that describes the issue, not to pull the release.
The budget is 30 pause days per release, and Apple gives the arithmetic: pause for 10 days, resume, and 20 pause days remain for later. There is no cap on the number of pauses. A resumed release continues from the day it stopped, so pausing on day 4 and resuming the following week puts you back at 10 percent rather than at 1 percent. Deciding when to pause a phased release and when to let it run is ordinary app maintenance rather than an emergency procedure, and the budget is generous enough to cover a weekend of waiting for crash data.
Three things end a phased release early. Release to All Users, at the top right of the version page, which skips the remaining days. Spending all 30 pause days. And removing the app from sale, including letting an Apple Developer Program membership lapse: Apple says phased release then stops and will not be available for that version again, and when the app is reinstated the version goes to all users immediately, whatever percentage it had reached. The documented way back to a controlled rollout after that is to make the version unavailable for download and submit a new version update with phased release enabled.
Try it
Where a pause today would leave you
Apple's published percentages, against your own number of automatic updaters.
Day 3: 5%, about 2,000 people
Leave it running and tomorrow is 10 percent. Pausing stops that number growing and does nothing else. People who already updated keep the new version. Resuming picks up on day 3 rather than day 1, you would have 30 of your 30 pause days left, and anyone can still download the update by hand from the App Store while it sits paused.
Google Play has no schedule at all
Play's equivalent is called a staged rollout, and the App Store has no answer to the one thing it gives you: there is no timetable. You choose the percentage of users when you roll out the release, and Google Play Console Help states that the percentage will not increase automatically. Raising it is a manual step: the Releases tab, then Manage rollout, then Update rollout, then Confirm update. The Google Play Developer API calls the same value userFraction and documents the range as greater than 0 and less than 1, settable only while the release status is inProgress or halted.
Halting is Play's pause, and Google is explicit about the thing Apple leaves unsaid: when you halt a staged rollout no additional users receive that version, and users who already received it remain on it. Resuming asks you for a percentage again. Google's own advice when the build itself is the problem is not to resume but to create and roll out a new release with a fixed app bundle. The step by step, the status names and the console paths sit in the google play staged rollout walkthrough.
Two Play behaviours have no App Store counterpart. A staged rollout can be limited to specific countries, with the catch that once it has started you cannot remove any, and the country option appears only when updating a production release. And if you start a new staged rollout before the previous one has finished, Play reuses the same group of users, which quietly changes what your before and after numbers are comparing.
Google Play Console Help, Release app updates with staged rollouts, read 3 October 2026
Picking a percentage you can actually act on
A gradual rollout only earns its keep if someone reads the result, and the first days of Apple's curve are thin. One percent of a 20,000 person base with automatic updates on is roughly 200 devices, which will not give you a crash rate worth trusting. The honest reading of the schedule is that days 1 to 3 are a smoke test for something catastrophic, and the signal starts around day 4 when it reaches 10 percent.
That argues for different habits on each store. An iOS phased release cannot be slowed down, so you either accept Apple's seven days or release the version manually and skip phased release entirely. On Play you can sit at 10 or 20 percent for as long as the data takes, which is the better instrument for a risky release, provided somebody remembers to raise it. A forgotten staged rollout is the commonest way an Android release ends up half shipped for a month.
Either dial is useless without the numbers behind it. Decide before you ship which measurement would make you pause: crash-free sessions, a specific error rate, one funnel step. Choosing those thresholds and watching it after release is a job of its own, and this page stops at the rollout controls rather than the measurement.
iOS against Android on the four things people get wrong
| What you control | App Store phased release | Google Play staged rollout | The published limit |
|---|---|---|---|
| The percentage curve | Fixed at 1, 2, 5, 10, 20, 50, 100 over 7 days | You pick it, and it never rises on its own | userFraction above 0 and below 1 |
| Who receives it | Random sample of users with automatic updates on | New and existing users, picked at random per rollout | Neither store notifies them |
| Stopping the ramp | Pause Phased Release on the version page | Manage rollout, then Halt rollout | Apple: 30 pause days, unlimited pauses |
| Users who already updated | Not addressed in Apple's documentation | They remain on that version | Neither store moves a device back |
| A first release | Subsequent versions only | App updates only, percentage options hidden | Both stores publish this restriction |
Where this sits if a builder shipped the app
Neither dial lives in your build pipeline. The phased release option is an App Store Connect setting on a version, and the rollout percentage is a Play Console setting on a release. Whatever produced the binary has no say in either one. That is worth stating because people hunt for the control in their build tool and lose an afternoon to it.
Newly is an AI app builder: you describe an app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. On iOS it uploads the build and stops; you press submit yourself, because Apple's guideline 4.2.6 puts that on the person whose app it is. Ticking the phased release box on the version page afterwards is yours too.
Android splits the same way. A build sitting in internal testing is not a production release, so the staged rollout percentage is something you set in Play Console when you promote it to production. The same builder also produces a standalone production APK, and an APK you hand out yourself has no staged rollout at all, because that dial belongs to Google Play rather than to the file.
Questions people ask about phased release
Day 1 is 1 percent of users, day 2 is 2 percent, day 3 is 5 percent, day 4 is 10 percent, day 5 is 20 percent, day 6 is 50 percent, and day 7 is 100 percent. That table is published in App Store Connect Help and was read there on 3 October 2026. The percentages apply to a random sample of users with automatic updates switched on, not to your whole install base.
Ship the update, then choose the curve
Get the build into App Store Connect and into Play, then tick the phased release option on the version page and pick a Play percentage you are willing to sit at for two days.
Start building