OS X Mountain Lion (10.8) Is Not Good News For Developers

While I’m stil processing the information coming out about OS X 10.8 (Mountain Lion), the talk in the office has been anything but positive. It all revolves around apps.

UPDATE: As some commenters have pointed out, the GM release of Mountain Lion did enable the Notification Center APIs for non-App-Store apps. While this is a positive move, there are still a few restricted APIs (iCloud, and the argument can be made that this is a positive or negative thing) but sandboxing and OS-refusal to run unsigned apps continue to be hard pills to swallow.

UPDATE 2: It looks like sandboxing is so restrictive, that Apple is using private exceptions and security scoping in their apps that aren’t available to developers. It’s easy to play by a different set of rules if you’re Apple, but it’s further indication that you can’t play on par in the OS anymore.

Gruber did a nice writeup about his experience with the Apple Event For One and new features in 10.8, but makes the following statement that I find to be relatively uninformed:

This default setting benefits users by increasing practical security, and also benefits developers, preserving the freedom to ship whatever software they want for the Mac, with no approval process.

It’s true, you know, that there is a security interest here. However, it is crippling to development. Here are a couple reasons why:

  1. Unsigned software won’t run unless you hop in to the OS settings. For practical purposes, it makes signing almost necessary. The problem is that any old signing won’t do – I can’t get a Verisign cert and use that. Apple holds all the keys here.
  2. Signed software can’t load unsigned (compiled) plugins. There are a plethora of apps that you probably use on a daily basis that load plugins. They range from launchers (like LaunchBar, Alfred, etc.), to IM clients, professional tools for design, music, and movie creation and editing, and so on. Many apps make use of plugins to extend functionality and separate features in a logical fashion.
    1. The flip side to this is that you can make all plugins Javascript or Python or Ruby, but then not only are they slower, but they’re completely open-source. The license may not be open source, but code is definitely available for all to see.
    2. While developers may be able to statically link to their own plugins, any software that encourages plugin development from the community will suffer.

Apple’s strategy has been termed, in our office, “boiling the frog.” It’s the old adage of a frog tossed in to boiling water will hop out, but put it in room-temperature water with the water temperature turned up slowly will not notice and will eventually boil to death. Apple’s strategy is easy to see.

I can understand people thinking I’m overreacting, but here’s where Apple is boiling the frog – now it’s signed apps, but you can still run unsigned ones with effort. If Apple is willing to give out signing certificates for free, requiring all apps to be signed is easily imagined in 10.9. But oh, there’s more – some of the more interesting new frameworks in 10.8, like Notification Center and iCloud, are only available to apps sold through the App Store.

The nail in the coffin is this – starting March 1, all apps submitted to the Mac App Store will have to be sandboxed. To quickly review what that means, apps will only have access to their install directory and perhaps their preferences directory, and will be unable to do things like access the general file system, hook in to OS-level functions, and so on. This effects the above-listed apps, as well renders useless apps like Little Snitch, Dropbox, Transmit, Git and SVN apps, across-file search functions in text editors like TextMate and Sublime Text, and so-on.

If all apps have to be signed, and in order to sign them Apple holds the keys, and in order to use all the frameworks you have to use the app store, and if you sell your app in the app store it is required to be sandboxed, well, you can see where this is going. The water is getting a lot hotter for Mr. Frog.

If you’re still a little confused about sandboxing, you can think of it like iOS on the iPhone and iPad – each app runs in its own space, can’t communicate with other apps, doesn’t have access to lower level OS services, and so on.

Of course, you can, when submitting an app to the App Store, write an essay (not kidding) about why your app needs to be able to step out of the sandbox in certain ways. However, you’re at the mercy of Apple also thinking you should have such permissions, that your app should be allowed to do what you developed it to do… And even if you do get approval, by the way, it can be revoked at any time.

There is going to be an awful lot of talking about these new policies in the coming months. I’m hoping things end up getting hashed out in the favor of developers – and the users who rely on their apps daily.