Mobile API compatibility is not determined by the latest app release. It is shaped by every supported client that can still reach production—including older binaries, queued operations, and users who update slowly.
Adding /v2 does not automatically isolate the previous contract. Both versions may still share databases, services, caches, background jobs, and downstream integrations.
For example:
- Changing a field from an empty string to
nullcan break an older client with strict decoding. - Changing a business failure from HTTP
200to422can send older clients into a generic network-error flow.
Safer API evolution requires additive changes, supported-client testing, version-specific telemetry, backend execution controls, measured deprecation, and data-compatible rollback.
A mobile feature flag can hide a screen, but it cannot reliably stop older binaries, queued operations, or replayed requests. Sensitive operations must still be controlled by the backend.
Rollback must restore behaviour across code, data, events, jobs, and accepted operations—not merely redeploy an older backend image.
Top comments (0)