You might be wondering how many previous versions of the OS should your software support? Supporting very old mobile app OS versions can be problematic and expensive. We will show you that less is definitely more.
May 21, 2018
One question that surfaces in almost every software project, especially for mobile devices, is how many previous OS versions should the software support.
While companies may be eager to include all potential users, supporting very old OS versions can be problematic and expensive.
In this article we’ll attempt to show that less is definitely more. For the sake of simplicity, we will focus on iOS as it’s clearly superior to Android in every way! (#iosmasterrace)
According to Apteligent with figures published on 26th March 2018, iOS 11 accounts for 81.53% of iOS users. That’s quite impressive approximately 6 months after iOS 11 was released on 17th September 2017. iOS 10 accounts for 12.06%, much of which is accounted for with iPhone 5, iPhone 5c and iPad 3 for which iOS11 isn’t available. That leaves 6.34% of users on versions lower than that.
When we look at the cost of supporting that 6.34% in our projects, we’re left with the impression that it’s not value for money, especially when that budget could be allocated towards implementing new features or preparing for the next OS release.
It’s also worth noting that the ~6% is a dwindling figure as stragglers finally update and older devices are retired.
The time taken to QA each build in a developement cycle can make or break a project. For each supported OS, the ‘matrix’ of devices and OS versions grows considerably. Consider, for example, supporting iOS 9 in addition to iOS 10 and 11. iOS 9 is supported by the following devices: iPhone 4s, iPhone 5, iPhone 5c, iPhone 5s, iPhone 6, iPhone 6s, iPhone 6 Plus, iPhone 6s Plus, iPad 2, iPad (3rd generation), iPad (4th generation), iPad Air, iPad Air 2, iPad Mini (1st generation), iPad Mini 2, iPad Mini 3, iPad Mini 4, iPad Pro, iPod Touch (5th generation), iPod Touch (6th generation).
That’s a staggering twenty-one unique devices. Combine that with 11 minor revisions from iOS 9.0.1 to 9.3.5 and you get a whopping 231 device/OS combinations just for iOS 9.
Ideally, each of these 231 should be tested prior to release but the cost implications make that prohibitive, not to mention the added overhead of sourcing and managing that number of devices.
Security, Security, Security…
Security. Did we mention security? New exploits are being found just about as quickly as companies can issue patches to fix them. The problem with older OS versions is that patches aren’t forthcoming, leaving your app potentially vulnerable to attack. For example, looking at the security fixes in iOS 11.2, there are a number of major security vulnerabilities that aren’t patched in previous versions. Some of these can allow attackers to execute arbitrary code remotely or read restricted memory. All of these vulnerabilities also exist in previous versions of iOS but have not been patched and are very unlikely to be patched in the future.
New features, libraries and frameworks are added to iOS with each major release. At the same time, API methods are constantly being deprecated/retired. We want to use the latest features provided by the OS in order to provide the best user experience within our app. But, if said feature isn’t available in a previous version of iOS that’s supported by our app, we either have to omit the new functionality from the older OS or implement a custom solution. Custom solutions typically take a lot longer (and often don’t work quite as well) than using the OS-provided solution.
Following on from development time, comes the issue of maintainability. Having to support older versions of an OS means that code can become fragmented in order to support the various ways of implementing certain features. This can lead to ugly unreadable code that becomes more difficult to maintain. This in turn leads to overhead maintaining this code in future revisions to the app.
In an ideal world, all users would update to the latest OS as soon as it’s available. But that’s unlikely to ever happen.
Our rule of thumb tends to be: support the latest release plus the last revision of the previous release.
For iOS, at the time of writing where the latest revision is iOS 11.3, this would mean supporting every revision of iOS 11 and iOS 10.3.3. We think that this provides the best compromise between supporting the vast majority of user base while also staying relatively up to date in terms of security and saving on development costs.