With the imminent release of macOS Monterey comes a new system for scripting and automating the Mac: Shortcuts. As an introduction to future articles about Shortcuts and how to get more out of it, this article provides an overview of the last 28 years of scripting the Mac.

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.

Scripting concepts

The concept behind AppleScript is simple: scripts that compile to a series of instructions for despatch by macOS 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 macOS. Those, and the suites of additional commands that bring joy to the scripter, are documented in standard formats within an 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 disk being mounted, 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
end tell
if mailIsRunning then
-- do one thing
else
-- do another thing
end if

You might use that code to set up a script that interacts with the Mail application. It first asks macOS 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’re 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 macOS to fire off AppleEvents (AEvents) to trigger the target applications to perform the actions.

App support

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 haven’t provided scripting hooks into its data and features, you cannot engineer them in yourself. If your favourite image editor doesn’t give scripts access to its filters, then you’ll be unable to use those filters in your scripts.

An app which is well designed for scripting shouldn’t 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 macOS, provide an extensive suite of commands and classes to support a GUI front end, including dialogs, alerts, and more.

macOS support

In recent years AppleScript has languished a bit, no longer being plugged by Apple as a leading feature of macOS. 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 brief revival when Xcode 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 macOS.

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 with OS X 10.4 in 2005 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’s 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. macOS 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.

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 Instruments’ 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, and was last seen as its successor Marten.

Enter Shortcuts

Shortcuts started out in the winter of 2014-15 as Workflow by DeskConnect. Apple bought it in 2017, and it became Shortcuts the following year, when it was integrated into Siri in iOS 12. Its arrival in macOS 12 was announced at WWDC this year (2021), as the successor to Automator, although Apple intends supporting both for the time being.

While Shortcuts on macOS can run AppleScript and shell scripts, the mechanisms involved in Shortcuts’ actions are completely different from AppleScript and Automator. For an app to support all three well requires it to present four different interfaces: one for the user in the GUI, AppleEvents, Automator actions, and now Shortcuts actions.

Four months after WWDC, Apple has released precious little documentation for developers; indeed, what it has produced in Xcode to date states that the interface required to support Shortcuts isn’t generally available in macOS 12, but is confined to Catalyst apps, which contradicts presentations given at WWDC, which stated clearly that Shortcuts was supported in AppKit, which is generally accessible. As a result, for most third-party developers Shortcuts support is unlikely to be feasible with the release of Monterey, and the only support is going to come in macOS itself and Apple’s own apps, much of which is still based on Shortcuts in iOS and iPadOS.

Over the coming weeks, I’m going to be looking in more detail at what Shortcuts on macOS has to offer both the user and the developer. Wish us luck!