Archives for October 2011

If you're a Mac developer, then you are probably aware that Apple will soon be requiring all applications submitted to the Mac App Store be sandboxed.  A sandboxed AppleScript-based application is kind of an oxymoron. Sandboxing denotes that an application will run in its own isolated environment, for security reasons.  Meaning that it doesn't have access to other applications on your Mac.  However, this goes against the nature of AppleScript, which is designed as an inter-application scripting language.  By writing AppleScripts, you can intertwine your various applications together to form complex workflows and automate time consuming things you would otherwise need to do manually.

So, how can you, an AppleScript developer, deal with sandboxing and get your app into the Mac App Store?  You can request temporary entitlements (translation: may not be supported in the future) for the apps and processes with which your app interacts.  Here are the general steps, which will vary depending on the actual function of your app:

1. Use Xcode to create your Cocoa-AppleScript app (AppleScriptObjC app)

2. In the Project Navigator, select your project

3. In the Project Editor, select your app's target

4. In the Summary tab, configure the following settings:

click to enlarge

- Enable Entitlements - Select this checkbox to turn entitlements on for your app

- App Sandbox - Select this checkbox to turn sandboxing on for your app

- File System - If you plan to use file/folder user interaction commands, such as "choose file", "choose folder", and "choose file name", then set this dropdown to "Read/Write Access".  Do the same if you plan to use commands such as "open for access" and "write".

5. In the Project Navigator, select the .entitlements file that should have been created automatically

6. Add an entry for "com.apple.security.temporary-exception.apple-events".  If you will have multiple entitlements, set this to be an array. Otherwise, set it to a string.  Add UTI entries for each application your app needs to target. For example, for the Finder, add "com.apple.finder". For iTunes, add "com.apple.itunes". If you don't add a temporary Apple Events entitlement and the necessary UTIs, then your app will produce errors when attempting to target external applications.

click to enlarge

7. If your app will write to a directory in the user's home folder, add an entry for "com.apple.security.temporary-exception.files.home-relative-path.read-write".  Set this to be an array, and add paths to any folders you will write to, beginning each with a slash. I.e. /Desktop/ represents the user's Desktop.

That should do it.  Build and run your project, and check Xcode's debug console for problems.

Download an example of a sandboxed Cocoa-AppleScript Xcode project here.

Official documentation for sandboxing an app can be found on Apple's developer website.

• Code Signing And Application Sandboxing Guide

Note that sandboxing doesn't affect strictly AppleScript applications.  Other applications could potentially be affected, as well, including Automator* and numerous popular third-party applications.  Well, to be fair, these applications could still work.  They just couldn't be submitted to the Mac App Store once Apple's sandboxing requirement goes into effect, at least not without employing temporary entitlements.

For more on the growing controversy regarding sandboxing and inter-application communication, check out:

• App sandboxing risks eroding the Mac's Identity by Andy Ihnatko
• The App Culture by Jason Snell
• The App Store, Sandboxing, and AppleScript

* In theory, Automator actions contained within a sandboxed application should not need to be sandboxed themselves.  This is because they would technically fall under the scope of the application that loads and runs them - in this case - Automator.  So, their capabilities should be governed by Automator's sandbox, which, due to the nature of Automator, should allow them to run unimpeded.