The old version of your app is still on someone's phone.

One website, many apps

When you ship a fix to a website, the next person who loads the page gets it. There's one version, and you control it.

A mobile app doesn't work like that. When you release a new version, it goes to the app stores, then out to phones over days and weeks. Some people have automatic updates on. Some update when a red badge annoys them enough. Some never update at all, because their phone is old, their storage is full, or they just don't. A website has one version. An app has every version anyone still has installed.

Most of the time this doesn't matter much. Then one day it does, and the team discovers that the decisions it needed (how old a version it still supports, how to ask people to update, what the server can switch off) were never made. Here are three what-ifs that tend to force the issue, and what you'd want in place before each one.

What if there's a bug in checkout?

Say the new release has a problem in the payment step. On some phones, the "Pay" button submits twice. You fix it within a day and send out a new version. But people who installed the broken version keep using it until they update, and some of them are paying twice right now.

What you'd want in place:

• A switch on the server. If risky features, like a new payment flow, can be turned on and off from your side without a new app release, you can route everyone back to the old flow in minutes. Our note on kill switches for feature flags covers how to do that without half-switching it off.
• A careful rollout. Releasing to a small share of users first means a bug like this reaches fewer people before you catch it. The same thinking is in naming the canary before you raise the share.
• A way to fix the effects. A server-side check that catches duplicate payments, and someone who knows how to refund them, matter more than how fast the new version reaches phones.

What if you need to change how the app talks to your server?

Your app gets its data from your own server through an API. Now you want to change it: rename a field, restructure an order, retire an old endpoint. The new app version is ready for the change. The old versions aren't, and they'll start failing in confusing ways the moment the server stops answering the way they expect.

What you'd want in place:

• Versioned API calls. Each app version should tell the server which version of the API it speaks, so the server can keep answering old versions the old way for as long as you choose.
• A list of who's calling. Your server should log which app versions are still in use, roughly how many people are on each, and when the last request from a very old one came in. Without that, "can we turn off the old endpoint?" is a guess.
• A retirement date for each old version, decided in advance and written down, so the team doesn't have to agonize over it every time.

If your app works offline, this gets more important, not less. A phone that's been offline for a week may send a week's worth of changes in an old format. We wrote about the conflicts that follow in specifying the conflict before the field app ships.

What if there's a security fix nobody can wait for?

Sometimes an old version has a problem serious enough that you don't want anyone using it. A login flaw. A leaked key that has to be rotated. A bug that exposes another user's data.

This is when you need a minimum supported version: a number your server can raise, below which the app shows a friendly screen asking the user to update before they continue.

On Android, Google Play offers in-app updates with two flows: a flexible one that downloads in the background while people keep using the app, and an immediate one that's full-screen and requires the update before the app can be used. On iPhone, teams usually build their own version check that runs when the app opens and sends people to the App Store.

Either way, build the check into the app long before you need it. A forced-update screen can only appear in versions that already contain the code to show it. If you add it to today's release, the versions released before today will never show it.

Keep the screen kind: what's changed, why it matters, and one clear button. "Update required" with no explanation reads like a scam.

Decide the rules before you need them

None of these three what-ifs is rare. Over a few years, most apps meet all of them. The teams that handle them calmly are the ones that answered a few questions early:

• How many versions back do we support? For example, the last few releases or the last year of them, whichever is longer.
• Who can raise the minimum version, and who has to agree? Forcing an update interrupts every user on an old version, so it shouldn't be one person's call at midnight.
• What switches live on the server? List the features you'd want to turn off without a release.
• How do we tell people? In the app, by email, in the store listing. Prepare the words in advance.
• What happens on phones that can't update? Very old devices may not be able to install your newest version. Decide whether they get a read-only mode, a website link, or a polite goodbye.

Two questions for this week

Ask your team two things this week. Which app versions are calling our server today? And if we needed everyone off one of them by tomorrow, could we do it?

If the answers are "we're not sure" and "no," the fix is a small amount of work in the next release: version logging on the server, a minimum-version check in the app, and two or three server-side switches.

We build mobile applications for people who use them on the move, through poor signal and old phones and interruptions, which is exactly where the old version lives. If you're not sure what your users are running, we can help you find out.

Related work: Spin:Market.