Matt Gemmell wrote a delightfully opinionated post discussing OS version support. He makes a number of good arguments for why it is entirely reasonable to support only the latest version of an operating system for your app.
I agree with his thesis, but thought it would be helpful to try and boil down that strategy into more specific rules. Hopefully making it simpler to actually make decisions. I ended up with two simple rules. This is how I manage OS versions in all my apps and so far it has worked out pretty well.
- All new apps should support only the latest OS version.
- You should bump your supported OS version in existing apps as soon as there is a compelling technical reason to do so, but not before.
New Apps
The first rule is incredibly freeing for new application development. Since you don’t have an existing codebase to worry about you can use all the best tools and affordances that the latest SDK tends to provide. Generally speaking, I find that this speeds development dramatically. Additionally, you don’t have an existing set of customers that you will annoy by only supporting the latest operating system, so many of the reasons for providing legacy support fade away.
The only major downside I see to this rule is that you may end up limiting the potential market size at launch. Depending on the nature of your individual app that may be more or less important. However, I’d guess that you’ll end up making a better app by focusing on a single SDK version. A better apps is more likely to get 5 star reviews, featured by Apple, or catch on more generally. I imagine those will more than make up for the reduction in market size. In a nut, any time spent supporting old versions is time not spent on making your app as awesome as possible. Which can’t be a good thing.
Existing Apps
Perhaps the only thing harder than writing an app is re-writing an app. As Joel Spolsky said in this classic post, the “single worst strategic mistake” a software company can make is “[deciding] to rewrite the code from scratch”. That truth tends to make me reluctant to make large scale updates to an app unless there is a compelling reason to. Once you have a certain size of codebase it becomes very difficult to change things. I’ve typically found that to mean that leaving working, but not ‘modern’ code, in an app is better than trying to gut something out and replace it with a newer version allowed by a new SDK. The corollary of this is that it doesn’t make sense to bump the version unless you need to to gain a significant benefit in the new SDK.
There are, however, a number of reasons that would justify making the move. If a new SDK provides your app with an opportunity to do something novel, awesome, and great — then go for it. When you do, dropping support for older versions is typically the cleanest way to go. Trying to balance both versions currently when a major feature won’t be available leads to confusion and support headaches.
Another compelling reason are developer affordances that will make your development better and make you happier. An example of this would be blocks (introduced in iOS 4). Blocks change fundamentally how you structure iOS code and changes it dramatically for the better. If you are working on a major feature in an app that doesn’t support blocks that would be a great reason to bump at least to iOS 4.
iOS 5
All of the above advice may end up being irrelevant with the arrival of OTA updates in iOS 5. As I’ve written about before, OTA updates seem to provide a mechanism that will keep the vast majority of users on the latest version in near realtime. I saw around 90% of my 5.0 users upgrade to iOS 5.0.1 within two weeks of it coming out. (Graph from the above linked post duplicated for reference)
If that holds for major releases, which seems likely since they will actually provide user visible benefits, we all may be able to always code for the Latest Version.