- Users keep old app versions for a long time, so every app needs a way to ask for, and sometimes require, an update.
- Control two numbers per platform from your server: a recommended version and a minimum supported version.
- Below the recommended version, show a prompt people can dismiss; below the minimum, show a screen that blocks the app.
- On Android, Google Play in-app updates can download and install the new version for you; on iOS, your screen opens the App Store page.
- Raise the minimum only after the new build is live in both stores, and keep old API versions working for a planned period.
How do you make users update a mobile app?
Build a minimum version check. When the app starts, it compares its own version with two numbers you control on the server for each platform: a recommended version and a minimum supported version. Below the recommended version, show a prompt people can dismiss. Below the minimum, show a screen that blocks the app until it is updated. On Android, Google Play's in-app updates can handle the download and install; on iOS, the screen opens the app's App Store page.
The check is small, but it has to be in the very first release. An app that ships without it cannot be asked to update later, because the old version does not know how. It is part of every app our mobile app development team plans.
Why do users stay on old versions?
Unlike a website, you cannot replace every copy of an app at once. Some people turn automatic updates off, some only update on Wi-Fi or when storage allows, and some open the app rarely. Google's own guide notes that while some users get background updates, others need to be reminded to install them (Android in-app updates).
Every old version still in use is a client your API has to keep serving. That is why our mobile app back-end checklist recommends versioning the API from the first release. The update check is the other half: it lets you retire old versions on your own schedule.
When should an update be required?
- A security fix, where the old version exposes accounts or data.
- A breaking API change that you cannot keep backward compatible at a sensible cost.
- A payment, legal or policy change that the old version handles incorrectly.
- A bug that damages data, such as duplicate orders or lost entries.
New features, design changes and minor fixes deserve a prompt, not a block. Google's guide makes the same point: be careful how often you request updates, and only ask for changes that are important to the core of your app (in-app updates for Kotlin and Java).
How does a minimum version check work?
- The app reports its version. Send the build number and platform with each API request, or fetch an update config when the app opens.
- The server holds the rules. For each platform, store a recommended version, a minimum version and the message to show. A remote config service such as Firebase Remote Config, which changes app behavior without a new release, works, as does a small endpoint on your own API.
- Compare build numbers, not text. A string comparison can put version 1.10 before 1.9.
- Decide what happens offline. If the config cannot load, let the app open with the last known rules rather than locking people out.
- Enforce it on the server too. When a version below the minimum calls the API, return a clear error that the app shows as the update screen, in case the start-up check was skipped.
What does Google Play's in-app update offer?
On Android, the Play Core library has two flows. A flexible update downloads in the background while the user keeps working, then asks them to restart. An immediate update is a full-screen flow that the user must complete before using the app; Google Play installs the update and restarts it. In-app updates work on devices running Android 5.0 (API level 21) or higher, on phones, tablets and ChromeOS (Android in-app updates). It is a Google Play feature, so it only helps users who got the app from Google Play.
Two settings help you choose between the flows. You can give each release a priority from 0 to 5 through the Google Play Developer API when you roll it out, and it cannot be changed later. The app can also read how many days have passed since an update appeared in the store, so you can start with a flexible prompt and switch to an immediate update after a while (in-app updates for Kotlin and Java). If the user declines an immediate update, the guide suggests letting them continue where possible and asking again later.
What about iOS?
On iOS, the usual approach is your own update screen with a button that opens the app's page in the App Store. Keep the wording short, say what changed in plain terms, and make sure the button works on the first tap. For a blocking screen, remove every other route into the app, including links from push notifications and deep links.
The timing rule matters on both platforms: raise the minimum only after the new build is approved and live in each store, and after any phased rollout has reached everyone. If you raise it first, users are sent to a store page with no update to install.
What happens to old API versions?
Track which app versions are still active. Your analytics or crash reporting tool can show this; our guide to crash reporting with Crashlytics or Sentry covers tagging releases. Then retire old versions in steps: a prompt first, a blocking screen once few users remain, and finally switching off the old API endpoints.
The stores push you to release regularly anyway. Google Play, for example, sets a minimum target API level for new apps and updates, and apps that fall behind are not offered to new users on newer Android versions (Google Play target API level requirements). A working update check makes those regular releases reach your users.
How do you test forced updates?
- Keep old builds. Archive every release build so you can install an old version and test the prompt and the block against the real API.
- Use internal app sharing on Android. Google's test guide explains the steps: the test account must have installed the app from Google Play, the build must have the same application ID and signing key, and the update needs a higher version code. Update priority is not supported in internal app sharing (testing in-app updates).
- Test the failure cases. No network, a config that fails to load, a user who declines, and a store page that does not show the update yet.
- Write down the release steps. Who raises the minimum, when, and how to lower it again if something goes wrong.
Our custom software team builds the server side of this, the version rules and the API checks, together with the app, so both halves are tested at the same time.
Frequently asked questions
Is it bad for users to block the app until they update?
It is frustrating if it happens often or for small changes, so keep blocking screens for real breaks such as security fixes or an API change the old version cannot survive. Explain the reason in one plain sentence, make the update button obvious, and use a dismissible prompt for everything else.
Can we change the app without a store release?
Some things, yes: text, settings and feature switches that come from your server or a remote config service. Changes to the app code itself need a new build through the stores. React Native apps can also receive JavaScript updates through over-the-air update services, but native code changes still go through store review.
Should iOS and Android have different minimum versions?
Yes. Version numbers, release dates and review times differ between the stores, and a fix may only be needed on one platform. Keep separate recommended and minimum values for each platform on the server, so you never block Android users because of an iOS problem or the other way round.
What if a user cannot update because their phone is too old?
If the new version needs a newer operating system than the phone has, the store will not offer it. Decide in advance what those users see: a clear message, a link to a web version if you have one, or support contact details. Check your analytics for how many users this affects before raising the minimum OS.
How long should old versions keep working?
There is no single answer. Watch how many active users are on each version, set a support window that suits your audience, and give a prompt well before you block. Business apps used by staff can move faster, because you can tell people directly; consumer apps usually need longer.
Last updated