Imagine a wholesale distributor building an ordering app for its customers and a separate app for its own delivery drivers. Early in the project, a developer asks a short question: "What's the minimum iOS and Android version?" Nobody on the business side knows what the question means, so the answer is "whatever you think is best." The developer picks something sensible from their last project, writes it into a configuration file, and the topic never comes up again.
Six months after launch, two things happen. Several customers write in to say they can't find the app in the store. And the drivers' company phones, bought in bulk a few years ago, turn out to run an Android version just below the floor the developer chose. Neither problem is a bug. Both come from a decision that was made by default.
The minimum operating system version decides who can install your app, how much testing every release needs and which features are cheap to build. That makes it a business decision with a technical answer, and it is worth an hour of conversation at the start of the project.
1. Start from your own users, not global charts
Platform-wide statistics tell you what the average phone runs. Your users are not the average. A consumer app aimed at young users in one country may find almost everyone on a recent version. A B2B app used by older customers, or by staff on company-issued devices, can look very different.
Before choosing, collect the data you already have. If you have a website, its analytics show the operating systems of mobile visitors. If you have an earlier app, its store console shows installs by OS version. If the app is for your own staff, ask IT for the list of devices actually in use, including warehouse scanners and tablets that nobody thinks of as phones. Then decide what share of these users you are willing to leave out, and write that number down.
2. Know what each older version costs
Supporting an older version is not free, and the cost rarely shows up in the first estimate. Every extra version adds devices or simulators to the test matrix. Newer system features, such as certain notification options, widgets or privacy prompts, may need a fallback path on older systems, which means two pieces of code doing the same job. Third-party libraries and SDKs set their own minimums; if a payment, maps or analytics SDK you depend on drops an old version, you either stay on its outdated release or follow it.
None of this means you should always support only the newest versions. It means the trade should be visible. "Supporting one more Android version adds this much testing per release and rules out this feature" is a question the business side can answer. "What's the minimum version?" is not.
3. Separate the minimum from the target
On both platforms there are two different numbers, and they are often confused.
On Android, the minimum SDK decides which devices can install the app. The target SDK tells the system which version's behaviour the app is built for. Google Play requires new apps and updates to target a recent API level, so the target has to move forward regularly even if your minimum stays where it is.
On iOS, the deployment target is the oldest version that can run the app, while the SDK you build with comes from the Xcode version you use. Apple also requires App Store submissions to be built with a recent Xcode and SDK.
The practical result: you can keep supporting older devices while still meeting store rules, but only if both numbers are tracked separately and someone owns raising the target each year.
4. Decide what happens to users you leave behind
Raising the minimum does not delete the app from older phones. Users who already have it keep their installed version; on iOS, the App Store can offer the last compatible version to devices that no longer meet the requirement, and on Android, devices below the new minimum simply stop receiving updates.
That creates a quiet problem on the server side. Old app versions keep calling your backend. If you change an API response, rename a field or remove an endpoint, those users see errors instead of a message. Before raising the floor, decide how long the backend will keep serving older app versions, and design API changes so that old clients either keep working or receive a clear message.
5. Ship a version check in the first release
The cheapest moment to add a version check is before the app is in anyone's hands. The idea is simple: when the app opens, it asks the server for the minimum supported app version. If the installed app is older, it shows a screen explaining that an update is needed and links to the store. A softer variant suggests the update but lets the user continue.
Without this check, the only way to reach users on an outdated app is to keep their old version working forever, or to let it break. With it, you can retire old versions on your own schedule. The check itself should be tolerant: if the server cannot be reached, the app should open normally rather than lock the user out.
6. Review the floor once a year, on a calendar
Minimum versions tend to stay where they were set until something forces a change: a library update, a store rule, a feature that won't work on old systems. Changes made under pressure are rushed, and users get no warning.
Put a yearly review on the calendar, a few weeks after the major iOS and Android releases. Look at your install data again, check the minimums of the SDKs you depend on, and decide whether to move. If you do move, announce it inside the app for users on older systems before the update that drops them, so they are not surprised.
In short
Choose the minimum OS version from your own users' devices, not from global charts. Make the cost of each older version visible, keep the minimum and target versions separate, plan for users who stay on old versions, add a version check before the first release, and review the decision once a year. Made this way, the minimum version stops being a line in a configuration file and becomes a decision someone owns.
In our mobile projects, we set the minimum versions with the client at the start, using their own device and analytics data, and include a server-side version check in the first release.
Our work on this: Mobile App Development
Planning a project like this?
Plan it in 10 steps