A mobile team ships every two weeks, cannot roll back a released build, and regularly finds severe bugs in production. What would you change?

The constraint that changes everything

A mobile release cannot be rolled back. Once a user has installed a version it stays until they update, and a fixed build must go through review and then be adopted — which takes days regardless of how fast the fix is written. Old versions remain in the field for months or years.

Every practice has to be built around that.

What to change

• Staged rollout by percentage, with automated halt on crash-rate or error-rate regression. This converts "cannot roll back" into "can stop before most users are affected", which is the closest available equivalent.
• Server-controlled feature flags for everything risky, so a bad feature is disabled without a release. This is the single highest-value change: it makes the un-rollbackable artefact contain a switchable feature.
• Configuration served rather than compiled, so behaviour can be adjusted for versions already installed.
• Crash and error monitoring segmented by version, with alerting on regression rather than on absolute rate, since a new version's problems are visible only relative to its predecessor.
• A forced-upgrade mechanism for genuine emergencies, built and tested before it is needed — building it during the incident is too late.

What the API side requires

Backward compatibility for as long as old versions are in the field, which is far longer than most teams plan for. A breaking API change strands users on old builds, and they experience it as the app breaking spontaneously.

That means a version support policy stated explicitly, with a mechanism to prompt or require upgrade before support ends, and telemetry showing the installed version distribution so the decision is informed by data rather than by assumption.

The cultural point

Ship smaller and more often, behind flags. The instinct under un-rollbackable releases is to batch changes and test longer, which makes each release larger and riskier and the feedback slower — the opposite of what the constraint calls for.