When a new iOS version arrives, it’s oftentimes a moment to reflect on the supported iOS versions and see to which minimum iOS version your project should be set. It’s an important decision in a developer’s job and not something you can do without reasoning.
We can be fortunate with the iOS adoption rate in which most of our users update to the most recent version within a year. This might differ for your app based on the target audience for which a case-per-case decision is required.
It’s important to realize that dropping support for older devices does not mean they can not use your app anymore. You can decide as a team to deliver the latest update for a specific iOS version before you finally drop it. Let’s dive into the details of what it takes to drop a version.
What is a minimum iOS version?
The minimum iOS version is the lowest iOS version supported by your app. Users running an older iOS version will not download newer updates of your app from the app store.
The minimum iOS version can be set in the build settings under iOS Deployment Target—the same counts for macOS, tvOS, visionOS, and watchOS.
Which minimum iOS version should my app support?
Which minimum iOS version should I support? That’s the big question for which the answer differs case by case. Many companies rely on the “current minus one” rule, which comes down to supporting the latest and previous iOS version.
However, it’s not always that easy, and multiple reasons could make you decide differently. As the above poll shows, it’s not the same decision for everyone.
Reasons for (not) dropping an iOS version
Losing customers and revenue: Take a look at your data
Dropping an iOS version means losing customers, which could mean losing revenue. Therefore, the first reason why it would not be easy is based on losing customers and revenue.
This differs case by case and can be decided based on your analytics data. Make an overview of the number of active users per iOS version to know how much it’s worth supporting an older iOS version. If there’s a relatively high number of users using an old iOS version and you still want to try dropping that OS, you can decide to look a little closer and verify how much those users are worth. If they don’t bring in any profits, but it does cost a lot of time to maintain the old OS, you might still want to drop the old version.
Your customers might have a choice
It’s best practice to evaluate whether your users have a choice to update to iOS 17 or whether they can’t due to using an unsupported device. Apple provides a list of supported devices that you can use to evaluate your audience. Use your analytics tool, filter on devices running iOS 16 and lower, and determine the percentage that could update to iOS 17. Based on that outcome, you could decide it’s not worth maintaining an older OS version for users who have been lazy in updating their OS.
New APIs are only available on newer iOS versions
Sometimes, you have a particular use case for your app, which requires your app to use a certain minimum iOS version to use a new API. For example, you might want to focus entirely on SwiftData to be prepared for the future. Your only choice is to support iOS 17 and up or write legacy code using Core Data.
Time reasons
Each iOS version you support needs to be tested, which can take up a lot of time. It will take even longer if an older iOS version contains specific bugs or features that must be fixed. Therefore, time could be a big reason to drop an iOS version.
The previous paragraph discussed dropping a version based on certain released APIs. Although you might be able to make it possible to create your app for an older iOS version, it could be that new APIs make you develop twice as fast because they’re simply making it easier to implement a particular feature. This could be another time-related reason to drop support.
Data, data, data
As mentioned before, data is your best friend when dropping an iOS version. Please make sure you know the facts and have an overview of what it means for your app to drop a specific iOS, macOS, tvOS, or watchOS version.
If you didn’t build in any analytics, you could always go to the App Analytics page in App Store Connect.
It’s essential to realize this data is incomplete since it’s opt-in: users can decide not to share it during the device setup. However, it’s still representative data you can use to make decisions. In the above example, we’re looking at usage data for RocketSim. Based on these metrics, I can at least conclude it’s not worth maintaining macOS 12 anymore.
Within App Store Connect, there are multiple ways of looking at your data. One option is to look at the active users for the last 30 days per iOS version. You can combine this number with other iOS versions you consider dropping and calculate the percentage based on the total number of users. If this percentage is low enough, you might consider dropping the version.
Ideally, however, you would be able to use an analytics tool that allows you to bundle OS versions as percentages. At WeTransfer, we like to use Datadog and created these two widgets:
It’s questionable whether we want to continue supporting iOS 15 since 4.95% still results in many users. Therefore, we’re not only basing our decision on this percentage but also on the value these users bring in.
Convincing your colleagues or managers
It might be clear that you want to drop an iOS version, but you’re often not alone. Make sure you have reasons to drop an iOS version and use them to convince your colleagues and managers. You should not only drop an iOS version because it makes your life as a developer easier. Think further, make reasoning, and convince your colleague that both you and the product should drop an iOS version.
If you can’t make that strong case, you should be honest with yourself and wait a few months to come back to this decision and see whether something has changed.
How to drop an iOS version?
The easiest part would be to change the iOS deployment target to your new minimum iOS version:
However, there’s more effort required to make this a smooth process.
Prepare and decide how your last supported version will be
You’re dropping support for older devices, but it does not mean they can not use your app anymore. If they have already installed your app, it will still be available for them to use.
Therefore, thinking about the features you want in this latest supported build is essential. Sometimes, you can create a stable release of your last new features so those users at least have the most up-to-date version possible.
It’s also an excellent idea to Inform your backend engineers. Older app versions can use older APIs, which can eventually be phased out. You may have dropped iOS 10 a few years back, for which a specific API endpoint was still maintained, which is no longer needed. Ideally, you can remotely disable older app versions once you want to stop supporting them.
Informing the users
If you’re a good citizen, you make sure the users of an unsupported iOS version get informed. Tell them they’re running an unsupported iOS version and that they’ll only be up to date if they update their iOS device. Although this might not always be possible for each user due to an old device, it will make sure those other users think about updating their software. This will make you and the other developers happy as the adoption rate grows.
Updating your codebase
Once you decide which minimum iOS version to support, it’s time to update your codebase. Xcode will automatically show new warnings once you build for the first time with the new deployment target:
- Certain
#if availablechecks which are no longer needed - Deprecated methods as of the new minimum deployment target
Take time to either fix those directly or plan and ensure you fix them later.
Watch older WWDC sessions
You might be surprised by this one, but it’s one of the main reasons I started writing this blog post. Older WWDC sessions are still precious, and you can now directly start implementing code from those sessions as you raised your minimum iOS version!
It might be a bit hard to know which WWDC sessions are now relevant. To make it a bit easier, here’s a simple list:
- Watch WWDC 2023 when dropping iOS 16
- Watch WWDC 2022 when dropping iOS 15
- Watch WWDC 2021 when dropping iOS 14
- Watch WWDC 2020 when dropping iOS 13
I do want to point out that you could always directly start implementing code from those sessions once their related iOS version is released. However, you’ll not be the first developer to skip and wait till you only support that iOS version and up. It can be precious for those (like me) to revisit those older sessions and see which parts you can now implement.
Conclusion
Dropping an iOS version can be easy if you’re developing an app independently. When working on a team, though, it can be very hard. Making a solid decision based on data and facts is required to convince your colleagues about dropping a version. Once you drop a particular version, inform your users and update your backlog with new APIs to implement.
If you like to improve your workflow even more, check out the workflow category page. Feel free to contact me or tweet me on Twitter if you have any additional tips or feedback.
Thanks!