I’m increasingly feeling like Apple isn’t likely to dump significant new resources into Applescript… that sooner or later it’s just going to be deprecated and go the way of Hypercard.
Which is scary, since the company I work for relies on dozens of scripts running into 10’s of thousands of lines to automate a workflow tying together Photoshop and Illustrator with file manipulation, automation of other Applications including UI scripting, Swift code, Python code, Javascript code, terminal commands, and API interactions to an ERP system.
Personally, I’d love Apple to devote resources to patching up Applescript - standard dictionary, maybe extend ASObjC to ASSwift, finish the “professional syntax” localization project, add thorough Applescript dictionaries for all Apple products that don’t have them, etc.
But that’s not likely to happen, is it?
What could they do, other than abandon automation users?
I was thinking a more forward-looking approach would be to:
-
Do the reverse of the ASObjC project - make a bridge so Swift can swap data back and forth with and run lines of Applescript code directly, interspersed with Swift code, so programmers can still control programs with AS dictionaries.
-
Apple is all into “learn to code” now, but XCode has a nasty learning curve and too much functionality for weekend coders or 5th graders learning to code. So implement a “training wheels” mode inside XCode that makes XCode behave more like Hypercard or Applescript+Facespan, ideally with something like the iOS app Workflow’s functionality and Automator integrated too. For easy UI’s and “hyperlink” style apps, or anything you can build by dragging-and-dropping canned widgets. You should be able to create something that runs using pure GUI interaction really quickly and easily. But then Swift is under everything you build in the GUI, and you can go add to it or modify it by writing code, just like hypercard/hypertalk. Or you can switch to the full XCode UI when you need to and go crazy with it, building on what you started in “training wheels” mode. (you just probably wouldn’t be able to take things that had been worked on in full-on Xcode back into Training Wheels mode. But maybe even that too is possible.)
-
Rebuild how AS Dictionary creation works to make application dictionaries much easier to build - make as much as possible be generated “for free” by Xcode in the normal course of writing an application. And have the new revamped dictionaries aimed at Swift interaction from the beginning. So over time, more programs end up scriptable. The “SwiftAS” implementation is just for backwards compatibility to grandfather out Applescript and old dictionaries.
Would that put Apple onto a future-friendly and modern path to automation?
What do you think? Is there a better path?
Hoping not to start some holy war here with old opinions about the way of the future, just wondering what other people think is the best path. Pretending you don’t have extensive investment in Applescript and you could act as Tim Cook and need to plot a path for the future of MacOS automation, what would you do?
