Mobile release cadence: what to get right first

The advice here is unglamorous, which is probably why it gets skipped. If you only fix one thing about mobile release cadence this quarter, make it the first item below.

The version of the app your customers are running is rarely the one you just shipped. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Start here

Users on old versions are your compatibility floor. The cost of getting this wrong is rarely visible on the day it happens. It rarely shows up as a line item, which is exactly why it slips.

Then this

Feature flags let you ship code before enabling behaviour. The teams that handle this well are rarely the ones with the biggest budgets. If two people in the business would answer this differently, that gap is the actual problem.

Eventually

Force-upgrade prompts should be a last resort. There is a version of this that is over-engineered, and it is worth avoiding. Budget a little time for it every quarter and it never becomes a project of its own.

What this looks like day to day

You do not control the device, the network, or the operating system version, and the design has to accept that. Three things worth confirming about mobile release cadence before you move on:

• Someone can say what the current setup is without going to look
• Force-upgrade prompts should be a last resort — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.