As developers, we’re always looking to take advantage of the latest technologies. Each new version of Apple’s mobile operating system (iOS) introduces new APIs that give us the ability to do wonderfully new things within our apps, but the balance lies in leveraging this new technology while still supporting an established user base. We often try to guess how many versions of iOS our apps need to target because the overall goal is to introduce new functionality while supporting the maximum number of users. Adding bells and whistles won’t do us much good if that means cutting out a significant portion of our audience. Personally, when trying to decide which iOS version my apps will target the three primary things I take into account are a high adoption rate, app complexity, and selective feature offerings.
High Adoption Rate
Apple’s devices aren’t “fragmented” in the way that many competitors’ devices are because Apple controls both the operating system and the hardware it runs on. As a result, there are really only two things that keep iOS users from upgrading: either the hardware is sufficiently old to prevent the upgrade, or users themselves choose not to. This clear upgrade path results in a new operating system adoption rate that is staggeringly high. Several sources (such as CNET and ZDNet) claim that this year’s release of iOS 9 reached over 60% adoption within a month’s time, significantly faster than that of iOS 8. This works in our favor because we can rest assured that by the time we’ve developed and tested features introduced by the latest software release, a good portion of our target audience will be able to take advantage of the latest features.
App Complexity
Will my app even need to take advantage of the latest technologies? What if I just plan to present a web view and a few buttons and labels? What if my app consists primarily of table views and doesn’t even rely on network connectivity? If I’m following the KISS principle (Keep it simple, stupid!) and I don’t plan on doing anything cutting edge, then I could honestly support several prior versions of iOS since most of the basic features have been around since the beginning.
Selective Feature Offerings
If I need to add some newer capabilities, I can always choose to code them in for newer devices and filter them out for older ones. Xcode, the iOS development tool, automates so many of the little tasks that we would have to perform when trying to support multiple devices or versions of an operating system. Want to use the latest software development kit (SDK), but support earlier operating systems? Just set the deployment target to an earlier version with one setting and test for compatibility in the various simulators. It really is quite easy to offer new features to those devices that can support them and selectively filter out features for devices running older versions of the operating system. Many times, the compiler will alert us if we try to compile a feature that isn’t compatible with the specified target. Want to take advantage of modern alert views with inline callbacks but you’re worried that older devices won’t support them? Just test if NSClassFromString(“UIAlertController”) == nil to determine what the device can and can’t support. This way we can still use the latest features and simultaneously support earlier operating systems. (For more information on the importance of mobile application testing check out the blog “Why is Mobile Application Testing Important?”)
Potential Pitfalls
Abrupt Transitions
It won’t happen often, but sometimes there will be a bit of an abrupt transition between two versions of iOS that’ll cause headaches. Sometimes the compiler doesn’t tell you that what you wrote only works on the latest version of iOS. Suddenly your app crashes during the testing period and you’ve discovered that everything you wrote won’t work on older versions. I’ll use the example of a UIAlertController which was introduced in iOS 8. I wanted to support iOS 7 and 8 simultaneously and had to make a choice whether to use UIAlertView only (risking future deprecation) or use NSClassFromString(“UIAlertController”) to check for nil and write both. At some point I knew that UIAlertView would become fully deprecated and stop being supported, so in the interest of future proofing my app I chose to support both. This involved writing a small amount of code to support iOS 8 and a lot of code (including delegate methods) to support iOS 7. Now that iOS 9 is out and I’m supporting iOS 8 and 9 exclusively, I was able to go back into the project and remove all the offensive iOS 7 code, eliminating a bit of bloat in the process. Again, this doesn’t always happen, but the differences between the iOS 7 and 8 SDKs seemed much more stark than the comparatively easy transition between 8 and 9.
Selecting a Development Language
Another consideration is determining which language to develop with. Traditionally iOS apps were written in Objective-C, which is still widely used. As of iOS 7, many developers have chosen to adopt Swift, Apple’s newer development language. While I personally enjoy Swift a good bit more than Objective-C and find myself writing much fewer (and cleaner) lines of code as a result, it is not without its growing pains and the changes between each language update can be quite drastic. This can lead to hours of code changes and problem solving just to get the project to compile. Additionally, when Swift was first introduced, if you chose to use it as your development language, you limited yourself to supporting only the latest version of iOS.
Potential pitfalls aside, I’ve chosen to use some of the latest technologies in my latest projects and have come to the conclusion, based on high iOS adoption rates, that I’d be reaching the vast majority of iOS users if I support the two most recent major operating system versions, iOS 8 and 9. From what I’ve seen, the prevailing wisdom seems to be that you really can’t go wrong if you support iOS for the prior year. Apple’s faithful supporters tend to be an eager bunch and will upgrade if they can, unless there’s a really good reason not to, which rarely seems to be the case. You can be confident that you’ll still be reaching the vast majority of your audience.