Applescript and Sandboxing

Posted on July 29, 2011
Filed Under Applescript, Commentary, System | 4 Comments

So I’ve been hearing that Applescript is going the way of the dodo. Apparently the model for sandboxing Apple is using more or less makes it impossible to write your application in an Apple Event savvy way. Apple is very concerned about security and perhaps understandably Applescript is a huge issue in that regard. In fact starting in November all applications in the App Store will be sandboxed. Given the incompatibility of sandboxing and Applescript one might suspect as a practical matter that all useful Applescripts begin ending then. It’ll probably take some time. (After all even Apple’s Lion apps support Applescript right now the same as they did under Snow Leopard) It may well explain why Apple hasn’t extended Applescript in any of their applications.

The big question will be what they will do with Numbers whenever its upgrade eventually comes up. (Perhaps this is part of the delay?) Is Apple coming up with a more secure alternative to Apple Events? Heaven knows people have been grumbling about Applescript for years.

Right now Apple has an interim fix with scripting applications like iTunes called temporary entitlements. These are ways to get through the sandbox that really aren’t safe but for which Apple’s not come up with a good alternative. Applescripting is the biggest example of an unsafe practice Apple is allowing. The very emphasis from Apple on temporary doesn’t exactly inspire confidence here. Worse, while these temporary measures let applications receive Apple Events they can’t send them if they are sandboxed. Quite a few developers who utilize AppleEvents in their applications are either slowing development on those aspects or dropping them altogether. (See for example here)

Fastscripts right now is trying to get into the App Store.  I have a suspicion they won’t be able to come November.  Quickeys (my macro program of choice) doesn’t even try.

My honest hope is that we just get something better. Apple’s not exactly show a lot of Applescript love in years. The cynical person thinks this is because Apple doesn’t care about scripting by power users. The optimist thinks that Apple knows how bad Applescript and Apple Events are and is coming up with a strong alternative — perhaps based on Python or Ruby.

For more info see Apple’s developer notes on Sandboxing.

Edit: I erroneously indicated above that you had to set your sandbox entitlement to receive Applescripts. You don’t. By default all applications can receive and respond.  However to send you need a temporary exception for specific applications. There is no general case for applications like Fastscripts or Quickeys.

My bigger point remains that Apple seems to be backing out of a generalized scripting system. That said I am appreciative of all the discussion that’s gone on this weekend. Both correcting my erroneous views but also indicating at least some support for Applescript.  I’ll probably do a further post on the issue in a few days since I do think looked at broadly Apple’s commitment to Applescript has been very weak.

Edit: Dr Drang has a related post up worth reading.

Related posts:

  1. Applescript: Things that Make You Go Huh?
  2. Replacing Applescript?
  3. Applescript: Not Dead Yet
  4. Making Applescript More Useful
  5. Applescript Shell

Comments

4 Responses to “Applescript and Sandboxing”

[...] one. The authors of the program apparently hate Applescript so don’t hold your breath. (And as I’ve said it’s not clear what Apple’s actual stance towards Applescript is [...]

[...] problem. Otherwise come November it’ll be a big shock to a lot of Mac power users.  (See my post on Applescripting and sandboxing for more info — the problem applies to a lot more than scripting [...]

I wrote a blog posting about this too: http://bornsleepy.elegantchaos.com/bornsleepy/sandboxing-and-neu

I agree that it’s a bit of a worry.

[...] However, it also can automate file transfers or photo editing – and will no longer be usable by sandboxed applications. Instead, AppleScript will theoretically be replaced by APIs (application programming interfaces) [...]

Leave a Reply