Last updated: 29/07/2026
The short answer
Getting through review is not the same as going live, and the gap between the two is where most avoidable launch damage happens. Both stores give you a controlled rollout, and they work in opposite ways. Apple's is automatic and time-based: App Store Connect states that selecting phased release "will release your app's update gradually over 7 days", on a published schedule of 1%, 2%, 5%, 10%, 20%, 50% and finally 100% of users. Google's is manual: Play Console Help warns that "your app's staged rollout percentage won't increase automatically" — you raise it yourself, and you can halt it the moment something looks wrong.
Both mechanisms exist for one reason: to make a bad build a small event rather than a large one. Neither does anything for you unless a named human is watching a named metric on the days after you ship. That is the part to insist on in your build contract, and the rest of this article is the detail you need to write it.
Approval is not release
The mental model most owners carry into a launch is a light switch: the store approves the build, the build goes out, done. Both stores abandoned that model years ago, and the reason is arithmetic. If a defect reaches 100% of your install base on day one, every affected user is a support ticket, a one-star review and a re-download. If it reaches 1% on day one, you have a bad morning instead of a bad quarter.
So both platforms interpose a dial. What differs is who turns it. Apple turns it for you on a clock; Google leaves it in your hand and does nothing until you move it. Neither store notifies your users that they are in a controlled rollout — Apple describes "a random sample of users with automatic updates on eligible devices" receiving the update "without any notification of their participation in the phased release", and Google states that "users won't be notified if they receive a version of your app in a staged rollout". Your rollout is invisible to the people in it, which is exactly why the monitoring has to be deliberate.
One consequence catches teams out on both stores. Apple notes that "apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time" — the phasing throttles automatic updates, not the store listing. Anyone who taps Update gets the new build immediately, percentage or no percentage.
What phased release actually does on the App Store
Apple's phased release is an opt-in checkbox on the version you submit, and once your app reaches Ready for Distribution it runs itself on a published schedule. The schedule is not a guideline or an estimate — it is a table in Apple's own documentation, which makes it something you can plan a support roster around.
| Day of phased release | Percentage of users | What it is useful for |
|---|---|---|
| 1 | 1% | Crash-rate signal on real devices and real OS versions |
| 2 | 2% | First reviews and support tickets referencing the new build |
| 3 | 5% | Enough volume for rarer device or locale-specific faults |
| 4 | 10% | Backend load from the new client becomes visible |
| 5 | 20% | Last comfortable point to pause before it is a large event |
| 6 | 50% | Mixed old/new install base — watch for API version mismatches |
| 7 | 100% | Full distribution; Apple notifies Admin and App Manager users on completion |
Days and percentages are quoted verbatim from Apple's table. The "useful for" column is Namtech's own operational note, not Apple's.
Three details in Apple's help page do real work in practice. First, the pause budget: "During phased release, you may pause the release for up to 30 days, with no limit on the number of pauses" — and the budget is cumulative, so as Apple explains, "if you pause the release for 10 days and then choose to resume it, you will have 20 days remaining to pause the release again". Second, resuming does not restart the clock: "your phased release will pick up on the day it was left off when it was paused". Third, the escape hatch runs one way only — you can hit Release to All Users at any time once the version is Ready for Distribution, but there is no button that puts users back on the previous build.
There is also a failure mode worth knowing before it happens to you. Apple states that if you remove your app from sale — "including when your Apple Developer Program membership lapses" — phased release stops and "won't be available for that version again", and when the app is reinstated it "becomes available to all users immediately, regardless of the percentage reached before removal". A lapsed membership renewal can therefore convert a careful 5% rollout into a 100% rollout without anybody pressing anything. Put the renewal date in the same calendar as the release plan. Access matters too: Apple lists the required role for phased release as Account Holder, Admin, or App Manager, so make sure the person who is meant to hit pause at 2am actually holds one of them.
What staged rollout actually does on Google Play
Google's staged rollout starts from the opposite assumption: nothing moves unless you move it. You choose the percentage when you create the release, and Play Console Help is blunt that the number stays where you put it — "Keep in mind, your app's staged rollout percentage won't increase automatically." Raising it is a manual action in the Releases tab under Manage rollout, and so is halting.
The single most important sentence in Google's documentation is the one describing what halting does not do. "When you halt a staged rollout, no additional users will receive the app version in your existing staged rollout. Users who already received the app version in your staged rollout version will remain on that version." A halt stops the bleeding; it does not undo it. Google's own remedy is to ship forward: "If you find an issue with your existing app bundle, create and roll out a new release with a fixed app bundle." Plan your release process on the assumption that there is no rollback on either store, only a faster next release — which is an argument for keeping your build and release pipeline warm rather than dusting it off twice a year.
Two further constraints shape how you use it. Staged rollouts "can only be used for app updates, not when publishing an app for the first time" — your very first Android release goes out whole, which raises the stakes on the testing tracks below. And the user selection is sticky in a useful way: "When you halt and then resume the rollout of your release, you'll be affecting the same set of users", and a new staged release started before the previous one finished "will use the same group of users as the previous release". You are not reshuffling the deck each time.
The two mechanisms side by side
Here are the two rollout systems compared on the questions an owner actually asks, using only what Apple and Google publish on their own pages. The shapes look similar from a distance and behave very differently in a crisis.
| Question | Apple — phased release | Google — staged rollout |
|---|---|---|
| Who advances the percentage? | The system, automatically, over 7 days. | You do. "Your app's staged rollout percentage won't increase automatically." |
| Can you choose the percentages? | No — the 1/2/5/10/20/50/100 schedule is fixed. | Yes. "You select the percentage of users who will receive your rollout." |
| Available on a brand-new app? | Documented as an option for a version update. | No. "Staged rollouts can only be used for app updates, not when publishing an app for the first time." |
| How do you stop it? | Pause Phased Release — up to 30 days total, unlimited pauses. | Manage rollout > Halt rollout, then Resume rollout when fixed. |
| Does stopping remove the build from users who have it? | Not documented as doing so. | No. Users who already received it "will remain on that version". |
| Can you ship to selected countries first? | Not part of the phased-release mechanism. | Yes. "You can start with a limited set of countries" — but "once a staged rollout has started, you can't remove any countries". |
| Can users get the new build anyway? | Yes. Apps in phased release "can be manually downloaded from the App Store by anyone at any time". | Rollout is limited to the selected percentage and, if set, the selected countries. |
| Who is told about it? | Nobody in the sample — no notification of participation. | Nobody. "Users won't be notified if they receive a version of your app in a staged rollout." |
| Fast-forward to everyone? | Release to All Users, any time after Ready for Distribution. | Update rollout to 100%. |
Every cell is quoted or paraphrased from developer.apple.com and support.google.com. Where a platform publishes nothing on a point, the cell says so rather than guessing.
The tracks that come before production
A staged rollout limits the blast radius of a defect; a test track prevents the defect from reaching the store at all, and it is far cheaper. Google is explicit that this is not optional on Play: "You must test your app before you can release it to production." Both stores give you a tiered ladder, and the published limits are generous enough that no small business has an excuse to skip it.
| Stage | Apple — TestFlight | Google Play — test tracks |
|---|---|---|
| Internal / team | Up to 100 team members holding Account Holder, Admin, App Manager, Developer or Marketing roles. | Internal testing: up to 100 testers per app, available "within minutes" of publishing a new app bundle. |
| Wider invited group | External testers by email invitation, within the 10,000 limit. | Closed testing: named testers via email lists or Google Groups; multiple closed tracks allowed. |
| Public beta | Up to 10,000 external testers, invited by email or public link, with criteria such as device type and OS version. | Open testing: "anyone can join your testing program and submit private feedback to you". |
| Review requirement | External testing needs "your first build already approved by App Review for TestFlight"; builds are auto-submitted when added to a group. | "Internal tests may not be subject to the usual Play policy or security reviews." |
| Concurrency | Up to 100 builds shared; multiple builds tested at once; testers use up to 30 devices. | "At any time, you can run multiple closed tests and one open test." |
| Effect on public rating | Feedback arrives in App Store Connect, not the public store listing. | "Feedback from your test users won't affect your app's public rating." |
Note the Play trap in the same help page: "A user who opts into your app's internal test is no longer eligible to receive an open or closed test" until they opt out — so do not put your whole pilot customer list on the internal track.
Google adds one requirement that catches new companies: developers with personal accounts created after 13 November 2023 "must meet specific testing requirements before they can make their app available on Google Play". If your app is being published under a personal account rather than an organisation account, that requirement sits on the critical path of your launch date, not beside it. It is one of the checks we cover in our app store submission checklist.
The number that decides whether you raise or halt
A staged rollout is only as good as the metric you are watching during it, and on Android that metric is published with a number attached, which makes it usable as a contractual gate. Google defines bad-behaviour thresholds on core vitals and states the consequence plainly: if your app exceeds them, "it's likely to be less discoverable on Google Play", and "in some cases, a warning could be shown on your app's store listing to set user expectations".
| Metric | Overall bad behaviour | Per-device bad behaviour |
|---|---|---|
| User-perceived crash rate | At least 1.09% of daily users experience a user-perceived crash, across all device models | At least 8% of daily users, for a single device model |
| User-perceived ANR rate | At least 0.47% of daily active users experience a user-perceived ANR, across all device models | At least 8% of daily active users, for a single-device model |
| Excessive battery usage (watch face) | More than 1% of watch face sessions have excessive battery usage, across all device models | — |
ANR = "Application Not Responding". Thresholds quoted verbatim from Play Console Help. Google also notes that Android vitals "is updated daily", holds data "for the previous 90 days in Play Console and for three years in the Play Developer Reporting API", and excludes issues on uncertified device models or on builds not installed through Google Play.
The per-device threshold is the one that changes how you read a rollout. An app can look healthy overall while being unusable on one popular handset in your market — and 8% of daily users on that single model is enough for Google to call it bad behaviour. Android vitals breaks every metric down by Artifact (the app version the issue occurred on) as well as by device model, Android version, form factor and country, which is precisely the cut you need mid-rollout: is the crash rate rising because of the new build, or was it always there?
Write the gate into the release plan before the release, not during it. Something as simple as "we hold at 10% for 48 hours; we raise only if the new artifact's user-perceived crash rate is at or below the previous version's, and no single device model is above 8%" turns a judgement call at midnight into a decision anyone on the team can execute. That gate belongs in the same dashboard as the rest of your launch instrumentation — see our note on measuring app success after launch.
Managed publishing: the part that saves launch day
Approval timing is the other half of release control, and on Google Play it has a name: managed publishing. It holds approved changes back until you choose to publish them, which is what lets a release line up with a campaign, an event or a press date instead of appearing whenever review happens to finish. Google recommends it for exactly that: "coordinating an ad campaign, launch event, or a new app version release with changes to your app's Store listing or distribution", and for "apps that are subject to extended review times, such as apps submitted by new developer accounts".
The scheduling reality behind it deserves to be read out loud in your kick-off meeting. Google states that processing "can take a few hours or up to seven days (or longer in exceptional cases)", and recommends you "adjust your planning to include a buffer period of at least a week between submitting your app and going live". A launch date that assumes same-day approval is a launch date with no slack in it — the same lesson that shapes our app development timelines.
Managed publishing holds back most things, including full and staged rollouts, pre-registration, store listing changes, app content changes and testing-track configuration. But Google publishes a list of exceptions that go live regardless, and three of them will surprise you:
- Increasing an existing staged rollout to 100% is not held back. Once a rollout is running, the fast-forward is live.
- Release notes changes are not held back. Handy for a typo, and a hazard if the note describes a feature that is still embargoed.
- Price changes and in-app product changes are not held back. If your launch involves pricing, that leg needs its own timing plan.
One prerequisite: like staged rollouts, "your app must already be available to use Managed publishing. You can't use it when publishing an app for the first time." Your very first launch on Play has neither safety net, which is the strongest argument there is for spending real time on the closed and open test tracks before it.
Getting the update onto devices that are already out there
A rollout percentage governs who is offered the update. It does not govern who installs it, and on Android there is an API for closing that gap. Google's In-app updates library "prompts active users to update your app" from inside the app itself, and offers two flows with very different manners.
- Flexible — "background download and installation with graceful state monitoring". Google's guidance: use it "when it's acceptable for the user to use the app while downloading the update", for example to encourage a new feature "that's not critical to the core functionality of your app".
- Immediate — "fullscreen UX flows that require the user to update and restart the app in order to continue using it". Google positions this for "cases where an update is critical to the core functionality of your app". After the user accepts, Google Play handles installation and restart.
Immediate is the lever you reach for when a release has to reach everyone — a security fix, or a client that no longer works against your API. It is also the lever that blocks a paying customer at the counter if you use it casually, so the decision of which flow applies to which release should be written down once and not re-argued each time. Note the published constraints before you assume it is available to you: the feature is "supported on devices running Android 5.0 (API level 21) or higher", is "only supported for Android mobile devices, Android tablets, and ChromeOS devices", and is "not compatible with apps that use APK expansion files (.obb files)".
The deeper design point is a backend one. If your rollout deliberately leaves 90% of users on the old client for several days, then for several days your server is talking to two client versions at once. That is a normal, manageable situation — but only if it was designed for, which means additive API changes and old-client compatibility for at least one release cycle. It is the least glamorous line in a release plan and the one that most often turns a staged rollout into a full outage.
Singapore first — and why country targeting only goes one way
For a business operating in Singapore, Google's country targeting is the most useful feature in this whole area and the least used. Play Console Help states that "when you're releasing an app using a staged rollout, you can start with a limited set of countries", with availability defaulting to the locations already set up for your production track. If your customers are in Singapore and your app is also distributed across the region, you can put a release in front of your home market first — the market where your support team is awake, your reviewers speak the language, and a defect gets reported to you in an hour rather than discovered in a review a week later.
Two cautions come from Google's own page. Country selection is a ratchet: "once a staged rollout has started, you can't remove any countries." Add markets deliberately, one at a time. And Google recommends sequencing your store listing behind the rollout, not ahead of it: "If your app update requires changes to the store listing, we recommend updating your store listing after your release rolls out to 100% of users" — otherwise your listing advertises a feature most of your users do not have yet, and your reviews will say so.
Apple's phased release does not offer an equivalent country dial. On iOS the equivalent control is the pause button and how attentively you use it during the first 48 hours, when the schedule has only reached 1% and then 2% of your automatic-update users.
What this means for your budget and your cadence
Release management is mostly process, but it is not free, and it is worth knowing which parts cost money. The build work is a CI/CD pipeline that can produce a signed, store-ready artifact on demand, plus crash and ANR reporting wired to something a human reads. The recurring cost is attention: somebody has to hold the store roles, watch the vitals for a few days after each release, and be authorised to halt without convening a meeting.
At Namtech that pipeline is part of the normal build rather than a separate invoice line. Our published tiers start at SGD 20,000 for a Starter / MVP, SGD 38,000 for a Business App and SGD 90,000 for an Enterprise / Platform build, each scoped individually — honest starting points, not teaser rates. The watching is where the ongoing arrangement earns its keep: Maintenance and Support from 15% of build cost per year is what pays for someone to be looking at the crash rate on the Tuesday after you ship, and to be the person who hits halt.
One caveat we will not dress up: no rollout mechanism prevents defects, and nobody can promise you a clean release. What a staged rollout buys is a smaller denominator when one gets through — and on both stores, the fix is always a new build going forward, never an undo.
Questions to ask your vendor
- "Are we using phased release on iOS and a staged rollout on Android by default?" If the answer is "we just push to 100%", ask what happens on the day that goes wrong.
- "Who holds Account Holder, Admin or App Manager on App Store Connect, and who can halt on Play?" Apple lists those roles as required for phased release. If the only person with them is on leave, you have no pause button.
- "What is our raise-or-halt rule, in numbers?" Google publishes 1.09% user-perceived crash rate and 0.47% ANR rate as bad-behaviour thresholds, broken down by app version and device model. Your rule should reference those, not a feeling.
- "How long can the backend serve two client versions at once?" A staged rollout guarantees a mixed install base for days. The answer should be "at least one release cycle, by design".
- "What is our path if a build is bad after it has shipped?" There is no rollback. The honest answer is a fixed build shipped fast — so ask how long that takes from decision to submission.
- "Are we using managed publishing, and does our launch date include Google's recommended week of buffer?" Processing can take up to seven days, or longer in exceptional cases.
- "Which releases justify an immediate in-app update, and who decides?" Immediate updates block the app until the user updates. That is a business decision wearing a technical costume.
Neither store lets you take a bad build back — Apple can only pause a 7-day schedule and Google can only stop new users receiving it — so the entire value of a controlled rollout comes from someone watching a published number on the days after you ship.
Sources
- Apple — Release a version update in phases, App Store Connect Help (7-day schedule and the 1/2/5/10/20/50/100 table; random sample of automatic-update users with no notification; manual download available to anyone at any time; 30-day cumulative pause budget with unlimited pauses; resume picks up where it left off; removal from sale ends phased release for that version; Release to All Users; required roles).
- Apple — TestFlight (up to 100 builds shared; up to 30 devices per tester; up to 100 internal testers by role; up to 10,000 external testers by email or public link; first build must be approved by App Review for TestFlight).
- Google Play — Release app updates with staged rollouts, Play Console Help (percentage does not increase automatically; updates only, not first publication; random user selection and stickiness across halt/resume; halting does not remove the build from users who have it; ship a fixed bundle forward; country targeting cannot be narrowed once started; update the store listing after reaching 100%; users are not notified).
- Google Play — Set up an open, closed, or internal test, Play Console Help (up to 100 internal testers; builds available within minutes; testing required before production release; multiple closed tests and one open test; internal testers ineligible for open or closed tests; internal tests may not be subject to usual policy or security reviews; test feedback does not affect public rating; testing requirement for personal accounts created after 13 November 2023).
- Google Play — Use managed publishing, Play Console Help (processing takes a few hours to seven days or longer; recommended buffer of at least a week; app must already be available; list of changes held back and the exceptions, including raising a staged rollout to 100%, release notes, price and in-app product changes).
- Google Play — Monitor your app's technical quality with Android vitals, Play Console Help (bad-behaviour thresholds of 1.09% user-perceived crash rate, 0.47% user-perceived ANR rate and 8% per single device model, plus 1% of watch face sessions for excessive battery; effect on discoverability and store-listing warnings; daily updates; 90 days in Play Console and three years in the Reporting API; breakdowns including Artifact, device model, Android version, form factor and country; exclusion of uncertified devices and non-Play installs).
- Android Developers — In-app updates (flexible versus immediate flows and when each is appropriate; Android 5.0 / API level 21 minimum; supported device types; incompatibility with APK expansion files).
- Namtech — Pricing (SGD 20,000 / 38,000 / 90,000; Maintenance and Support from 15% of build cost per year).