Picking minimum iOS and Android versions for an app v1
Apple is now prompting iPhone users who are still on iOS 26 to install iOS 27, and the iOS 27.2 betas are already out. Every time this happens I end up revisiting the same question for any app I'm about to ship: what is the oldest OS version v1 should support?
Why the floor matters more than it looks
The minimum version decides which APIs you can use without workarounds, how many devices you need to test on, and how many of your early users can even install the app. I've found that teams often pick it by habit and only notice the cost later, when a small UI bug shows up on one old version and eats a full day.
How I think about iOS
On iOS, adoption of new versions tends to be fast, and Apple nudging people to update only speeds that up. For a brand new app I usually support the current major version and the one before it. That keeps the test matrix small and still covers most active iPhones. If the app depends on something only in the newest release, I'd rather wait a little than ship a split experience.
Android is a different conversation
Android users stay on older versions much longer, and device variety is wider. Here I look at who the app is actually for before picking a number. An app aimed at a broad audience in markets where budget phones are common needs a lower floor than a tool for developers. Cross platform frameworks like Flutter or React Native help with shared code, but they don't remove the need to test on a few real older devices.
A simple v1 checklist
- Decide the minimum versions before writing UI code, not after.
- Test on at least one older device per platform, not just simulators.
- Watch crash reports by OS version in the first weeks.
- Plan to raise the floor once a version drops below a level you care about.
None of this is complicated, but deciding early saves a lot of rework.
Over to you
When you ship a new mobile app, how do you pick the minimum iOS and Android versions, and has that choice ever come back to bite you?