Picking your minimum iOS version to support

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 very lucky with the iOS adoption rate in which makes most of our users update to the most recent version within a year.

You’re dropping support for older devices but it does not mean they can not use your app anymore.

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 be able to download 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, 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 is different case by case. A lot of 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 and losing customers could mean losing revenue. Therefore, the first reason why it would not be easy is based on losing customers and revenue.

This totally depends 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 to still support an older iOS version.

New APIs are only available on newer iOS versions

Sometimes, you have a very specific use case for your app which requires your app to use a certain minimum iOS version to be able to use a new API. An example could be certain Siri features, ARKit or Machine Learning features.

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 certain bugs or features which need to be fixed. Therefore, time could be a big reason to drop an iOS version.

The previous paragraph discussed the fact of 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 certain feature. This could be another time-related reason to drop support.

Data, data, data

Although mentioned before, data is your best friend when dropping an iOS version. Make sure you know the facts and you have an overview of what it means for your app to drop a certain iOS, macOS, tvOS or watchOS version.

If you didn’t build in any analytics you can always go to the App Analytics page in App Store Connect.

App Analytics in App Store Connect
App Analytics in App Store Connect

Convincing your colleagues or managers

It might be clear to you 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 both your colleagues and your 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 fellow colleague that it’s better for both you and the product to drop an iOS version.

If you can’t make that strong case you should be honest with yourself and wait for another 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 just change the iOS deployment target to your new minimum iOS version:

Changing the minimum supported iOS version
Changing the minimum supported iOS version

However, there’s more you can and need to do 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 already installed your app it will still be available for them to use.

Therefore, it’s important to think about the features you want to be available in this latest supported build. Sometimes you can decide to create a stable release of your last new features so those users at least have a most up to date version possible.

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 at least make sure those other users think about updating their software. This will make both you and other developers happy as the adoption rate will grow.

Updating your codebase

Once you decided which minimum iOS version to support its 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 available checks which are no longer needed
  • Deprecated methods as of the new minimum deployment target

Take time to either fix those directly or to plan ahead and make sure that you fix them later.

Watch older WWDC sessions

You might be surprised by this one but it’s actually one of the main reasons I started writing this blog post. Older WWDC sessions are still very valuable and you can now actually 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 2019 when dropping iOS 12
  • Watch WWDC 2018 when dropping iOS 11
  • Watch WWDC 2017 when dropping iOS 10
  • Watch WWDC 2016 when dropping iOS 9

I do want to point out that you could obviously always directly start implementing code from those sessions once their related iOS version is released. However, you’ll not be the first develop to skip and wait till you actually only support that iOS version and up. For those (like me), it can be very valuable to revisit those older sessions and see which parts you can now start implementing.


Dropping an iOS version can be very easy if you’re developing an app on your own and very hard if you’re working in a team. Take your time, visit your data, and find reasons to convince your team members to make a solid decision.