Staged Rollouts for Mobile Apps: A Release Playbook

On the web, a broken deploy gets rolled back in minutes. On mobile, the binary is already on your users' phones. You cannot pull it back. The best you can do is stop it from reaching more people, then ship a fix and wait for review and for users to update.

That asymmetry is why release process matters more on mobile than almost anywhere else. A crash on launch that hits 100% of your users on day one means one-star reviews, support tickets, and a chunk of installs that never come back. The review you leave behind stays on the store page for years.

The fix is boring and effective: release to a small slice of users first, watch a short list of numbers, and have written rules for when to stop. This is a staged rollout, and both stores support it. Most early-stage teams we meet either do not use it or use it without thresholds, which means they click "continue" out of habit.

This playbook is what we recommend to founders shipping a production app: how each store handles staged release, what percentages to use, which metrics to watch, the numbers that should halt a rollout, and what to do when you need to undo something. If you are earlier than this and still preparing for your first launch, start with our mobile app launch checklist.

The two stores behave differently, and that difference shapes your plan.

Apple: phased release over seven days

Apple's phased release for automatic updates rolls the new version out to users who have automatic updates turned on, over seven days, on a fixed schedule: roughly 1%, 2%, 5%, 10%, 20%, 50% and then 100%. You can pause the phased release for up to 30 days, and you can release to everyone immediately at any point. Two caveats matter. First, users who go to the App Store and tap Update manually can still get the new version at any time, regardless of the phase. Second, the percentages are not under your control. You get Apple's schedule, not yours.

Phased release only applies to updates, not to the first version of an app. And you cannot pull a version that has already gone out. Pausing stops the spread to auto-update users. That is all.

Google Play: staged rollout with percentages you choose

Google Play lets you set a percentage of users to receive a release, and you raise it when you are ready. You can halt a rollout, and you can also increase it manually at your own pace. This is more flexible than Apple's, and you should use it fully. Start at 1% to 5%, hold for a day or two, then move up in steps.

Google also supports release tracks (internal, closed, open and production), which give you a place to test builds with real devices before any production rollout begins.

What this means for your plan

On Android you control the schedule. On iOS you control only the pause button. So the iOS plan leans harder on pre-release testing and on being able to fix issues without a store review, which we get to below.

Here is a default schedule. Adjust it to your user base, since an app with 2,000 monthly users cannot learn much from 1% of them.

1. Internal and beta first. TestFlight and Google Play internal or closed tracks for at least 2 to 3 days with real devices, including at least one older, slower Android phone and one iPhone at the oldest OS version you support.
2. Android at 5%. Hold 24 hours. Check the dashboard below.
3. Android at 20%. Hold 24 hours.
4. Android at 50%. Hold 24 hours.
5. Android at 100%.
6. iOS phased release turned on the same day Android hits 20%, once the Android signal looks clean. Seven days on Apple's schedule, with checks daily.

Why Android first? Because you control the pace there, and Android has the wider spread of devices, so it surfaces device-specific crashes sooner. A bug that shows up on a Samsung mid-range phone at 5% gives you warning before iPhone users see the build.

Small user bases need a different approach

If you have under roughly 5,000 weekly active users, percentages stop being meaningful. A 5% slice is 250 people, and a handful of crashes looks like a catastrophe or like nothing, depending on luck. In that case, lean on beta testers you recruit on purpose, longer hold times, and a stricter reading of absolute crash counts rather than rates. Ask your most engaged customers to join the beta track. They will tell you things the crash reporter cannot.

Do not watch a dashboard with 40 charts. Pick five numbers and compare the new version to the previous one at the same point in its own rollout.

1. Crash-free sessions and crash-free users

Tools like Sentry and Firebase Crashlytics report these per release. Compare the new release to the previous stable release. We discuss tooling in our Sentry, LogRocket and FullStory comparison. As a working target for a consumer app, 99.5% crash-free sessions or better is healthy, and a drop of more than half a point against the last release is a flag.

2. New issue count

The number of previously unseen crash signatures in the new release. One new issue with a handful of events is normal. A new issue with hundreds of events in the first hours is not.

3. ANR rate on Android

Application Not Responding events are tracked in Android vitals. Google publishes bad-behavior thresholds for user-perceived crash rate and ANR rate, and exceeding them can reduce your visibility in Play Store search and recommendations. Check Google's current documentation for the exact figures, since they have been revised before. Treat those thresholds as the ceiling, not the goal.

4. Launch and key-flow success

