Mobile releases: staged rollouts, kill switches and the update you cannot recall

01Halting is not rolling back

Both stores let you halt a staged rollout, which stops further users receiving the version. It does nothing for users who already have it. Those users stay on the broken build until you ship a fix and they accept it.

This means the recovery time for a bad mobile release is store review plus user adoption, which is days at best. Planning for that reality is more useful than trying to prevent all bad releases.

The practical consequence is that server-side control is your real rollback mechanism. Anything you can disable without a release is recoverable in minutes; anything you cannot is recoverable in days.

02What to build before you need it

These are cheap to add in a normal release and impossible to add during an incident.

• A remote kill switch for each risky feature, evaluated server-side with a safe default when the config call fails.
• A forced-upgrade check that can block a known-broken version from operating, with a clear message and a store link.
• Server-side feature flags rather than build-time flags, so the decision is not baked into the binary.
• API version tolerance so a new backend does not require a client release to keep working.
• A staged rollout as the default release process, not something reserved for risky changes.

03Staging a rollout so it tells you something

A staged rollout only helps if you are watching the right signals and the stage is large enough to produce them. One percent of a small user base generates too little data to distinguish a real regression from noise.

Hold each stage long enough to cover a full daily cycle. Problems that only appear during peak usage or on a particular network will not show up in the first hour.

Compare metrics by app version, not in aggregate. A new version's crash rate is diluted into invisibility by the installed base until the rollout is substantial, which is precisely when halting stops helping.

04What to watch during a rollout

Crash-free rate by version is the obvious one and the least sufficient. Add non-fatal error rate, API error rate segmented by client version, and completion rate of your core flow.

That last one catches the failures crash reporting misses entirely: a release where nothing crashes and nobody can complete a purchase. Those are the expensive ones, and they are only visible if you are watching business outcomes rather than stability metrics.