Last Week on My Mac: Mojave’s half-baked Quick Actions

Mojave’s headline features include exciting new Quick Actions, lightweight editing you can do in the Finder without having to open a full-blown app.

quickactions50

Last week I’ve been looking at their state of play, and had intended completing my series with an article demonstrating how to build your own in Xcode. Unfortunately, you’re going to have to wait for that, because as far as I can see that remains one of Apple’s closely-guarded secrets.

It is one of several reasons that Quick Actions are one of the least complete features in Mojave, with less than four months to go before Apple’s expected announcement of macOS 10.15 at WWDC 2019.

The Mac has had no shortage of ideas as to how to give users quick access to tools without running leviathan apps. One of the most exciting was OpenDoc, a pioneering modular scheme introduced in 1993. It shone with promise for three or four years, must have cost Apple a great deal in engineering effort, then was abandoned.

AppleScript has been longer-lived, also introduced in 1993 but now quietly dying through neglect, despite its many remaining enthusiasts. Then in 2005 came Automator, still an amazing tool but severely stunted by its lack of bundled actions, and now in Mojave’s privacy-protected environment a minefield of unwanted dialogs.

I wanted to see whether I could build a simple Quick Action which would add the tag(s) attached to a folder to all its contents. It’s something which doesn’t seem possible in Automator without calling external code such as AppleScript or a custom-built action. I seriously considered the latter, but discovered that Xcode 10.1 (and 10.2 beta) can only make Automator Actions which are written in Objective-C, not Swift. I’m not sure whether that’s an architectural limitation, or merely lack of investment in support for automation.

Having discovered the great differences between running Quick Actions built using Xcode and those made by Automator, I then realised that an Automator workflow wasn’t a good answer either. It may look lightweight to the user, but efficient it is not: good for a quick solution to an immediate problem, but that’s about it.

The oddest thing about trying to create a software tool to support one of Mojave’s much-vaunted features is that Xcode doesn’t seem to support it. Search its Help book and macOS documentation and there’s no mention of Quick Actions at all. Some old documentation on ‘app extensions’ refers to adding a new Target to an app, and there’s even example code of a Photos extension available, but that doesn’t help you create a new-style Quick Action.

Even if Xcode were to help me create a Quick Action, there’s one major architectural issue which I can’t find discussed anywhere: how to provide some form of Undo, or access to previous versions. Without those, Quick Actions which change the content of any document are a quick way to ruin the user’s day. Mojave’s bundled Quick Actions work around this neatly: you can undo Rotate Left, which just performs a hidden action to rotate right, and the Markup editor provides an in-action Revert button.

If Quick Actions are to be more generally useful, they have to address the problem of giving the user some reversibility. Automator workflows can do that with the kludge of making a Finder copy of any document before they change it, but that isn’t a good approach for a ‘proper’ finished action. If Quick Actions can’t offer undo or access to saved versions, then they can’t be used for any serious task which modifies the content of documents.

Undo is the undiscussed problem in a great deal of lightweight solutions, including Automator and AppleScript. A steady stream of enthusiastic advanced users discover to their cost that those natty little applets they built for themselves aren’t reversible. Rescale the wrong images and your scripting skills suddenly prove dangerous, and you’re left wondering whether unmodified files are still in your Time Machine backups.

For Quick Actions to become really useful, they need a lot more work on Apple’s part. Good support in Xcode and developer documentation are fundamental steps which should have been delivered before Mojave’s release last September. That we still don’t have those over four months later is inexcusable.

But at their heart, if they can’t be used safely to change document content, they’re little more than a Finder embellishment, pretty but of no real consequence. I just hope that they have been better thought through, rather than joining the growing list of failed initiatives like OpenDoc.