Mac OS X Automation covers new AppleScript features in Mavericks:
In OS X v10.9 or later, when you create or change documents using the AppleScript Editor or Automator applications, iCloud can keep the scripts, workflows, and applets up to date in those editors on your other Macs.
Code Signing support has been added as an export feature to both the AppleScript Editor and Automator applications, enabling Apple developers to easily generate signed copies of their applets and droplets.
AppleScript Libraries provide a new plugin architecture for extending the power and abilities of AppleScript. AppleScript Libraries are user-created script files and bundles, composed in AppleScript or AppleScript/Objective-C, which contain specialized commands that can be referenced in scripts to provide extra or “missing” functionality.
For its 20th anniversary debut in OS X Mavericks, AppleScript delivers a long-sought ability: an import command — dramatically extending the scope and power of this unique language.
A new AppleScript construct, called the “use statement”, imports the terminology and functionality of AppleScript Libraries and scriptable Applications through a simple single-line declaration placed at the top of a script, such as:
use application "Finder", or:
use script "My AppleScript Text Library".
No longer will scripts and workflows have to display dialogs to inform users that time-consuming or complex automation processes have completed. With integrated notification support for AppleScript and Automator, users can leave their automation processing unattended, confident that they will be notified of the results in the built-in Notification Center.
In OS X Mavericks, security controls are more granular, requiring the individual addition of applications, or automation applets that script the accessibility frameworks, to an approval list, displayed in the Security & Privacy system preference pane.
In OS X 10.9, AppleScript introduces an alternative syntax for calling handlers and methods. Instead of using underscores and running the terms together, like this:theString's writeToFile_atomically_encoding_error_(thePath, true, current application's NSUTF8StringEncoding, missing value)
You use an interleaved syntax similar to Objective-C, like this:theString's writeToFile:thePath atomically:true encoding:(current application's NSUTF8StringEncoding) |error|:(missing value)
This is great for AppleScriptObjC. Unfortunately, although you can use the interleaved syntax for your own handlers in regular AppleScripts, you still cannot call into the Cocoa frameworks from regular AppleScripts (like you can via the PyObjC and RubyCocoa bridges).Don Southard:
Most of all, I am happy to see Apple putting a focus on the power user with these enhanced automation tools and I hope it is a sign of the bright future OS X still has had of it.
But improvements in the AppleScript language itself are like the proverbial tree falling in a forest. If no applications bother to use AppleScript, do those improvements exist? Not in any practical sense. No one in their right mind uses AppleScript as a standalone language; it’s all about adding functionality to an app or acting as glue between apps.
Stay up-to-date by subscribing to the Comments RSS Feed for this post.