The State of Mac Automation

The Apple world has undergone a huge change in automation options in the last few years, requiring you to learn new skills, change old habits, and perhaps even buy and configure some new software—all in the interest of getting your Mac to do more work for you.

Through the first edition of this book, in 2014, I thought the direction Apple was likely heading was towards more and better automation capabilities, and with various Apple teams paying greater attention to automation. Since then, signals have become decidedly more mixed.

For starters, Sal Soghoian was laid off in late 2016. Sal spent 20 years at Apple as the company’s main internal and external evangelist for automation; his title was Product Manager of Automation Technologies. Apple’s explanation was they eliminated the position for business reasons, not for personal ones (see Tell Us Your Mac Automation Stories by Adam Engst in TidBITS). But no one seems to know what those reasons were.

Sal was instrumental in the development of Automator. And more than anyone else, he worked hard to explain, promote, and encourage the adoption of automation technologies across the Apple ecosystem and apps. Without his efforts, I’d have far too little to say about Mac automation that could fill a book.

I’d be more sanguine about Sal’s departure, even though he’s a friend, if Apple had kept on a path towards improving automation. But as best as I can tell, there’s no one in charge of this area at Apple since he left.

Another recent change: in macOS 10.15 Catalina, Apple has deprecated the Unix scripting languages Perl, Python, and Ruby, all of which have been included with the operating system for eons. That’s a pity, because these are powerful and useful tools that numerous other automation utilities depend on for automating tasks. Although Apple hasn’t provided specific details, it sounds as though future versions of macOS will no longer install these languages by default.

I don’t have any inside knowledge of Apple’s corporate thought processes or business plans, but I can make some informed predictions:

• Most of Apple’s automation technologies—particularly the home-grown ones—will remain roughly the same in the next few releases of macOS, just as they did in High Sierra, Mojave, and Catalina. Although individual apps may drop support for certain automation technologies, I expect that most workflows you build today with, say, AppleScript or Automator will still be functioning a year or two.

• I would be shocked to see substantial improvements or revisions to Apple’s existing macOS automation technologies in the next few years. I expect to see bug fixes at best.

• Apple will likely continue to promote app extensions, cloud services, web-based tools, and—most importantly—apps written in the Swift programming language as the preferred ways to accomplish tasks that older automation technologies typically addressed (even though these methods might not quite be able to do the job yet).

• There will be an increase in attention to automation on iOS, which accounts for a far greater share of Apple’s income (and, thus, programming resources) than macOS these days. See the sidebar Shortcuts in iOS and iPadOS.

My gut feeling is that, in terms of official, system-level support from Apple, Mac automation has plateaued, and might be on the decline.

However…

Even as someone who loves automation, I don’t find this depressing. In fact, I feel quite positive about a broader picture of automation on the Mac—one that isn’t defined solely by Apple’s decisions. Here’s why:

• The Mac automation community is large, vibrant, and influential; witness 73 Mac Automation Stories from TidBITS Readers. Notably, some of the large groups that spend the most on Apple gear—such as graphic artists, musicians, and various sorts of enterprise users—depend crucially on automation technologies. I’m sure those people collectively hold some influence over Apple’s decisions.

• In many respects, Apple takes a “let’s leave well enough alone” approach to the guts of macOS. Notwithstanding the deprecation of Unix scripting languages mentioned above, there are oodles of other old Unix utilities still kicking around in macOS. They’re not doing any harm, and some problems might arise if they were removed, so they largely stay, even without a strong argument as to why they’re needed. The same could be true of today’s built-in automation technologies.

• If you depend on Perl, Python, or Ruby for automation tasks, you’ll always be able to manually download, install, and use these tools even after they’re no longer built into macOS. Indeed, since Apple’s versions of these tools have been behind the times for a number of years, installing fresher versions has already been quite common among developers.

• The number of apps with their own built-in automation tools is growing, as are the capabilities of those tools. (See, for example, the chapter Use Omni Automation.) Even if AppleScript disappeared tomorrow (don’t worry; it won’t), you’d still be able to automate tasks within Acrobat Pro DC, DEVONthink 3, Microsoft Office, Nisus Writer Pro, Photoshop, and many other apps. You’d also still be able to use tools like Keyboard Maestro that use their own methods to automate other apps.

• Even though app extensions, Swift, and so forth don’t meet the general need for automation tools today, they could plausibly evolve in such a way that they will in the future. Indeed, perhaps Apple or a third-party developer will invent some entirely new technology that will make today’s options seem quaint.

• Apple’s new Catalyst framework, which makes it simpler for iPad developers to develop native Mac versions of their apps that share most of the same source code, fully supports AppleScript. (Yeah, I have to admit even I was a little surprised to learn this!)

• Apple is paying a lot of attention to both automation and programming on iOS/iPadOS. The free Shortcuts app gained big new capabilities in iOS 13 and iPadOS 13; see the sidebar Shortcuts in iOS and iPadOS, ahead. Apple also (somewhat shockingly) approved Omni’s iOS/iPadOS apps that incorporate JavaScript—not just for automation within a single app, but between apps too. And the company offers Swift Playgrounds, a free app that lets people learn to code in Swift on an iPad (even though iOS/iPadOS devices can’t yet be used to develop full-blown iOS/iPadOS apps).

  Granted, that’s iOS/iPadOS, not macOS. But this shows that Apple does care about automation, and lately we’ve seen a number of technologies flow from iOS/iPadOS to macOS. Apple could very well be using iOS/iPadOS automation developments to lay the groundwork for future Mac capabilities. At the very least, it’s an argument for parity between the two platforms.

In short, although I don’t know what the future of Mac automation holds, I’m enthusiastically increasing my own use of various automation technologies, and I hope you’ll join me!