Shipping a mobile release is not like deploying a server. You can't roll a bad build back off every phone that already installed it. That one asymmetry shapes how I think about releases: the goal isn't to ship fast, it's to make shipping boring and reversible-enough. Staged rollouts are the main tool for that.
Tracks: nothing reaches production untested
Every build climbs the same ladder before it sees a real user:
- Internal — my own devices, minutes after a build. Smoke test.
- Closed testing — a small trusted group on real hardware and real networks (which, for a field app, means places with no signal).
- Production, staged — released to a fraction of users first, then ramped.
The staged ramp
A staged production rollout goes out to a percentage of users rather than everyone at once. I start small, let it soak, then increase — roughly along the lines of a few percent → 10–20% → 50% → 100%, watching the numbers between each step rather than clicking through on a schedule.
The point of the small first slice is blast radius. If a release has a problem I didn't catch, it reaches a sliver of users, not the whole base — and I can stop it there.
What I watch during a ramp
- Crash-free rate (Crashlytics) — the single most important signal. A dip right after a bump means stop.
- ANRs — Play Console's Android vitals. Jank and freezes that crash reports won't show.
- Ratings & reviews — the qualitative early-warning system; users describe what the metrics only hint at.
- Key flows — for this app, that a device still pairs over BLE and a reading still lands in the database. If the core loop breaks, nothing else matters.
Halting is the feature
If the vitals turn, I halt the rollout. That freezes it at the current percentage so no new users get the bad build while I ship a fix on top. I can't un-ship what's already out, but I can stop the bleeding — and that's the whole reason to ramp instead of releasing to everyone at once.
You can't recall a release. Staged rollout is how you limit how many people a mistake can reach.
Boring by design
Around this sits the unglamorous discipline that makes it work: automated, repeatable builds through CI so the artifact is never hand-assembled; a version bump every release so crash reports map to an exact build; and a short release note so testers know what changed. None of it is clever. That's the point — a release should be a non-event.
The takeaway
Treat every release as something you can't take back, and the process falls out naturally: climb the tracks, ramp in stages, watch crash-free rate and ANRs at each step, and halt the moment they turn. Do that consistently and "release day" stops being a day you dread.