The news that Apple had laid off, who has been a fixture in the world of scripting and automation for decades, hit hard at MacTech Conference back in November. Although Sal hasn’t been making as many public appearances as he used to in the days of Macworld Expo,  inside and outside Apple have had wide-ranging impact. Sal worked tirelessly within Apple to encourage support for AppleScript and Automator (among much else), and to ensure that Apple apps provided the necessary scripting dictionaries and Automator actions. He was long a champion for the user, believing that users know best what they need to do and that automation technologies were essential for enabling users to create and streamline their own workflows.
What should we make of Sal leaving? Apple didn’t lay him off specifically, it instead eliminated the position of Product Manager of Automation Technologies. It’s my understanding that multiple groups within Apple wanted to hire Sal afterward, but Apple was under some sort of hiring freeze that prevented him from migrating within the company. So it doesn’t look as though Apple was trying to get rid of Sal personally, which is good. What’s less good is that it would appear that Apple doesn’t see the need for having a position that evangelizes user automation.
, Apple’s Senior Vice President of Software Engineering, to ask that Apple not kill AppleScript and Automator, and was told “We have every intent to continue our support for the great automation technologies in macOS!”
Federighi’s response prompts the question of whether Apple’s future actions will bear out his statement. It may be overreaching to read too much into his precise words, but “intent” is an aim or a plan, not a guarantee. And “support” can mean “maintenance mode” rather than “advancing the state of the art.” Regardless, eliminating Sal’s position isn’t a step in the right direction. Sure, Apple could have plans to replace AppleScript and Automator with super secret magic unicorn technologies, but based purely on what the company has done and said, it’s hard to believe that.
It wasn’t always like this. The reason AppleScript survived the purge of products and technologies after Steve Jobs returned was that Jobs understood the importance of automation to key Apple markets, like publishing, finance, and TV and film, not to mention the enterprise and IT worlds. These industries live and die by custom workflows based on AppleScript and other automation technologies built deep into macOS.
But the Apple of today is an entirely different company, focusing as it does on the iPhone and iOS. Even so, it’s obvious to anyone who uses iOS that there is still an important role for automation. I can tell Siri to “Change ‘Floating’ to 8 AM” to adjust the time of my wake-up alarm, but I have no way to automate the five taps necessary to play the audiobook we listen to every night in the Hoopla digital library app. Five wasted taps every night isn’t the end of the world, but if you can’t automate the little stuff, you certainly can’t automate the big stuff.
If Apple’s seeming indifference toward automation worries you because you rely on scripts, macros, workflows, and more to get your work done quickly, effectively, and accurately, here’s what I’d like you to do. Leave a comment on this article outlining how you depend on Mac automation tools in your job. If there are too many examples to fit in a single comment, just focus on those that are the most important to you. I’ll compile all the comments and publish them as a future article, and I’ll also send a copy to Craig Federighi and Apple CEO Tim Cook so they see concrete examples of why we need these automation technologies to continue to evolve.
To kick things off, here’s my most important bit of automation. When it comes time to publish a new or updated Take Control title, I start with three versions of the book: a PDF, an EPUB, and Mobipocket file. A copy of each must be stored in several locations on our internal file server and uploaded both to our Web server and to Amazon S3. Plus, the uploaded versions must be renamed precisely according to an algorithm that’s replicated on our server, so the site can update itself and serve the correct files based on the presence of properly named uploads in the right directories. When I used to do this by hand, it took 15–20 minutes, and I ran the risk of renaming a file incorrectly or uploading to the wrong directory. (And making a mistake meant that I had to spend even more time figuring out what I’d done wrong and fixing it.) Now that I have a series of Automator workflows performing these tasks for me, it takes me just seconds to initiate the uploads, and there are never any errors.
So that’s my automation story — tell us yours!