The M1, macOS Monterey and the next Mac power shift

More than ever, the Mac is Apple’s power tool. Today’s Macs running Apple silicon can use the complete library of macOS apps, and apps from iOS via Catalyst or unmodified directly from the App Store. And then there’s everything that’s under the hood, from app scripting to Unix-based tools of all sorts.

But with the move to Apple silicon and Apple’s announcement in June that Shortcuts is coming to the Mac as a part of a multi-year automation transition, things are changing. While the Mac isn’t going to stop being a power tool, the next few years will change its nature in some fundamental ways.

Shortcuts replaces Automator

The news that Shortcuts is coming to replace Automator (and make no mistake, that’s what will happen) isn’t just important because macOS has a shiny new tool for user automation. It’s also an important sign that Apple is paying attention. In the last few years, it’s been tough for Mac app developers to feel like there was any point in adding automation features to their apps. But now we’ve got the answer: Shortcuts is here, and Apple’s going to be spending a few years in the transition to a new world.

Beginning this fall, you’ll start to see Mac developers adding support for Shortcuts. As on iOS, apps will “donate” actions into the Shortcuts app. The power of the apps you use accumulates to Shortcuts. In some cases, those actions will open the app and cause it to perform a task. In others, it might not even need to open the app visibly, but can apply a portion of its power to whatever problem needs to be solved.

Shortcuts gets Unix power

Shortcuts on the Mac also goes beyond what’s available on iOS and iPadOS by being able to hook directly into Unix scripting and shell support—with one big catch. Apple has committed to no longer including common Unix scripting systems with macOS. In macOS Monterey, PHP has already departed, and Perl and Python are older versions that will be removed soon enough.

This is no big deal on one level: you can still install the latest versions of PHP, Perl, and Python on macOS. (I use Homebrew to do it.) On the other hand, if you’re building an automation that relies on one of those scripting languages, you’ll need to install them on any Mac that you want to automate.

What about the other scripting languages?

This leads us to the bigger question: What happens to AppleScript and the Apple Events technology that has kept inter-application communication alive on the Mac for decades? iOS doesn’t have an equivalent to Apple Events. Passing URLs back and forth became the standard method of communication, believe it or not. But Apple has recently been modernizing with features such as Siri Intents.

The truth is, most automation on iOS has been about building workflows using little pieces of different apps. That’s an important part of the user automation story, but another part is the ability to deeply control powerful apps via scripting. On iOS, apps with this level of control tend to use a self-implemented macro engine based on JavaScript or Python. Perhaps the best example of this is The Omni Group’s rich JavaScript-based automation, which lets scripts control Omni’s apps—on iPad, iPhone, or Mac.

Every app implementing its own scripting or macro language is not a path forward. This is where Apple needs to step in as the platform owner and create a common frame of reference for everyone, developers and users alike.

The future of scripting on macOS

What happens at the end of this years-long transition? The easiest guess is that AppleScript, which dates from the early 1990s, will be put out to pasture at last.

What will replace it is more of an open question. Shortcuts can’t be the end-all, be-all on its own: it’s just not a tool geared for the level of precise remote-control of applications. Also, the more actions you put in a shortcut, the more complex it gets—and beyond a certain point, it probably should be written out as a script rather than assembled in a simplified interface. (Witness Jellycuts, which is a scripting language designed to make Shortcuts!)

I’d prefer a system that lets scripters choose what language they want to use. (Nobody ever talks about it, but Apple added JavaScript as a peer to AppleScript for scripting on the Mac a while back.) More likely, though, is that Apple will pick an official scripting language. Maybe it’ll be JavaScript since it’s ubiquitous and Apple’s been there before. Or perhaps it will be the obvious: a simplified version of Swift.

And maybe, just maybe, Apple will build this automation system once and deploy it not just on the Mac, but on the iPhone and iPad as well.

This is tough stuff. This is why Apple was so clear in calling this a multi-year transition. Shortcuts on the Mac is going to be a great first step, but there’s a lot more work to be done before the next generation of Mac user automation is ready to lift the burden from the last. It might take years, but the future is bright.