Phased Rollouts on iOS and Android: Shipping Without Fear

The worst way to find a crash is from every user at once. The App Store and Google Play both let you release an update to a small group first, watch what happens, and only then give it to everyone. Combined with over-the-air updates for JavaScript changes, that turns most bad releases into a minor incident instead of a one-star avalanche.

This guide explains how a phased release on iOS and a staged rollout on Android actually work, their important differences, what to watch at each step, and a rollout plan you can reuse for every release.

Key takeaways

• Apple's phased release spreads an update to users with automatic updates over seven days: 1%, 2%, 5%, 10%, 20%, 50% and 100%. You can pause it and release to everyone early.
• Google Play's staged rollout lets you choose the percentage yourself, increase it when ready, and halt it if something goes wrong.
• Neither store can roll a version back. You stop the spread, then ship a fixed version (or an over-the-air fix for JavaScript bugs).
• Watch crash-free sessions, ANRs, key flow completion and reviews before every increase.
• Over-the-air updates have their own percentage rollouts, so the same discipline applies to JavaScript fixes.

How Apple's phased release works

When you enable phased release for a version update, Apple releases it over seven days to users who have automatic updates turned on:

Two details matter. First, anyone can still download the new version manually from the App Store at any time, and new users always get the latest version, so phased release limits exposure rather than strictly controlling it. Second, you can pause the rollout (for up to 30 days in total) while you investigate, or release to all users immediately if everything looks healthy.

How Google Play's staged rollout works

On Google Play, you choose a rollout percentage when you release to production, for example 5% or 10%. Users in that group receive the update; everyone else keeps the previous version. You can raise the percentage whenever you like, or halt the rollout completely.

Halting stops new users from getting the update, but people who already have it keep it. To fix a bad release, you upload a new version with a higher versionCode and roll that out instead.

iOS and Android side by side

What to monitor before each increase

Compare against the previous version over the same period, not against an absolute number.

From the field: Phased rollouts are part of the release path I own, along with store review and Sentry crash triage, on apps including one with 100K+ active users at 99.9% crash-free sessions in production. A regression that reaches 1% of users is a quick fix. The same regression at 100% is a crisis.

A rollout plan you can reuse

1. Day 0: release with phased release on iOS and a 5 to 10% staged rollout on Android. Watch crashes closely for the first hours.
2. Day 1 to 2: if crash rate and key flows match the previous version, increase Android to 20 to 50%. Let Apple's schedule continue.
3. Day 3 to 5: go to 100% on Android if stable. Consider releasing to all iOS users early if metrics are clean.
4. Any time: if a serious issue appears, pause on iOS, halt on Android, and ship a fix, using an over-the-air update if the bug is in JavaScript.

Common rollout mistakes

• Jumping to 100% on day one because the first hours looked quiet. Many crashes appear only on specific devices or after a day of real use.
• Watching only crashes. A release can be crash-free and still break payments or sign-up. Track completion of your key flows too.
• Forgetting the backend. If the new version needs a new API, the API must keep serving older app versions that are still in use.
• No owner on release day. Someone should be responsible for watching metrics and deciding when to widen, pause or halt.

Where over-the-air updates fit

Store rollouts control native releases. For JavaScript and asset changes shipped over the air, Expo's EAS Update supports percentage rollouts too, for example 10% of users first, and one-command rollbacks. Use the same habit: small first, watch, then widen.

Feature flags add one more layer: ship the code to everyone, but turn the feature on for a small group first. That's the safest way to launch risky features, independent of store schedules.

FAQ

What is a phased release on the App Store?

It's an option that releases a version update over seven days to users with automatic updates enabled: 1%, 2%, 5%, 10%, 20%, 50% and then 100%. You can pause it if problems appear or release to everyone early. Users can still update manually from the App Store at any time.

How do staged rollouts work on Google Play?

You release a production update to a percentage of users that you choose, then increase it over time or halt it if something goes wrong. Users outside the rollout keep the previous version until you widen it.

Can I roll back an app update on the App Store or Google Play?

Not directly. Both stores let you stop the update spreading (pause on iOS, halt on Android), but users who already updated keep it. To fix the problem, ship a new version, or an over-the-air update if the bug is in JavaScript.

Should every update use a phased rollout?

For most apps, yes. The cost is a few days of slower adoption; the benefit is limiting damage from any bug you missed. Urgent security fixes are the main exception, where you may want everyone updated as quickly as possible.

Next steps

If your releases go to 100% of users on day one, I can set up phased rollouts, monitoring and a rollback plan so the next bug reaches a handful of users instead of all of them. Get in touch, or see my services.

Sources

• Release a version update in phases, Apple
• Release app updates with staged rollouts, Google Play Console Help
• Android vitals, Android Developers
• EAS Update rollouts, Expo