How to limit the blast radius of a bad update.

A crash-on-launch bug on the web is a bad hour: roll back the deploy, apologize, move on. The same bug in a mobile release can be a bad month, because neither app store has a rollback button. Once a build is on someone's phone it stays there — the only thing you control is how many phones it reaches before you notice. And that's a lever you have to set before you submit.

There is no undo

Both stores move in one direction. The App Store and Google Play will offer a device the newest version it's eligible for, never an older one — there is no mechanism for pushing users back to the previous release. Recovery from a broken update means diagnose, fix, resubmit, sit through review, and roll out again. Apple's expedited review can shorten the middle part, but it's a request you justify, not a button you press. Realistically you're days from whole again, not minutes.

So the useful question isn't "how do I undo a bad release" — you can't — it's "how few users can I expose while I find out whether this release is bad." Both stores give you a throttle for that, and they behave differently enough that assuming one works like the other will burn you.

iOS: phased release is a throttle, not a gate

In App Store Connect, every version update has a release option called "Release update over 7-day period using phased release." Turn it on and the update reaches users with automatic updates enabled on a fixed schedule: 1% on day one, then 2%, 5%, 10%, 20%, 50%, and everyone on day seven, advancing on its own every 24 hours. You can pause the schedule for up to 30 days while you investigate something, resume where it left off, or release to all users immediately once you're confident. It only exists for updates — a brand-new app has nobody to protect.

The fine print matters more than the schedule: the percentage applies only to automatic updates. Your product page offers the new version to everyone from day one — any user who opens it and taps Update gets the build immediately, and every new download gets it too. That 1% is a floor, not a ceiling.

Which cuts both ways. Pausing a phased release doesn't pull the update — it stops pushing it, while the build stays fully available to anyone who asks. If you need an update to be genuinely unavailable, iOS has no tool for that. The upside: when a bug report comes in from the 1%, you can reproduce it by updating manually instead of waiting for the lottery.

Android: staged rollout is an actual gate

Play inverts nearly every one of those defaults. You pick the starting percentage yourself, and it never advances on its own — nothing changes until you change it. The fraction applies to new and existing users alike, chosen at random, and a user outside it doesn't see the update at all, even if they open your listing and check manually. Halting a staged rollout closes the door properly: nobody new gets the version, and the store keeps serving the previous release while you fix things. Users who already installed it keep it — that part is universal — and when you resume, Play targets the same set of users rather than re-rolling the dice.

In short: iOS phasing limits exposure, Play staging limits availability. Play's is the stronger safety tool. A sensible ladder is something like 5% → 20% → 50% → 100% over a week, where each step is a decision you make after reading the numbers, not a timer firing.

What to watch while the number is small

The early stages aren't about reach — 1% of your users is a rounding error of installs. They exist to buy signal:

Crash-free sessions, per version. Compare the new version's rate against the previous version's, not against zero — every release crashes for someone, and the question is whether this one is worse than your baseline. If you don't know last version's crash-free rate, you can't read this week's. On Android, watch ANR rate too; Play tracks it in Android vitals and holds it against your store visibility.

Humans. Reviews mentioning the update and your support inbox catch the failures a crash reporter never sees: wrong data, dead buttons, a purchase that doesn't restore. The app that fails without crashing looks perfect on a dashboard.

And respect the sample size. At 1%, one crashy device model can look like a catastrophe, and a real catastrophe can hide behind a quiet afternoon. Hold each stage until you've accumulated enough sessions for a fair comparison — not just until 24 hours have passed.

The rollback you have to build yourself

Everything above protects the users who don't have the build yet. For the ones who do, the store can't help — the only levers that work on an already-updated phone are the ones you compiled into the binary:

Remote flags on anything new and risky. If the rewritten sync engine misbehaves, flipping it off server-side beats a five-day fix–review–rollout cycle every time. Config read at boot instead of hardcoded. ShotCanvas loads its AI key and free-tier limits from a config document at launch, so a key rotation or a limit change never waits on a release. A minimum-version gate for the day you must force everyone forward — a polite "please update" screen beats an old build failing silently against an API that moved on.

One operational consequence people miss: a rollout held at 40% means two versions live in production for weeks — on top of the long tail of users who never update anything. Your backend has to stay compatible with every version that's still breathing, not just the newest one.

When not to phase

Staging is a default, not a religion. For a security fix or a forced migration, a throttle works against you — you want everyone forward as fast as the stores allow, so release to all users and lean on the in-app update prompts instead. And mind announcement timing, especially on Play: if the launch post goes out Tuesday and the build is staged at 5%, the feature everyone just read about doesn't exist on 95% of phones — and unlike iOS, they can't go get it manually. Roll out ahead of the announcement, or go straight to 100% and accept the risk with eyes open.

The one lever that's never throttled

A last asymmetry worth knowing: parts of your store listing move instantly even while a binary crawls through review and a week of percentages. Google Play listing changes and Apple's promotional text need no build at all — so while the update you're nursing toward 100% sits at 5%, sharper screenshots and better what's-new copy are changes you can still ship today. ShotCanvas designs the screenshot set and publishes it to both stores directly.