Rewriting the AppleScript

Andy Ihnatko, Macworld
19 October, 2011
View more articles fromthe author

I refuse to get upset about the tight level of control that Apple maintains on its products, and by extension its developers and its users. It comes down to this:

1) Yes, Apple hardware comes with restrictions that would be insane in any other context. But…

2) 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 program to be rock-solid on the current OS and hardware, and they’d like their applications to work on future editions without much, or any, modification. And…

3) 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.

4) 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.

My iPhone and iPad are rock-solid. They have huge libraries of trustworthy and extremely high-quality apps. I never need to crack my MacBook open. The Mac App Store allows me to install, authenticate and update my software on all my Macs via a single iTunes Store sign-in.

And, beginning in November, all apps submitted to the Store must be sandboxed. Sandboxing is a pain in the butt for developers, but its practical benefits for users are crystal-clear: In a sandboxed world, no running process can interfere with any other running process.

The Lion version of Preview 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.

The whole point of sandboxing is to isolate the processes running in your system, and prevent them from interacting in any way with any other process. But, 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?

See you later, Automator?

I should do the responsible thing at this point and clarify that Automator and AppleScript are alive and well in Lion. Also, Apple has implemented sandboxing in such a way that inter-application communication isn’t 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 screwed. Developers can request the proper entitlements for their software, but it’s a little bit like asking security at the airport to pretty please allow you to keep your bottle of Dr Pepper. Unless you’re carrying a badge, it ain’t gonna happen.

I fret about AppleScript. I’ve come to think of it as an infinitely resourceful friend who’s been working for 20 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 feel like automation is a feature worth rescuing if the building is on fire.

Do I fret needlessly? You tell me. Recently I had an idea for a tool that would make my life easier. It required some scripting of the Preview app. In all my years of scripting, I’ve never done anything with that app so it came as a surprise when I tried to open its dictionary with the AppleScript editor and found 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: It’s unscriptable. Preview is well-represented in Automator so why on Earth wouldn’t Apple’s utility for viewing, modifying and converting images and PDFs be a superstar of scriptable apps?

Now you’re HyperTalking

Traditionally, the mandate of an operating system is to enable a machine’s potential. High-level software is responsible for making computers easy to use. Sometimes that means putting the power tools high on a shelf so the kids can’t hurt themselves, but those resources should be there for those who want them.

And traditionally, Apple’s desktops have been about ‘power to the people,’ even if those people want to write software. The Apple II 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 under thirty minutes. Learn the HyperTalk scripting language (the inspiration behind AppleScript) and you could create a sophisticated and impressive app. HyperCard opened up a vast 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 load of spray cans and a blank wall and our immediate response will be to ask you to stand 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, they should, at the very least, treat AppleScript and Automator like the gems that they are.

One Comment

One person was compelled to have their say. We encourage you to do the same..

  1. Jamie says:

    Ah HyperCard, I remember spending many hours creating HyperCard stacks and doing all kinds of cool things (or at least I though that they were at the time! This was back in the late 80′s after all).

Leave a Comment

Please keep your comments friendly on the topic.

Contact us