Getting started with mobile release cadence
We end up explaining this on discovery calls often enough that it deserved writing down. A short on-ramp to mobile release cadence for teams who have not touched it before.
You do not control the device, the network, or the operating system version, and the design has to accept that. Doing this properly once is usually cheaper than doing it approximately three times.
Why it matters
Users on old versions are your compatibility floor. Small and consistent beats large and occasional here. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
Your first week
- Find out what is already in place
- Feature flags let you ship code before enabling behaviour
- Change one thing and measure it
Force-upgrade prompts should be a last resort. The reasoning matters more than the rule, because the rule has exceptions. It rarely shows up as a line item, which is exactly why it slips.
In practice
The version of the app your customers are running is rarely the one you just shipped. Three things worth confirming about mobile release cadence before you move on:
- Someone can say what the current setup is without going to look
- Users on old versions are your compatibility floor — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Most of the value here comes from doing the first two things, not all of them.