Sometimes that's fine, but other times, it's extremely unfortunate and prevents you from solving problems using much more modern approaches. For example, async/await is only backwards deployable to iOS 13 and later.Įven more importantly though, supporting older deployment targets means you can't easily use new framework APIs. Given how high the adoption is for new versions of iOS, it just doesn't make sense for us to test and support older versions of iOS.Īlthough some Swift features might be available regardless of deployment target, that's not true for all of them.

Because of this, at my company, we choose to drop support for the 3rd oldest major version of iOS in January of each year. If we look at users on the last 3 major versions of iOS at that time, then we see numbers closer to 96-98%. Many companies have guidelines for which versions of iOS they plan to support, and it seems like the most common guideline is to support the last 2 or 3 major versions of iOS at any given time.įor my company's main app, within a few months of a major iOS release, we typically find that around 90-95% of our users have upgraded to at least the last 2 major versions of iOS. To prevent regressions in app quality on old versions of iOSĪlthough every app's customer base will be a bit different, it's worth noting that major versions of iOS have surprisingly good user adoption. To reduce the burden on QA teams and hardware budget From my perspective, the main reasons are:

I'm not the OP, but I'm pretty passionate believer in dropping support for older versions of iOS.

Newest xcode