The percentage of sessions that complete your critical path: sign-in, checkout, first core action. Crash reporters miss silent failures, like a button that does nothing after an API change. Log these events yourself and alert on drops.

5. Support and review signal

Someone should read new reviews and support tickets for the first 48 hours. Users often describe a problem before your tooling catches it, and a spike in a specific phrase ("stuck on loading", "cannot log in") is a signal worth a halt.

Wire release health into your alerts before the rollout starts. Sentry release health, Crashlytics velocity alerts and Android vitals all support notifications, and a Slack message at 2 am about a crash spike beats finding it in the morning.

The hardest part of a rollout is the decision to stop. People rationalize. Nobody wants to be the one who halts the release the CEO announced. So write the rules in advance and make them mechanical.

A starter set

• Halt immediately if crash-free sessions on the new release fall more than one point below the previous release at the same stage.
• Halt immediately if a crash or error blocks sign-in, payment or your core action for more than a small fraction of affected users. Pick the fraction and put it in writing. We tend to use 2%.
• Halt and investigate if a new crash signature appears with more than a set number of events in the first 12 hours. The number depends on your volume.
• Hold at the current percentage if the data is ambiguous. Waiting a day costs little.
• Proceed only if every check is green and a named person confirms it.

Name an owner for each rollout. One person, with authority to halt without asking permission. Rollouts that belong to "the team" get continued by default.

What halting actually does

Halting stops new users from receiving the build. It does not fix the people who already have it. For them you need a patch release or a remote fix, which is the next section. Plan for both before you ship, because the minutes after you spot a problem are the wrong time to read documentation.

You cannot force users back to the old binary. You do have several levers, and which ones you have depends on what you built in.

Server-side kill switches and feature flags

The most reliable rollback is a feature flag. If the new feature is behind a remote flag, you turn it off for everyone in seconds with no store involved. This is the single best investment in release safety. Ship new features dark, enable them for 1% of users, then ramp them separately from the binary rollout. That decouples "the code is on the phone" from "the feature is live". Our post on feature flags for AI and LLM rollouts covers the mechanics, and the same pattern applies to any risky change.

Over-the-air updates

If your app is built with React Native and Expo, you can push JavaScript and asset changes over the air without a store review, using EAS Update, or alternatives such as Shorebird for Flutter. That lets you ship a fix in minutes and roll back to a previous update bundle. Native code changes still require a store release. Both stores have rules about OTA updates: they are fine for fixing bugs and tuning behavior, and not for changing the primary purpose of the app after review. We compare the options in our OTA update comparison.

Expedited review and a hotfix release

When the problem is in native code, you need a new binary. On iOS you can request an expedited review from Apple, which they grant for critical issues at their discretion. On Android, reviews are usually faster, and you can start a new staged rollout from 100% of the fixed build if the damage is serious.

Forced upgrade as a last resort

Build a minimum-supported-version check into the app from day one. A small remote config that says "versions below 2.4.1 must update" lets you push users off a dangerous build. Use it sparingly, since a forced update interrupts people, but it is the only way to recover from a bad version that cannot be fixed server side. The catch: you must have shipped the check in a version before the bad one.

Here is the setup we recommend before you rely on any of the above.

Before the first staged release

• A crash and performance reporter in every build, with source maps or symbol files uploaded in CI so stack traces are readable.
• Release health tracked per version, not only overall.
• Custom events for your critical flows, with alerts.
• A remote feature flag service and a remote config for minimum version.
• An OTA update channel if your stack supports it.
• A release owner, a written halt rule, and a place to announce a halt.

On release day

• Release in the morning in your biggest market's time zone, early in the week. Avoid Friday releases unless someone is on call all weekend.
• Have the previous stable build and its release notes handy.
• Confirm that backend changes are backward compatible with the old app versions still in the wild. A new API that breaks version 2.3 will hurt users who have not updated, and they will be a large share of your base for weeks.

After the release

Write a short note: what shipped, what the numbers did, anything surprising. After a few releases you will have your own baselines, and your thresholds should move from guesses to data.

What it costs

Most of this is process and a few days of setup. Crash reporting has free tiers and paid plans that scale with event volume, feature flag services range from free to a few hundred dollars a month at startup scale, and an OTA update service is typically priced by active users. The engineering time to wire it up properly is usually a week or two for a team that has none of it, less if you already use some pieces. That is small next to what one bad release costs in churn and review damage.

A release process is a product feature your users never see until it fails. If you want help building the pipeline, monitoring and rollback tooling around your app, or an outside review of how you ship today, book a free strategy call.