A Look at Control and the Mac App Store

Much like they have in the mobile space, Apple is leading the charge to commoditize software from independent developers, making it more affordable and convenient for users to purchase and keep up to date. The signs seem to suggest that this has on the whole been a boon for most developers but it has also put an unprecedented amount of control in the hands of Apple regarding what apps Mac developers create and what functionality they can and (more importantly) cannot have. Given that control, Apple has chosen to enforce a few policies that are not in the best interest of Mac developers: they refuse to support paid upgrades for large scale apps, enforce a rather rigid and restricting form of sandboxing, prevent developers from using some of the platforms newest and most interesting APIs on apps that are not distributed via the Mac App Store.

Developing software is difficult, time-consuming, and expensive. Traditionally, developers of large applications have used upgrade pricing schemes to maintain recurring revenues as a way to fund future development of their apps; an extreme example of this would the Adobe suite of tools.  Apple currently does not allow developers to charge for updates. Think about that for a second. Users are going to, as they have been trained to for years, expect  their apps to be kept up to date and, in some cases, provide increased functionality as time goes on. However, the current App Store model forces developers to either betray users’ expectations or somehow finance perpetual development of their apps on whatever one time cost they manage to charge on initial purchase; it should also be noted that apps on the Mac App Store have a tendency to be relatively low cost. Some have suggested that developers could take advantage of the Mac App Store’s in app purchasing APIs to make up the lost revenue. In some cases this might be a serviceable option but falls short of being a full replacement for true update pricing. The issue here is that this limitation discourages the continued development of large scale software for the ecosystem.

Security hasn’t been much of an issue for OS X historically. Despite what Apple fans would tell you, that has nothing to do with any sort of enhanced or inherit security on OS X. The truth is that OS X did not have a sufficient install base to make it an attractive target for malware authors. As Apple has been ever so eager to share, Mac sales are growing rapidly when compared to the overall PC industry. In short, OS X is becoming an increasingly attractive target for malware authors. Apple has responded swiftly to these increased threats in what is probably the most excessive heavy-handed PC security policy to date: sandboxing. If you are reading this, I assume that you already know what sandboxing is, so I won’t bore you by reproducing the definition here. In theory, sandboxing is a good way to make an operating system more secure, but in practice, it is more a restrictive mess than anything else. Basically, sandboxing does not provide enough benefits to be worth the onerous restrictions that it imposes on apps’ functionality.

For us developers, APIs are our windows into the platforms we work on. We depend on those APIs being documented, stable, and consistently available. On those first two counts, Apple has done a tremendous job in recent years. However, with the introduction of Mountain Lion, Apple has restricted a number of its newer and more interesting APIs to applications that are sold on the Mac App Store; if you are interested in what APIs are restricted, there are a number of them, but on the whole, they tend to be the ones that have to do with iCloud or the Notification Center. This is something of a Catch 22 for developers, since users are going to increasingly expect apps to provide the functionality provided by these APIs but may not necessarily want to purchase their apps via the Mac App Store. Once again, we have a case of Apple’s policies forcing developers to run afoul of users’ expectations.

What does this all boil down to? Apple’s recent policies make OS X development a lot more complicated for developers who want to keep up with the operating systems newest APIs but also are unable to comply with the restrictions associated with sandboxing. My take is that if you are developing a powerful application for OS X, odds are that you are going to have sell outside of the Mac App Store, due to sandboxing,  and live in fear of Apple one day using GateKeeper to further restrict the distribution of non-App Store apps. For another take on this, have a look at popular iOS developer Marco Arment’s post on the issue.

I know I have made some pretty strong statements here but I stand by them. If you would like to debate me on these issues or have any other feedback, find me on Google+.

Comments are closed.