What is a staged rollout

Quick answer

A staged rollout releases a new app version or update to a small percentage of users first, watches the metrics, then widens the percentage. It limits the number of people a bad release reaches and gives you time to halt or roll back. Apple, Google Play and over-the-air update services each offer one, with different controls.

Why do mobile teams use staged rollouts?

Version 4.12 passed your tests and crashes on launch on an Android phone model that none of your test devices cover. Ship it to everyone and every owner of that phone gets the crash. Ship it to 1% first and your crash reporter shows the problem while 99% of users are still on 4.11.

Every release is an experiment on your users. A staged rollout (Apple says phased release; over-the-air (OTA) update services say rollout or percentage rollout) makes that experiment small before it is large. You pick a percentage, ship to that slice, compare its crash rate and key metrics against the previous version, and only then expand.

Server teams call the same idea a canary release. On mobile it matters more, because you cannot undo an install. Once a user has the new binary, the only fix is another release. A staged rollout keeps the number of users in that position small while you find out whether the release is sound.

How does a phased release work on the App Store?

Apple's version is called phased release. Once you turn it on for a version, App Store Connect releases it over seven days on a fixed schedule:

You cannot pick your own percentages. You can pause the release for up to 30 days in total, with no limit on the number of pauses, and when you resume, the schedule picks up on the day it stopped. You can also release to everyone at once at any point. Two things to know: the schedule controls who is offered the update automatically, and "apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time". Pausing a phased release is not a rollback. Users who already have the new version keep it.

How does a staged rollout work on Google Play?

Google Play lets you choose the percentage yourself, on production and on test tracks. The percentage does not rise on its own; you raise it when you are ready. New and existing users are eligible, and Google chooses them at random for each release.

If something goes wrong you can halt the rollout, which stops new users from receiving the version. You can resume a halted rollout later if the app bundle turns out to be fine. As with Apple, "users who already received the app version in your staged rollout version will remain on that version". There is no store-side rollback for users who already installed it; you ship a new version.

Google wins on control here: you pick any percentage and halt or resume whenever you want, with no fixed timetable. Apple's fixed curve is simpler but slower to widen.

How do staged rollouts work for over-the-air updates?

Apps built with React Native can update their JavaScript bundle over the air between store releases. Only the JavaScript and assets change; native code still goes through the store and its review. Apple covers this in App Store Review Guideline 2.5.2, which permits interpreted code within limits, and Google in its Device and Network Abuse policy.

OTA updates change what a staged rollout can do in two ways:

• The clock is yours. You set the percentage when you publish and change it whenever you like. Going from 10% to 100% can take an hour if the metrics are clean, or you can sit at 10% for three days.
• Rollback is real. Because the client checks for updates on launch, you can publish the previous known-good bundle on top of the bad one, or tell clients to fall back to the bundle embedded in the binary. Users who already got the bad update pick up the fix on their next launch. Stores cannot do this; the OTA layer can.

The limits are the same as for any OTA update. If the bug is in native code, no JavaScript rollout will fix it, and you are back to a store release.

What should you watch during a staged rollout?

A rollout is only useful if someone is looking at the numbers while it runs. Compare the new version's slice against the current version over the same window, not against last week.

Crash rate. The first number to watch. Google Play's Android vitals flags an app when at least 1.09% of daily active users experience a user-perceived crash, and at least 8% on a single device model. Those are store-visibility thresholds; your own threshold for halting a rollout should be lower. For OTA updates, the update service's dashboard usually also shows failed installs (users who downloaded the update and crashed before it ran).

Time to interactive. A release that does not crash can still make the app slower to become usable. Track time to interactive at the 90th percentile per version. Expo's recommendation for React Native apps is under 3 seconds including cold launch.

Per-screen metrics. A regression is often confined to one screen: the one the release changed. Per-route render time and per-route interactive time will show it where an app-wide average will not.

The metric the release touched. If the release changed checkout, watch checkout completion. If it changed onboarding, watch onboarding drop-off.

Give each stage enough time to see real traffic. A 1% slice of a small user base may be a few hundred sessions, and a crash on one device model may not show up for a day.

Can you roll back a staged rollout?

What "rollback" means depends on the layer:

• Store binary. There is no rollback. You can halt (Google) or pause (Apple) to stop new users getting the version. Users who already have it keep it until you ship a fixed version through review.
• OTA JavaScript update. You have two options: republish the last known-good update so that clients fetch it as if it were new, or send clients back to the bundle embedded in the binary. Before you do either, check whether the bad update changed persisted state on the device (a storage schema, a migration). If it did, the old bundle may not be able to read the new data, and fixing forward is safer than rolling back, as Expo's error recovery guide explains.

App Store, Google Play and OTA rollouts compared

Sources: Apple, Google, Expo docs.

Where Expo fits

EAS Update is Expo's hosted service for over-the-air JavaScript updates to apps that include the expo-updates library. It offers two rollout mechanisms.

Per-update rollouts attach a percentage to a single update:

Only one update can be rolled out on a branch at a time, and the rollout must be finished or reverted before another update for the same runtime version can be published. eas update:list and eas update:view show the state of a rollout, and the same controls are available in the EAS dashboard.

Branch-based rollouts (eas channel:rollout) move a percentage of a channel's users to a different branch, which is a stream of updates rather than a single one. Branch-based rollouts suit teams that publish several updates to a release branch before promoting it.

If a rollout goes wrong after it has reached 100%, eas update:rollback walks you through republishing a previous update or falling back to the embedded bundle. Expo's own guidance for uncertain updates is to roll out to a small percentage, watch the error rate on the dashboard, cancel the rollout if it climbs, and roll back if it already reached everyone. The longer form of that process is in The production playbook for OTA updates.

Limitations. EAS Update rollouts apply to the JavaScript layer only; a native regression needs a store release, and the stores' own rollout tools apply there. Updates only reach builds with a matching runtime version, so users on an older binary are not in the pool. The --environment flag is required from SDK 55. The free plan includes 1,000 monthly active update users, with higher limits on Starter (3,000), Production (50,000) and Enterprise (1,000,000) before usage-based pricing.

Next step

If your app is React Native, publish your next JavaScript update with --rollout-percentage=10 and leave it there long enough to compare crash rate against the current version. The EAS Update rollouts guide covers the commands and the branch-based variant.

Verified on 12 September 2026.