A Google Play staged rollout only moves when you move it, and halting it leaves everyone who already updated on that build.
A Google Play staged rollout sends an app update to a percentage of users that you pick, and that percentage never rises on its own. You raise it, halt it or resume it yourself in Play Console. Here is the part people learn too late: halting stops the version reaching anyone new, and everyone who already received it stays on it. Google's own help page says so in those words. There is no button that pulls a bad build off the phones that have it. The dial also works on updates only, so a first release cannot be staged, which is one of the sharper edges of publishing to Google Play.
Every step, field name and limit below comes from Google's and Apple's own current documentation, read on 3 October 2026. You get where the percentage field actually is, how to raise it, how to halt, what a halt does and does not undo, and why the same idea on the App Store behaves in the opposite way.
See who keeps the build after a haltThe short version
Google hands you the dial and Apple keeps hold of it.
The two stores built opposite things out of the same idea. A percentage rollout on Android is operator-controlled: you enter a number, and nothing changes until you enter a bigger one. On the App Store you tick one box and Apple steps the update out over 7 days on a fixed ladder, 1 percent then 2, 5, 10, 20, 50 and 100. Apple publishes that table. Google publishes no schedule, because on Google Play there is nothing to schedule.
So the two fail in different ways. Play rollouts fail when nobody goes back to raise the number, or when a rollout left open blocks the next release. Phased releases fail while you are asleep, because the ladder keeps climbing. The recovery options differ too, and Google's are better than most pages admit.
Setting the percentage, as Play Console works today
The dial lives on the release, not in a settings page. Go to Test and release > Production for a production update, or Test and release > Testing > Open testing or Closed testing for a test track. Click Create new release near the top right, add your app bundle, name the release and write the release notes, which Google caps at 500 Unicode characters per language. On the last screen before you publish you select a rollout percentage and click Start rollout. Two Google pages name that screen differently, Preview and confirm on one and Review release on the other, so do not hunt for an exact label.
Then the percentage sits there. Google states that your app's staged rollout percentage will not increase automatically. To raise it, open the track page, select the Releases tab, and under the release choose Manage rollout > Update rollout, set the new number and click Confirm update. The same menu holds Halt rollout and, after a halt, Resume rollout, which also asks for a percentage. The Play Console mobile app can resume one from the Active releases card.
Who receives the build is Google's choice rather than yours. New and existing users are both eligible, are picked at random for each new release rollout, and are not told they are in a staged rollout. Halt and then resume and you affect the same set of users. Start a new staged rollout before the previous one finished and it reuses the same group. You can narrow it geographically: on a production update, the Staged rollout section of the release has a Country availability option where you choose Select specific countries/regions. The default matches the locations already set for your production track, and once a staged rollout has started you cannot remove a country from it.
One scoping detail catches people. The percentage steps are documented on Production, Open testing and Closed testing. Internal testing is not named in them, and the separate page on halting a full release says that control works on any track except internal test tracks. So if your app sits on an internal track with up to 100 testers, the dial is not your tool yet. A limited build in front of real users before production is google play closed testing instead.
Google Play Console Help, Release app updates with staged rollouts, read 3 October 2026
Halting a rollout, and the thing a halt will not do
Halting is one menu item, and its effect is narrower than the word sounds. Open the track page, select the Releases tab, then under the release choose Manage rollout > Halt rollout. Google's wording is the whole lesson: no additional users will receive the app version in your existing staged rollout, and users who already received it will remain on that version. A halt is a stop on distribution, not a recall. Nothing in Play Console reverses an install that already happened.
There is a second control for the case people actually panic about. Google's Play Console Help page titled Halting a fully rolled-out release, read on 3 October 2026, says you can halt a release that is already at 100 percent. Do that and a previously live, fully rolled-out version automatically takes its place, becoming available to new users and to anyone not running the halted version. It works from the Play Console web or mobile interface, or through the Publishing API, on any track except internal test tracks. You cannot halt the first release on a track, because there is nothing to fall back to, and a previous release carrying a policy violation cannot stand in. You can resume to any percentage once the fix is ready.
Read the caveat on that page as carefully as the feature. Google says that if the release has been live for a significant length of time, or is being used by a large percentage of your users, halting might not be the most effective solution, because most users may already have updated. A halt protects the people who have not received it. For the people who have, Google's own tip is the only route: create and roll out a new release with a fixed app bundle. Bump the version code and ship, and expect review like any other build.
You can audit all of it afterwards. Under Test and release > Latest releases and bundles, open a release and Rollout history gives a timeline of when it was halted, resumed or served to a new percentage of users. That timeline is often the only honest record of what happened at two in the morning.
Try it
Who keeps the build after you halt
A halt stops new deliveries. It does not take the version off a phone that already has it.
2,000 keep it, 18,000 never get it
At 10 percent, up to 2,000 people can receive the build. Halting protects the other 18,000 and moves none of the first group. Getting that group off it takes a new release with a fixed app bundle. Halting a fully rolled-out version is the one exception, and it only puts the previous version back for new installs. For scale, Apple's published ladder reaches 10 percent or more on day 4 of 7.
What Apple does instead, and why it is not the same safety net
Apple's version is not a dial. app store phased release is a single checkbox, and Apple moves the percentage for you across 7 days: 1 percent on day one, then 2, 5, 10, 20, 50 and 100. You set it in App Store Connect before you submit, in the Phased Release for Automatic Updates section of the version page, by selecting Release update over a 7-day period using phased release and saving. Account Holder, Admin or App Manager can do it. Once approved, the version shows Ready for Distribution with Phased Release appended, and Admin and App Manager users get a notification when the ladder finishes.
Two details make it weaker than it looks as a containment tool. The phases only reach a random sample of users whose devices have automatic updates turned on, and Apple states that an app update in phased release can be manually downloaded from the App Store by anyone at any time. So the percentage caps automatic installs. It is not a boundary around the build, because anyone who opens the App Store and taps Update is on the new version on day one.
Your stop button is Pause Phased Release, in the same section of the version page. Apple allows 30 days of pause in total with no limit on the number of pauses, and a resumed release picks up on the day it left off, so ten days paused leaves twenty. Release to All Users sits at the top right when you want to end the ladder early. What is not on Apple's page is any way to put the previous version back. Apple's instruction for getting a controlled rollout again is to make the version unavailable for download and submit a new version update with phased release enabled. Google's full-release halt has no Apple counterpart.
One trap has nothing to do with your code. Apple says that removing your app from sale, which includes an Apple Developer Program membership lapsing, stops the phased release and it will not be available again for that version. When the app is reinstated it becomes available to all users immediately, whatever percentage it had reached. A lapsed renewal is a silent jump to 100 percent.
Apple, App Store Connect Help: Release a version update in phases, read 3 October 2026
The percentage to start at is not published, and that is worth saying
Nobody publishes the number you should start at. Google's help pages do not recommend a figure and we are not going to invent one. What Google does state is that your update will be available to the percentage of users in your staged rollout, but that it may take time for the full group to receive it. No duration is given anywhere on that page. So if you set 10 percent and watch the installs climb slowly for a while, that is documented behaviour rather than a broken rollout.
The only published schedule in either store is Apple's ladder, and you can borrow it as a defensible reference: 1, 2, 5, 10, 20, 50, 100. The shape works because each step at least doubles the last, so a crash that shows at 5 percent shows before most of your users could meet it. Past that, your own numbers decide. Google's advice for the window is to monitor crash reports and user feedback closely, and it notes that users who receive a staged rollout can leave public reviews on Google Play, which is the real cost of starting too high.
Two constraints are worth planning around. You cannot create a new release while you have outstanding ones: Google says to roll any staged releases out to 100 percent, or remove the changes on the Publishing overview page and discard the unpublished release first. A rollout left at 20 percent and forgotten is a blocked release months later. The other constraint is delivery itself, because how fast a device even notices an update is a separate mechanism from the dial, and that is how updates reach people.
The same four moves on each store, as documented today
| What you want to do | Google Play staged rollout | App Store phased release | Needs a new build |
|---|---|---|---|
| Start on a small share of users | Select a rollout percentage, then Start rollout | Tick the 7-day phased release box before you submit | No |
| Move more people onto it | Manage rollout > Update rollout, then Confirm update | Happens on its own: 1, 2, 5, 10, 20, 50, 100 percent | No |
| Stop it reaching anyone else | Manage rollout > Halt rollout | Pause Phased Release, 30 days in total | No |
| Put the previous version back for new installs | Yes, by halting a fully rolled-out release | Not described on Apple's page | No |
| Get people already on the bad build off it | Not possible, they remain on that version | Not described on Apple's page | Yes |
Where the rollout sits if a builder shipped the app
A staged rollout is a console setting, not code. Nothing in your app has to change to use one, and nothing in your app can undo one. The one code decision that touches the dial is whether your backend can serve two versions of the app at once, because during a staged rollout it is doing exactly that. Keep the API compatible with the previous version for one release and a halt stays a release decision instead of an outage.
Newly is an AI app builder, and this is where its Android path meets the dial. You describe the app in plain English, it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, uploads to TestFlight, publishes to Google Play internal testing and builds a standalone production APK. It is $25 a month and there is no free plan. Internal testing is not where the percentage steps are documented, so promote the release to Production, Open testing or Closed testing in Play Console first, then set the percentage on that track.
One sequencing point from Google's own tips, because it burns people mid-rollout. If the update needs a change to your store listing, wait until the release is at 100 percent before you change it. The listing is not staged. Everyone sees the new screenshots and the new description the moment you publish them, including every user still on the old build.
Questions people ask about staged rollouts on Google Play
A way to release an app update to a percentage of users that you choose, on production or on a test track, and then increase that percentage over time. Users are chosen at random from new and existing users and are not notified. It is for updates only: staged rollouts cannot be used when you publish an app for the first time, and rollout percentage options do not appear on a first release.
Decide the halt plan before you set the percentage
Write down the number you are starting at, who raises it and when, which metric halts it, and the fact that a halt leaves the current group on the build. Then ship the update knowing what your recovery actually looks like.
Start building