App sandboxing risks eroding the Mac's identity
So far I’ve refused to get upset about the tight level of control that Apple maintains on its products, and by extension its developers and its users. To me, it comes down to this:
Yes, conceptually, Apple hardware comes with restrictions that would be insane in any other context. But
Nearly all of these restrictions have an obvious and practical benefit to the developer and the consumer. Both of those kinds of people want every app to be rock-stable on the current OS and hardware, and they’d like their apps to work on future editions without much, or any, modification. And
Nobody’s forcing you to buy Apple’s hardware. If you don’t agree with Item Two, go right ahead and buy yourself some other computer, phone, or tablet.
There is such a thing as competition. If Apple consistently goes too far with Item One in their pursuit of Item Two, Apple will ultimately pay the price. That’s what encourages them not to become a bunch of total jerkweeds about it.
My iPhone and iPad are rock-stable. They both have huge libraries of trustworthy and extremely high-quality apps. My MacBook is designed so that there’s never a real need for me to crack it open. The MacOS App Store allows me to install, authenticate, and update all of my software on all of my Macs via a single iTunes Store signin.
And! Beginning in November, all apps submitted to the Store must be sandboxed. Sandboxing (one of Lion’s star features) is a pain in the butt for developers but its practical benefits for users are crystal-clear: ideally, in a sandboxed world, no running process can interfere with any other running process, no matter how naughtily it’s behaving.
The Lion edition of the Preview app is sandboxed. So, if you open a PDF file that contains malicious code that tries to inject itself into the OS, the malware won’t execute.
Fab! I duly noted all of this when I wrote my review of Lion this summer and then I mostly put it out of my mind.
It took me a few weeks to realize something: the whole point of sandboxing is to isolate all of the processes running in your system, and prevent any one of them from interacting in any way with any other process. Annnnd… controlling all of the apps and functions on your Mac is the whole point of Mac OS X’s automation features.
Can AppleScript and Automator have any future on an operating system where every app is surrounded by an impenetrable steel shell of distrust? (For more on this, see Jason Snell's take.)
Apple fails to support itself
I suppose I should do the responsible thing at this point in the column and clarify that Automator and AppleScript are both alive and well in Lion. Also, Apple has implemented sandboxing in such a way that interapplication communication isn’t outright forbidden. It’s simply controlled. AppleScript and Automator have the proper system-level entitlements that allow them to perform their sacred voodoo.
The only immediate Big Bad Impact of sandboxing on automation is that apps that want to control other apps via AppleScript are kind of hosed. Developers can request the proper entitlements for their software but that’s a little bit like asking the TSA agent at the airport to pretty please allow you to keep your 20-ounce bottle of Dr. Pepper. Unless you’re carrying a badge or wearing more than two Super Bowl rings, it ain’t gonna happen.
But I fret about AppleScript. I’ve come to think of it as a brilliant and infinitely-resourceful friend who’s been working for twenty years at a company that doesn’t seem to appreciate all of his or her contributions. I’m not worried about Apple killing AppleScript outright; I’m worried that the company doesn’t collectively feel like system automation is a feature that’s worth rescuing if the building ever caught on fire. Some day, Apple’s OS engineers will come up with an idea for a new system architecture that delivers a long list of benefits but which will require tons of work to prevent it from breaking AppleScript. And at that point, scripting on the Mac will finally die.
Do I fret needlessly? You tell me. Recently I had an idea for a tool that would make my life much easier and it required some scripting of the Preview app. In all my years of avid scripting, I’ve never done anything with that app before and so it came as a surprise when I tried to open its dictionary with the AppleScript editor and I discovered that it had none.
Horrors! Apple touted Preview as a shining example of a super-sandboxed Lion app. Was this a sign that sandboxed apps can’t and shouldn’t be scripted?
Nope. I searched the boards of various scripting sites and was reminded why I’d never tried to script Preview before: because it’s unscriptable. It doesn’t support even the AppleScript equivalent of tourist-level French, and it never has.
Preview is one of OS X’s core utilities! It’s well-represented in Automator, but why on Earth wouldn’t Apple’s own utility for viewing, modifying, and converting images and PDFs be a superstar of scriptable apps?!?
I’m beginning to wonder if the longtime situation with AppleScript wasn’t just the leading edge of a dangerous storm that’s about to make landfall. Traditionally, the mandate of an operating system has been to enable all of a machine’s potential. Higher-level software is responsible for making a computer easy to use and sometimes that means putting the power tools high enough on a shelf that the kids can’t hurt themselves, but those resources should be there for anybody who looks for them.
And traditionally, Apple’s desktops have all been about “power to the people,” even if those people have been interested in writing software. Apple II’s came with a complete printed disassembly of its source code; it inspired kids like me to learn assembly language and figure out how to make a computer do wonderful and bizarre things. Macs shipped with HyperCard, an utterly glorious graphical app builder that allowed anybody to create a useful app in less than thirty minutes. With just a little more time, and by learning the HyperTalk scripting language (yes, the inspiration behind AppleScript) ordinary people could create sophisticated and impressive apps. And create they did; name any esoteric niche, and there was a library of gloriously useful HyperCard stacks for that subject.
More often than not, each one was the very first piece of software that its creator had ever written. HyperCard opened up a vast new pool of developer talent and demonstrated that programming is a creative art.
Why has Apple forgotten that wonderful legacy? Mac users are doers, not consumers. Give us a choice between a 4-pack of Crayolas and a page full of lines to color inside or a backpack full of spray cans and a blank wall and our immediate response will be to ask you to stand right here on the corner and give the trash can a loud kick if you see a cop car coming.
The Mac must never, ever become a consumer product like the iPad, saddled with artificial limitations in the name of safety, reliability, and tidiness. If Apple refuses to give us the 21st-century equivalent of HyperCard, why can’t they at the very least treat AppleScript and Automator like the gems that they are?