Old, often neglected, and only available on Macs, AppleScript should have been overwhelmed by numerous other scripting languages – if it were not for its unique abilities.
The release of Apple’s System 7 Pro, version 7.1.1, in October 1993 brought a new programming language, based on the ‘natural’ English-like syntax of HyperTalk, HyperCard’s scripting language. AppleScript is designed to give users and developers direct control over the applications on their Macs, and was quickly supported by professional products such as QuarkXPress, as well as Apple’s own rich software portfolio.
The concept behind AppleScript is simple: scripts that compile to a series of instructions for despatch by OS X to their destination application, which in turn is controlled by those commands to perform a co-ordinated sequence of functions. At their simplest, these can open a document and print it, for instance. At their most complex, they can automate intricate and repetitive tasks that are messy in a GUI.
As a minimum, every application supports a small core of commands to play clean with the Finder and OS X. Those, and the suites of additional commands that bring joy to the scripter, are documented in standard formats within each application’s dictionary, which can be browsed by Script Editor and other tools. Rather than having to locate additional documentation sets specific to each application, all a scripter needs do is open the dictionary.
View a dictionary and you will see what at first appears very complex: long listings of data types (classes, which are instantiated into objects when they are used), such as application, window, file, and text, and methods (commands) that are applied to the objects of each class. There are also events, notifications that something has occurred, such as a DVD being inserted, or a file being added to a folder.
This complexity arises because AppleScript is in fact an object-orientated language as sophisticated as Objective C, used by pro Mac developers; do not be deceived by its apparently relaxed and informal style, with examples such as
tell application "System Events"
set mailIsRunning to application process "Mail" exists
if mailIsRunning then
-- do one thing
-- do another thing
You might use that code to set up a script that interacts with the Mail application. It first asks OS X whether it knows that Mail is running, and depending on the answer it executes the code that you insert where the comments (prefaced by
‘--‘ characters) are placed.
Unlike the great majority of programming languages, punctuation marks are used sparsely in AppleScript, making it considerably easier to write code that works, rather than tripping over a missing semicolon.
When you are ready to test your script, it compiles into intermediate code, and the editor automatically checks, formats and colours your source code, reporting any errors that it finds. When run, the intermediate code works through OS X to fire off AppleEvents (AEvents) to trigger the target applications to perform the actions.
Two inherent problems limit what you can achieve in AppleScript: the support built into each application, and the fact that common GUI devices such as dialogs are not fully controlled by AppleEvents.
No matter how wonderful an app might be, if its developers have not provided scripting hooks into its data and features, you cannot engineer them in yourself. If your favourite image editor does not give scripts access to its filters, then you will be unable to use those filters in your scripts.
An app which is well designed for scripting should not make the scripter wish they could control all the options in any of its dialogs, because the features that are implemented in dialogs should be supported more directly in the app’s dictionary. For example, our hypothetical image processing app might display a dialog to allow the user to adjust a sharpening filter. Good support for scripting would be for the sharpening filter command to include the same options that are set in the dialog, but as data passed in the function call.
Because AppleScript works at a fairly high level, it can only usefully be extended by means of special compiled modules, Scripting Additions, known by their file extension of .osax.
These are stored in ScriptingAdditions folders in each of the Library folders, which you can augment from freeware and shareware OSAX to add XML handling and more. Apple’s Standard Additions, bundled with OS X, provide an extensive suite of commands and classes to support a GUI front end, including dialogs, alerts, and much more.
AppleScript is also used in mechanisms to extend and customise standard apps. For instance Mail’s rules, Folder Actions, and Address Book Plugins are all written in AppleScript, and dedicated script development systems, such as Late Night Software’s costly but superb Script Debugger ($199), provide standard templates to help implement them.
OS X support
In recent years AppleScript has languished a bit, no longer being plugged by Apple as a leading feature of OS X. Prior to OS X, Apple built admin front ends for IBM AIX servers in AppleScript, and for a while looked set to change the course of software engineering to small modular apps orchestrated by scripts, peaking in OpenDoc and its Internet suite Cyberdog (1996-7).
One of AppleScript’s most exciting abilities, letting you record sequences of actions into scripts, has faded into unjustified obscurity.
More recently it enjoyed revival as the XCode software development kit included AppleScript Studio, encouraging scripters to craft full-blown apps around an AppleScript core. Proponents of other scripting languages such as Java and Ruby have enjoyed patronage in cross-platform applications such as those in Adobe’s Creative Suite, but AppleScript lives on undaunted in OS X 10.10.
Yosemite’s security systems, the application sandbox and Gatekeeper, do make scripting a tad more complex, but Apple has not done anything that should disturb your ability to develop and use your own scripts.
Applications obtained from the App Store are more rigorously controlled, and their developers now have to get permission from Apple before their app can perform certain tasks, like controlling another app. Your own scripts can still do that, as you are considered to be grown up enough to have complete control over your Mac.
Gatekeeper keeps an eye out for apps and other code obtained from outside your Mac which does not carry an approved developer signature. Again, depending on its settings, it should not worry about your own handrolled scripts, but is likely to alert you to scripts that you have downloaded but lack a signature. You can still, of course, be trusted to run them if you want to.
However if you want to distribute your own scripts, or apps derived from them, you should look into obtaining your own signature from Apple, so that your users can benefit from Gatekeeper rather than cursing it.
It is dangerous to predict the future of any part of OS X. Fears that Apple intended merging OS X and iOS are fading, now that Yosemite has kept its distance, and AppleScript is never likely to appear on devices like iPhones and iPads because of its security implications. So long as AppleEvents remain a key to handling the rich range of events in OS X, AppleScript should remain a valuable tool for both users and developers.
Tools: Wider Horizons
Once you have cut your scripting teeth using the free AppleScript Editor, you should look at proper development tools. There are two main platforms: Satimage’s SMILE, and Late Night Software’s commercial Script Debugger. Although the latter may appear costly, a trial run should convince you of the value that you get for your money.
Working with large and complex dictionaries can be deeply confusing. Although structured rigorously – and here you will come to appreciate the clarity of AppleScript’s approach to object-orientated programming – it is all to easy to become lost unless you have a structured image of the different classes. Here Script Debugger pays off with its graphical tree representation of the class hierarchy in each dictionary.
Used as a straight debugger, it enables you to step through a script examining intermediate results, so that you can work out where and why any bugs occur; for despite its facile syntax, it is just as easy to create bugs in AppleScript as any other programming language.
Without a proper debugger, the best you can do is insert ‘log’ commands, making the task long and tough. A good debugger pays for itself in the time and grief that you save, and should be your first investment in programming.
OS X also allows to you send AppleEvents to networked Macs, when you enable the Remote AppleEvents service in the Sharing pane. If you wish to do so, be assiduously careful to ensure that your firewall blocks incoming AppleEvents (TCP/UDP on port 3031); although it is very unlikely that an attacker would exploit that vulnerability, the potential damage could be very great if someone did.
With Remote AppleEvents you can script applications running on other Macs, as if using ssh on steroids – serious power, but remarkably infrequently used.
Alternatives: Automator and Visual Programming
Even ‘natural’ programming languages like AppleScript have to be learned, a task that many of us find too verbal and mechanical. Recognising this, Apple introduced Automator in OS X 10.4 to help produce custom workflows and apps using more intuitive visual tools.
Although Automator is often assumed to be a development of AppleScript, apart from its ability to run AppleScript objects, it is actually quite different. Instead of relying on AppleEvents and dictionaries, Automator’s modular actions are separate code objects installed in the Automator folder in a Library folder. OS X comes with a huge free library of actions that can accomplish tasks you might pay good money for, so familiarity can save you cost.
Automator is highly extensible, as its actions can include both AppleScript code and Terminal shell command scripts. Thus if you cannot find a standard action to do what you want, if it can be expressed in a suitable script, you can build that into your workflow.
Sadly Automator has not achieved the recognition or following that it deserves; the few sites such as Automator World and automator.us which provided additional support appear moribund, although Automated Workflows still offers various Action Packs.
Automator is much easier for the visually adept non-programmer, because it uses graphical objects to model the flow of data through its program steps. In this, it is the latest in a long line of only modestly successful attempts to offer ‘visual programming’. Two earlier efforts at this are National Intruments’ LabView, and ProGraph.
LabView is used in a wide variety of scientific and engineering situations, to control lab equipment and process data acquired from it. ProGraph was a general-purpose visual programming language which once attracted a small but enthusiastic following.
A small group in Canada has continued to develop a successor, now named Marten. The latest release seems compatible with current OS X, and is available free from Andescotia.
Updated from the original, which was first published in MacUser volume 28 issue 19, 2012.