Staged rollouts, three ways: Google Play, Apple phased release, and OTA
All three let you ship to a fraction of users first. Only one of them has an undo button. How the mechanisms actually differ, and how to run them together without surprising yourself.
"We do staged rollouts" means three different things depending on which mechanism a team is leaning on, and the differences bite exactly when something goes wrong. Here's how the three actually behave — including the property that matters most and gets discussed least: what happens when you need to take a release back.
Google Play: manual percentage, no fleet rollback
Google Play's staged rolloutmakes an update available to a percentage of eligible users that youincrease — it does not progress automatically. You can halt it to limit further exposure, but users who already installed the binary keep it. A corrective binary still has to go through the store process. Google says new and existing users are eligible for a staged rollout and selected at random, so do not assume new installs always get the latest build.
Apple: phased release, automatic curve
App Store phased releaseis the same idea with the control inverted: over seven days, automatic updates reach 1%, 2%, 5%, 10%, 20%, 50%, then 100% of users. You can pause it or release to everyone early, but you cannot choose arbitrary percentages. Anyone can manually download the update from the App Store during the phase, and a corrective binary still requires the store process.
OTA: arbitrary percentages, with provider-specific recovery
An OTA rollout controls what fraction of update checks are offered the new JavaScript bundle — often any percentage, changed at any time, with no store submission in the loop. Recovery behavior depends on the client and provider: disabling an update can stop further delivery, but whether installed clients fall back automatically is an implementation detail. Use a client with documented rollback behavior and test it. The operational discipline — soak windows, abort criteria, what to watch — is the subject of the rollout playbook.
The comparison that matters
- Granularity: Play, a manual percentage. Apple, a fixed automatic curve. OTA, provider-defined targeting that is often more flexible.
- Scope: store mechanisms roll out the whole binary; OTA rolls out JavaScript and assets on top of whatever binary the user has.
- Latency to react: store halt/pause limits future exposure; a corrected binary still follows the store process. OTA recovery depends on the client's documented behavior.
- Rollback: neither store mechanism rolls an installed binary back across the fleet. Some OTA clients support automatic fallback; verify it before relying on it.
Running them together
This isn't a choose-one situation; a native release should use both layers deliberately. The pattern we recommend: ship the new binary with the store's staged mechanism (phased release on iOS, a conservative percentage on Play) to bound native risk — the crashes no OTA can fix. Once the binary looks healthy, widen it, and from then on iterate on that binary's JavaScript with OTA rollouts, where mistakes are recoverable. What you want to avoid is the inverse posture — full-blast store releases with no staging, then relying on OTA to patch panic — because the failure OTA can't reach is native, and the boundary doesn't negotiate. Stage the risky, irreversible thing; iterate on the reversible one.