Staying Current

This morning, I read a new review from a user in Germany, who awarded TPE for iOS two stars, saying:

This is really a great app for photo freaks. But unfortunately it is not compatible to older iOS versions. That nerves and is not fair to users of older hardware. So, sorry, but 2 stars are enough. Its often easy to stay compatible…if you really want… and if you are really interested on your customers!!!

In light of this, I thought it would be worthwhile clarifying our thinking on device and OS support.

Current Situation

At the time of writing, TPE for iOS requires iOS 5.1.1 or higher. That means that a number of older iOS devices can no longer upgrade to the latest version, including:

  • Original iPhone (discontinued July 2008)
  • iPhone 3G (discontinued June 2010)
  • 1st and 2nd Generation iPod Touch (discontinued September 2008 and September 2010 respectively)

Er, that’s it. Every other iOS device ever made remains supported by the current version of TPE.

The Costs of Supporting Older Hardware

In an ideal world, yes – we would maintain support for older hardware. However, it’s not an ideal world, and every device and OS version we support imposes real costs, primarily in terms of development and testing time. We’re not, as you might imagine, a large company with development teams at our disposal (in fact there’s just the two of us). As a result, we have to decide how best to use our time.

“It’s often easy to stay compatible”: yes, that’s potentially true. But to do it you face a choice: either entirely forego the benefits of advances made in the functionality of later versions of iOS (more on which below), or start using those features, but write your code in a way that only exposes them to users on later operating system versions.

Suppose we made the first choice and elected not to make use of new OS features in the app. (By features, I mean developer level APIs that can be used by apps to support new functionality, or to improve the implementation of an existing feature in terms of performance, reliability and so forth.)

Even with this choice, older device support imposes some real costs: each time Apple releases a new version of iOS, we need to check that older code still works on the new software. Sometimes it doesn’t and we’re forced to change things in any case. Even when it does, we have an ever expanding number of versions to test against.

If we make the second choice (use the new features, but only for users running the newer iOS versions), we have to litter the code base with conditional checks for the running OS version (or equivalent checks) and then write and test code for every combination. Over time, the code base sprawls and becomes much harder to manage. Reliability suffers. We end up needing to write multiple versions of documentation for users on different OS versions. User problems are harder to resolve.

Neither is remotely an attractive situation.

Benefits Foregone

The other side of the equation is that, to support older devices, we likely have to forego the benefits of technological advances available in later versions of iOS (or any other operating system).

One great example is ARC. Introduced in iOS 5, ARC (automatic reference counting) essentially takes away virtually all the worry of memory management.

Memory management is probably the trickiest aspect of iOS development, and as such, is responsible for a large number of crashes and bugs when implemented incorrectly. Removing that worry from the developer results in a more stable, better performing app for users and allows the developer to focus on implementing new features and improvements: the net effect is a better outcome for customers.

When I switched TPE over to ARC earlier this year, once we started to require iOS 5, we saw a 5-fold reduction in the crash rate for the app. Five fold. A real and quantifiable benefit to users.

Another example is Block Objects and Grand Central Dispatch introduced in iOS 4. Blocks enable much more concise and readable code. Grand Central Dispatch (GCD) makes writing multi-threaded code much, MUCH easier. I relied heavily on both technologies to add support for the offline maps in TPE for iOS 2.3.

Choosing to forego these technologies to keep supporting older devices is done directly at the expense of users on new devices.

So how do we decide?

With all that said, how then do we decide which versions to support and which to drop? Why do we only require iOS 5.1.1 now? Why not switch to iOS 6?

The answer is that, pace my friend above, we are really interested in our users and we take careful note of how they use TPE.

When we dropped support for iOS 4 earlier this year, we examined the installed base to see what versions of iOS our customers were using:

We saw that 98.6% of our users were either already on iOS 5 or had devices that could be upgraded to iOS 5. The decision was easy at that point: at the expense of only 1.4% of users, we could offer significant benefits to the vast majority by moving ahead and taking advantage of the new capabilities in iOS 5.

So what is the cut-off point? I think that is always going to be a subjective decision and doesn’t depend on the numbers alone. Anything over 5% still on iOS 4 would probably have been a red flag. Between 5% and 1.4%, it would depend on the upside of moving to iOS 5. In the case of ARC, the upside was very clear.

Remember also, users still on iOS 4 didn’t lose use of the app: they lost only the ability to continue to upgrade until such time as they update their hardware.

As of today, 5.2% of TPE for Android users are using Android 2.2. I don’t think we’re ready to drop support for 2.2 quite yet. And the benefits attainable by moving to 2.3 are not that significant.

The bottom line is that we will follow our users. If 50% of users were still on iOS 3, would we still be supporting it today? Almost certainly, yes – if we didn’t, we wouldn’t have much of a business. Are we making the right choices? I hope so. If you see it differently, please let us know via Twitter/FB/G+.