AppleScript Editor

The AppleScript Editor application in OS X 10.8 includes a number of enhancements to document handling:

• Auto Save: Changes to documents are automatically saved, including changes that do not currently compile.

• Versions: Previous revisions of a document are easily retrievable using the standard version controls in the document’s title bar.

• Exporting: Available from the File menu, the Export… command saves a copy of a script or script application for distribution. Export… is now the only way to save a script as “run-only”, reducing the risk of saving over the editable original.

• Bundle Identifier: The Bundle Contents drawer for script applications now includes a field to set the bundle identifier. AppleScript Editor will fill in a default value, but it is recommended you customize the identifier for any script application that is targeted for distribution. Setting the bundle identifier has always been recommended, but previously required manual editing of the Info.plist file to do so.

AppleScript

Coercing a list to a string will now fail if one of the list items is not convertible. Previous versions would claim success with only a partial result. [2300198]

div and mod now use standard IEEE 754 routines to compute their results. This matches other languages and the rest of OS X. Previous versions would fudge the results to make certain “wrong” answers come out “right”, but this introduced inaccuracies and never worked in all cases. For further information on the issue, see What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg. [2358365]

Standard Additions

time to GMT now adjusts live to DST shifts and changes to the time zone. [7676174]

open for access can now create a file with a slash in its name. [10431973]

Gatekeeper and Signing Applets

OS X Mountain Lion includes Gatekeeper, which protects users from malicious software by applying a policy about what downloaded software is allowed to run. Gatekeeper relies on code signing to verify applications: a signed application is guaranteed to have been created by the signer and to have not been modified since it was signed. By default, Gatekeeper will allow running only applications that have been signed by the Mac App Store or an identified developer. If you write script applications (“applets”) for distribution, then this policy applies to your applets. To sign your applets so Gatekeeper’s default policy will not block them:

1. Obtain a Developer ID certificate. For details, see Distributing Applications Outside the Mac App Store in App Distribution Guide.

2. Save a copy of your applet for distribution using the Export… command. (Note: Your applet should have a unique bundle identifier, which you can set in the Bundle Contents drawer.)

3. Launch Terminal, and change the working directory to the applet bundle. (Tip: drag the applet on to Terminal, and it will create a new terminal window with the directory set correctly.)

4. Mark the main script as read-only.

   chmod a-w ./Contents/Resources/Scripts/main.scpt

   If your applet contains other scripts, also mark them as read-only.

5. Sign the applet using your code signing identity.

   codesign -s 'My Signing Identity' .

Sandboxing and Running Scripts

Sandboxing your application may require changes to how it runs scripts. The usual method in the past has been NSAppleScript, but since scripts typically rely on sending Apple events and the default sandbox profile does not allow sending Apple events to any other application, this often does not work correctly when in a sandbox. Scripts run from your application will fall into one of three categories:

• Self-targeted scripts. Your scripts only send events to your application and never to any other application. Continue to use NSAppleScript as before.

• Built-in scripts. Your scripts are built as part of your application, and will not change after shipping. Continue to use NSAppleScript, but add entitlements for sending events to the target applications.

• User scripts. Your scripts are supplied by the end user, and may use any other application. Use NSUserScriptTask. The scripts must be stored in a special location (use NSApplicationScriptsDirectory to determine where), and will run outside of your sandbox.

Sandboxing and Scriptability

Sandbox policy does not restrict receiving of Apple events, so in general, your application’s scriptability code will not be affected by sandboxing.

Your application’s scripting definition (sdef), however, should be updated to add access groups: groups of commands, classes, and so on that a sandboxed client can request to use with the new com.apple.security.scripting-targets entitlement. For example, Mail defines a “compose” access group that allows creation and editing of an outgoing message, but nothing else. This is safer than the old com.apple.security.temporary-exception.apple-events entitlement, which allows access to the entire scripting interface. See sdef(5) for details of the markup format.