Earlier this year we started discussing our longer-term plans for OS X support in our flagship app, RapidWeaver. It’s something we’ve given a lot of thought to, and it was particularly interesting to see the feedback from discussions with the users who drop by the RapidWeaver forums.
During our planning for RapidWeaver 5 way back in the summer of 2010, we heard from a lot of people that support for OS X 10.5.8 Leopard was a massively important thing for them. Our stats for OS usage in RapidWeaver (more on that in a bit) supported the case too. The numbers were going down of course, but there was a substantial number of customers particularly in education, who heavily relied on Leopard. So we decided to support Leopard - and still do in RapidWeaver 5.3.1, even on PowerPC systems!
In the intervening years, OS X has undergone a massive overhaul. PowerPC hardware went bye-bye, and then Apple phased out support for building PowerPC apps. Xcode 3.2.6’s default build architecture was “Intel-only”, and Xcode 4 removed support for PowerPC entirely.
If you hadn't realised it, over the last few years Apple’s ability to continually push new technologies has intensified to near-dizzying speed. From an almost-leisurely 18-month+ cycle between OS X releases, we’ve got annual releases of iOS now being feature-paired with annual releases of OS X. The tools we use are being built to support only the newer OSes and given the pace of OS updates and the significant change to our toolset, that obviously affects all developers - especially small teams such as ours!
Given that there’s no user-friendly way to specify which point-release versions of OS X an app supports (i.e. “supports 10.6.8, and 10.7.4+ but not 10.7.0 - 10.7.3”) the minimum OS requirement of your app then becomes incredibly important. So today I thought I’d talk a little about the thought process for our apps as we’ve been doing a fair bit of thinking about this stuff of late.
So What Do We Support Currently?
Our app lineup is interesting to look at, in terms of OS X support.
As you can see, there’s a definite trend! I’ve noted our support for PowerPC versions of OS X 10.5.8, as we treat that a separate OS release that we QA alongside the Intel variant.
So what do we consider, when deciding which versions of OS X to support?
What’s Everyone Using?
Our non-Mac App Store versions of LittleSnapper and RapidWeaver 5 have, since their respective launch, had the option to send anonymous information such as OS X version to us. To show you how we’ve seen OS X adoption skyrocket, here’s some hard data! If you’re wanting to see some more graphs, the folks at the Omni Group also publish their opt-in data. Before you check our data, I should disclaim it:
- these figures are only indicative and from a sub-set of users who have opted to share them anonymously with us;
- the numbers are not from the Mac App Store versions of the apps (however, the Mac App Store requires OS X 10.6.6+, and we consider Mac App Store customers to be more likely to update to newer OS X versions);
- there's potential bias, in so much as we consider people who update their version of OS X to be more likely to check for updates (which is when the information is sent to us).
- Because of the massive skewing of the data in launch month (lots of software update checks) we look at 3-monthly data. So, the stats below are for the period from two months before a major OS X release through to one month after it.
With the App Store making OS X updates even easier, and uptake of new OS releases quicker than ever, there’s certainly an argument to be made that developers should be targeting the newest OS releases. But that’s not the only thing to consider, of course.
Technical Restrictions
Sometimes there’s a technology so critical (or non-optional), that it effectively determines the minimum OS version. One such example is sandboxing on OS X, which has been constantly added to and improved. Sandboxing arrived in OS X Lion 10.7.0, but it wasn’t until OS X 10.7.4 that the sandbox matured enough for us to start adopting it - and as we gradually roll out sandboxing to all our apps, we’ll have to raise the system requirements to ensure we can reliably offer a great user experience.
OS X Feature Adoption
So after we’ve figured out where we have to set the system requirements, we get to the more subjective matter: which OS X technologies determine OS support - and is the developer feature mature enough.
Depending on the scale of the feature involved, sometimes a feature can determine the version we need. It’s not always the case, and sometimes we’ll progressively enhance our apps depending on the OS X version. For the next major upgrade to RapidWeaver, that’s likely to be what we do: offering specific features to a particular version of the operating system but still supporting an earlier version of the OS.
For Clear, whilst iCloud was available in OS X Lion it wasn’t until Mountain Lion that things settled down behind the scenes. Given the extra developer features and maturity of iCloud in OS X 10.8.2 which includes the improvements also found in iOS 6, we felt that this was the best version to target - and it seems we’re not the only ones to come to this conclusion!
Commercial Considerations
Knowing who to support, and the demographic you’re targeting is incredibly important. There will, depending on the scope of the app, be times where longer-term OS support is required - and if you’re supporting apps using iOS 3.x or iOS 4.x you’re probably running into issues that we face supporting OS X Leopard. They’re not insurmountable problems, but they’re definitely something to evaluate and plan for: the longer QA and development is something you’ll have to consider for every changeset and release, not to mention the speed at which you can adopt new features.
Decision Time!
So what’s the right choice? Unfortunately there isn’t one. Deciding the OS support obviously depends on what you’re building, who you’re building it for, and what makes sense from a technical and product marketing standpoint. Here at Realmac we want to offer (and are expected to offer) the latest technologies to the people who use our apps - and treading the line between cutting edge, supporting older systems and the experience our apps offer is a fine art! Our plans tend to be either:
Latest-only: When we launch any new apps in future, it’s highly likely this is the path we will take. Given that we’ll be under 12 months away from the next OS release, we want to be in a position to quickly iterate. Caveats are the potential lack of API maturity, and less widespread adoption, however a much smaller number of target OSes makes it easier to iterate the codebase and adopt new technologies.
Latest-minus-one: For example OS X Mountain Lion, and OS X Lion. This treads a better balance in terms of installed base - and depending on the versions you support, there’s pairs of releases that work pretty well together (10.5/6, 10.7/8). Obvious caveats however include the possibility of substantial changes between two releases for technologies that (for the end user) are perceived to be identical - again, iCloud for example.
As you can tell, there’s no right (or particularly easy) answer. There’s ways to support older OS versions if you absolutely have to, but it comes at the expense of a less modern and more convoluted codebase which may hamper your plans to iterate quickly. If longer-term OS support is required (either contractually, or philosophically) be sure to budget for the time needed to fully support these versions of iOS or OS X - but at the same time, be pragmatic about what you do support!
If you’ve got any thoughts, I’d love to hear them in the comments below - or just give me a shout on Twitter: I’m @nikf.