Each time Apple updates iLife or iWork, I always try to take a look at the updates’ usage of the OS X Sandbox. Apple is of course free to do whatever it wants (after all it’s Apple’s platform), and in the past Apple has simply used temporary entitlements to effectively escape the sandbox. However the lack of visible dog-fooding of the sandbox on Apple’s part to date has provided little reassurance to developers who may still be working to adopt the technology themselves.

Visual inspection of sandbox entitlements is a useful check, especially if you're curious about what other apps are doing, and after reading this post by Michael Tsai there’s a very simple way to do this using Terminal:

codesign -d --entitlements - /Applications/Keynote.app

N.B. There’s a space either side of the dash preceding the app path.

So that developers can quickly look at the change I’ve put together a repository on GitHub with all the details for Keynote, Numbers, Pages, iPhoto, Aperture, and GarageBand that launched with OS X Mavericks - it seems there’s some interesting stuff in the iOS updates too, but I’ve not yet taken a look for myself.

As you can see, there’s still some Apple private entitlements in use, and GarageBand escapes the sandbox entirely by using an absolute read-write path for not just your hard-drive but any external drives too:

<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<array>
    <string>//</string>
</array>

If you’re wondering about the sbpl temporary entitlements in some apps, Daniel Jalkut has a great article to explain.

For all the gripes about using these private entitlements (or in the case of GarageBand, an entitlement strictly not available for developers to use) it’s great to see that the iWork apps sandboxed for the first time and as someone who’s still working with the migration to sandboxing it’s reassuring to see Apple start walking the walk.

Update, 16th October 2014: I’ve updated the GitHub repo with the most recent iWork updates.