Mobile apps · Mixed

Versions and backward compatibility in apps

In one line: Users have old versions for months — the server must support them, and know when to stop.

The reality

Even with automatic update on, the version breakdown spreads over months. Any breaking change to the server interface drops real users without them understanding why.

So: extend, don't change. Add fields, don't remove; add paths, don't change the behaviour of existing ones.

Control mechanisms

Interface version. Declare it on every request so you know who's talking to you.

Forced upgrade. A screen that blocks versions no longer supported. Economical, and it must be there from day one — you can't add it retroactively to an old version.

Capability switches. Turning capabilities on and off remotely, by version and by user share.

When to stop supporting

Decide by data, not by feeling: when less than one percent of active use comes from a version, and after an in-app advance notice. Document the policy so you don't relitigate it on every release.

Going deeper

Run integration tests of the two most recent supported versions against the current interface on every server release. Backward compatibility that isn't tested automatically breaks silently, and surfaces only in store reviews.