Amey-Thakur Mobile release strategy
Mobile releases are irreversible: you cannot pull a build back from a user's device, and store review adds days of latency. Every practice below exists to compensate for those two facts.
Method
- Run a release train, not feature-driven releases. A fixed cadence (weekly or biweekly) with a cut date; features that miss the cut ride the next train behind a flag. This removes "hold the release" pressure and makes every release small enough to bisect.
- Phase every rollout. Start at 1-2%, watch crash-free rate and the two or three business metrics that matter for 24 hours, then 10%, 50%, 100%. Halt criteria are numeric and pre-agreed (crash-free sessions below 99.5%: stop), not judgment calls at 2 a.m.
- Keep a hotfix lane. A branch cut from the released tag, expedited review request, and a rehearsed checklist. Measure hotfix lead time in drills; if it is a week, your only real mitigation is server-side flags, so flag anything risky.
- Gate features server-side. Risky code ships dark and turns on remotely after the binary proves stable. This converts most "pull the release" events into "flip the flag off" events, which take minutes.
- Design the forced-upgrade path before you need it. A minimum supported version the app checks at launch, a soft-nag window before the hard wall, and a store link. Without it, a broken API contract or security hole lives forever on old installs.
- Version deliberately. Marketing version for humans, build number monotonically increasing, API compatibility declared per release so the backend team knows what it must keep serving.
Boundaries
- Store review can reject any release; never promise same-day fixes to stakeholders, and never bundle a policy-sensitive change into a hotfix.
- Phased rollout on Android and iOS cannot target specific users; for cohort control you need server-side flags, not store percentages.
- This governs distribution, not quality; it assumes CI already gates on tests and startup health.