Mobile Release Strategy

Mobile breaks the assumptions that make server deployment straightforward, and the constraints are worth stating because backend architects routinely design as though they do not exist.

You cannot roll back a release; you can only ship a new one, and that new one waits for review. Users control adoption, so a version released two years ago is still calling your API today. And a defect shipped to devices cannot be recalled at all.

The consequences for architecture are direct. The API must support every version still in the field, which makes backward compatibility a long-term commitment rather than a courtesy, and makes versioning and deprecation policy a product decision — including the ability to force an upgrade, which needs to be built before it is needed rather than during the incident that requires it.

The mitigations that carry the risk: staged rollout through the store to a percentage of users with crash-rate monitoring gating each expansion; feature flags so functionality can be disabled server-side without a release, which is the only real remedy for a bad feature in a shipped binary; and remote configuration for anything likely to need tuning.

The metric that matters more than any release metric is version adoption over time — it tells you what you must still support, and how long a fix takes to actually reach the fleet.