One of the most welcome announcements at WWDC this year was that Apple is bringing its iOS/iPadOS automation system Shortcuts to macOS 12 Monterey. This article looks at how that’s going to work, and how it will affect users and developers.

Macs have had automation for the last 28 years, when Apple introduced AppleScript in System 7 (for those who like great precision, in System 7.1.1). However, this is a programming language which depends on apps providing support for its capabilities, and on the user learning to code in AppleScript. Mac OS X added Unix shell scripts, which had previously only been available to developers using Apple’s Macintosh Programmer’s Workshop. Although widely used on other systems, shell scripting still requires command tools and the user learning to code.

Five years later, in 2005, Mac OS X Tiger brought the automation app Automator, which is capable of running AppleScripts, shell scripts, and Actions provided by apps, in graphical Workflows. Although Automator has proved popular with many users, in general its potential has never been fully realised. This is most probably due to limited support in third-party apps, and the fact that it’s limited to macOS.

In 2014-15, a third-party app Workflow was developed and released to support automation in iOS. In addition to supporting conventional methods of triggering its workflows, it introduced the ability to run them from Siri voice commands, and those workflows could also be shared through iCloud. It proved so successful that Apple acquired it in 2017, and the following year it became a feature in iOS 12 under the new name of Shortcuts.

Shortcuts resembles Automator in many respects, and Apple has made clear that it will ultimately replace that macOS app, although for the time being macOS 12 will ship with both, and continue to support both AppleScript and shell scripts, of course. For those currently writing AppleScript and running shell scripts, it should prove a convenient way of wrapping them into Actions, and assembling those into Shortcuts. AppleScript and shell scripts can also run Shortcuts through its scripting interface.

iOS doesn’t, of course, offer Actions which run AppleScript or shell scripts, and is constrained in what Shortcuts can do. For scripts to be useful as Actions in macOS, there are serious security considerations. Apple has these in hand, apparently: for example, Shortcuts will be shareable as files which are signed by the person who distributes them, and notarized by Apple to ensure that they’re not malicious. That could explain some of the changes being made in the notarization process this summer, and is likely to add significantly to the load placed on Apple’s notarization service. However, notarization of Shortcuts files should be far simpler than whole apps.

For the user, Shortcuts looks to be a major improvement on Automator. But much of its success will depend on the extent of its adoption by third-party apps. There are several immediate problems here: Shortcuts only runs on macOS 12 and later, and has no backward compatibility with Big Sur or earlier. Every current Mac app is going to need modification to support it, even those developed using Catalyst which may already support Shortcuts on iPadOS. Currently, very little support appears to have been built into major macOS frameworks such as AppKit, or even SwiftUI. Although Apple has so far provided some broad guidelines and code snippets, existing macOS documentation is largely confined to presentations at WWDC, notably Meet Shortcuts for macOS, 10232 of 2021, and Apple hasn’t yet made any example apps available.

Apps that work with Shortcuts need an Intent definition file which defines each Intent implemented in that app. From that, Xcode automatically generates outline source code which need to be fleshed out to dispatch and handle each Intent. Apple recommends that this is performed through a lightweight standalone process to handle Intents on behalf of an app – an Intents Extension.

The upshot is that the success of Shortcuts on macOS will be largely determined by third-party app developers, who in turn will need to decide whether the additional work required is worth the investment of coding what’s needed to provide good support. If support for Shortcuts is largely confined to Apple’s apps, and a few of the larger developers, then many Mac users won’t use Shortcuts much, which in turn reduces the likelihood of developers adding good support for it. It’s a classic vicious circle.

Apple’s role here is critical. If the additions required to support Shortcuts are extensive, if good example apps aren’t provided, and if Apple doesn’t provide first-class documentation with good conceptual coverage, then Shortcuts will have a very hard road. In any case, this is a way ahead for the future, and when Monterey is released it’s most probable that third-party support will be limited. Otherwise Shortcuts on macOS could go the same way as Automator, and never fulfil its true potential, which would be a great shame given all the engineering going into it.