A mobile application cannot be updated instantly and a bad release is in the store. What should the architecture provide?

What the architecture must provide

• Server-controlled feature flags, so behaviour can be changed without a release. This is the primary mitigation, because it converts a store-release problem into a configuration change.
• Staged rollout through the store's own mechanism, releasing to a percentage and monitoring before expanding.
• A kill switch per feature, evaluated on the client from cached configuration with a safe default — and cached with a fallback, since a flag read from a remote service on the launch path makes that service a hard dependency of the app starting.
• Backwards-compatible APIs indefinitely, because old app versions persist for years and a server change that breaks them breaks users who cannot be reached.
• A forced-update mechanism for the case where an old version must stop being used — used sparingly, because it is hostile, and necessary for a security issue or an unsupported protocol.
• Crash reporting with release attribution, so a bad release is identifiable within hours rather than through reviews.

The version-distribution reality

A meaningful proportion of the installed base is on versions months old, and on constrained devices or limited data plans, users defer updates. A server-side change must therefore be compatible with every version still in significant use, which is a longer tail than teams assume.

That makes additive-only API evolution not a preference but a requirement, and it must be established before the first release — because clients written without a tolerant-reader contract break on an added field.

The specific consideration for a large, price-sensitive audience

Application size and update size matter directly. A large update on a metered connection is one users decline, which widens the version tail and increases the compatibility burden — so update size is an architectural concern rather than a packaging one.

The response when a bad release is already out

Flags first — disable the feature remotely, which works immediately for every user. Then an expedited release, accepting the store's review time. Then a forced update only if the issue cannot be mitigated by flag.

A team without the flags has only the second and third options, both of which take days.