Shipping mobile: the release you cannot take back

A bad web deploy affects users until you revert it, which is minutes. A bad mobile release affects everyone who installed it until they install something else, which is days for the attentive, months for most, and never for a meaningful minority. Every practice below exists because of that asymmetry.

Staged rollout, with something to watch

Both platforms can release to a percentage of users. Using it is the closest thing to a rollback that mobile offers, since halting a rollout prevents further installs even though it does not recall the ones already made.

1. 01Internal testers first, on real devices, for at least a day of ordinary use.
2. 021% of users, held long enough to gather crash data — hours, not minutes.
3. 03Compare crash-free sessions against the previous version, not against an absolute threshold. A drop from 99.8% to 99.1% is severe and breaches no alarm.
4. 0410%, then 50%, then 100%, with a pause at each step and someone actually looking.
5. 05Halt immediately on a regression. Halting is cheap; a full rollout of a crashing build is not reversible.

The old version runs forever

This is the fact most teams underestimate. A meaningful share of any installed base is running a build from a year ago — devices with automatic updates disabled, storage-constrained phones, users who dismiss prompts, and regions where data cost makes updating a decision.

• Your API must keep working for versions you no longer support, or those users experience the app simply breaking
• Never remove an API field a shipped version reads. Deprecate, measure by client version, and remove only when usage is genuinely zero
• Version your API requests from the client, so the server can serve compatible responses rather than guessing
• Instrument which app versions are in use, because the decision to drop support has to be based on real numbers
• Assume every shipped version is live until the data says otherwise

The practical consequence is that mobile releases constrain backend design permanently. An API change that would be routine for a web application is a breaking change for an installed base you cannot update — which is why additive-only design matters more here than anywhere else.

Server-side switches, which are the real rollback

Since you cannot recall a build, the only way to change its behaviour after release is for the build to ask the server what to do. That has to be designed in before the release, not after the incident.

// Fetched at launch and periodically, cached locally with a sane
// default so a failed fetch never bricks the app.
{
  "features": {
    "new_checkout": false,        // disable a broken feature remotely
    "background_sync": true
  },
  "minimum_version": "2.1.0",     // below this, require an update
  "recommended_version": "2.4.0", // above this, suggest one
  "message": null                  // an in-app notice when needed
}

// Requirements that are easy to get wrong:
//  - a safe default if the fetch fails, so an outage in this
//    endpoint does not disable the app
//  - a cached last-known config, so offline launches still work
//  - this endpoint must be more available than everything else,
//    because it gates everything else

Forced upgrades, used sparingly and humanely

Blocking an old version until the user updates is occasionally necessary — a security defect, a data-corrupting bug, a backend contract that genuinely cannot be maintained. It is also user-hostile, so the bar should be high and the execution careful.

• Say why an update is required, specifically, rather than showing a blocking wall with a button
• Link directly to the store listing, and handle the case where the update is not yet available in that region
• Never force-block an offline device that could otherwise do useful work with local data
• Give a soft-prompt period before a hard block, where the platform and severity allow it
• Never discard unsynchronised local data as part of forcing an upgrade

Cadence, and what it costs

Release frequency is a trade-off specific to mobile, because each release carries review latency and a rollout period, and users bear the cost of updating.

Before each submission

1. 01Version and build numbers incremented, and the build reproducible from a tagged commit.
2. 02Crash reporting and symbol upload verified working in this build, not the previous one.
3. 03Migration from the currently released version tested on a device holding real prior data.
4. 04Tested on the oldest OS version you claim to support, and on a low-end device.
5. 05Signing credentials valid and not near expiry, with someone other than one person able to release.
6. 06Remote configuration fetched correctly, including its behaviour when the fetch fails.
7. 07Release notes written for users, and an internal note of what to watch during rollout.

Item three is the one skipped most often and the one that produces the worst failures. Testing a fresh install proves nothing about an upgrade, and the upgrade path — with a populated local database written by the previous version — is what almost every user will actually take.