I have been using Mavericks for a little while now and I have to admit that I was a little slow to get excited about this release of OS X. Once I started to sink my teeth into some of the power-user features, though, it didn’t take long for me to really get sucked into trying out every new geeky addition, specifically all of the new AppleScript features.

I will be the first to admit that AppleScript is not my favorite language and I only ever use it when I absolutely have to, but, with the release of Mavericks, Apple has added some very compelling reasons to give it another chance. I was recently discussing AppleScript with a developer friend of mine, and we agreed that since Apple had begun stripping out some script-related functionality of core apps like iTunes, it would not be surprising if the language was slowly phased out of any upcoming OS releases. However, I was wrong. In a surprising turn of events, Apple decided to breath new life into AppleScript and make it easier than ever to write clean and reusable scripts.

iCloud Sync

Before we dive into the technical changes in AppleScript, let’s talk about some of the higher level additions. AppleScript and Automator were updated with iCloud file syncing. Much like TextEdit, now when you launch AppleScript Editor or Automator you are greeted with the iCloud Document Library. This shows all your documents currently stored in iCloud for those apps and you can even drag existing scripts and workflows into the library to add them to iCloud. These files will be synced across all of your Macs running Mavericks.

Code Signing

Code signing is a necessary inconvenience when it comes to sharing your AppleScripts. Now by default, the average person will not be able to run scripts that were downloaded from the Internet because of the restrictions in place by GateKeeper. This is not meant to limit those who wish to download and use third-party AppleScripts – in fact, there are several workarounds such as adjusting GateKeepers settings or Control+clicking the script to override GateKeeper.

Thankfully, it’s slowly getting easier for developers to distribute scripts while also eliminating the need for the end-user to have to perform any of these workarounds thanks to the latest improvements to AppleScript code signing. Code signing for AppleScript was first introduced as a terminal command in Mountain Lion but in Mavericks it is as simple as selecting the Developer ID certificate from the dropdown menu while exporting the script. It is extremely easy and it will promote responsible code sharing for both developers and users. To code sign scripts, you must be a registered developer with Apple.

Notifications

Notifications in AppleScript are a welcome addition to the language. I wrote previously on MacStories about how to utilize AppleScript/Objective-C to post notifications directly from an AppleScript project but it was complex and difficult implement in projects outside the sample I created. Fortunately, Apple has recognized the genuine interest in a native AppleScript/Automator API for posting notifications to Notification Center: in Mavericks, there is a new Display Notification command that can be used with a few parameters including title, subtitle, and a message to post notifications from either application.

AppleScript Libraries

AppleScript Libraries are the most interesting addition to Mavericks in my opinion. They allow users to create reusable and modular AppleScripts. As a general overview, you can now write an AppleScript Library, which is really just a script containing routines, and save it to ~\Library\Script Libraries\. Once it is saved in that location, you will be able to use it in multiple scripts by calling it with the new use clause. This should reduce the amount of repetitive code across multiple scripts.

I have created an example AppleScript library called URL Utilities and a sample script that will demonstrate a lot of the new features, like accessing a library with the new use clause. It also demonstrates creating a definition file for your AppleScript bundle so you can use your own ‘terminology’.

In AppleScript, you can create your own terms to replace routine handlers inside AppleScript libraries. You will see in my example (which is a library for accepting a long URL and returning a short URL) that I created the terms shorten url and with. When used inside a future script I can write a single line of code like shorten url 'http://someurl.com' with google and that would return a goo.gl link that points to http://someurl.com as shown in the screenshot above.

To accomplish this I had to not only create the URL Utilities library but I had to create an embedded .sdef file which houses the definitions for the custom terminology. The process for doing this is consists of typing out the XML file and dragging it to the script bundle. The syntax for the .sdef file is not well documented by Apple so take my example and use it as a boilerplate to create your own custom terms. In the example below you will see a screenshot of the example library and the contents of the bundle displayed in the pop-out drawer. The file URL Utilities.sdef is identified as the definition file and actually kept inside of the script bundle.

It is also important to note that if you do go as far as creating custom terminology for your AppleScript libraries, it will be added to the AppleScript Dictionary viewer just like every other scriptable application. You can launch the dictionary viewer and and see a break out of all the commands as well as any help documentation you may have added just as I did in my example project.

All of these features can be combined with the powerful AppleScript Objective-C (ASOC) for even more possibilities. I don’t personally use much ASOC because I know a bit of Objective-C and I find the AppleScript-flavored syntax to be a challenge to read and write; however, if you are an AppleScript power user I would highly recommend experimenting with ASOC’s capabilities.

I feel as though these features are useful but not so much that I am going to choose AppleScript over a more powerful language like Python or Objective-C to do anything more than simple automation tasks. Overall, Mavericks does elevate AppleScript to a certain level of relevance once again. I might consider using it for more of my Alfred workflows or Hazel rules now that I can build out simplified and re-usable blocks of code in Mavericks’ new AppleScript libraries. 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.