The Final Countdown

AppleScript
#21

#1 For those who could stomach “dot-languages”, Python, Ruby, Node.js, and Swift were all highly competent replacements for a while, as long as you knew to avoid Apple’s own crapware and use appscript and its descendants instead:

https://appscript.sourceforge.io/

hhas · GitHub

rb-appscript and nodeautomation bridges are long broken, but the original Python appscript still functions and receives precompiled builds for new Python versions thanks to Felix Zumstein. The accompanying ASDictionary and ASTranslate apps are also still working since I rebuilt them as 64-bit and greatly simplify translating working AppleScript commands to Python equivalents:

appscript - Browse Files at SourceForge.net

SwiftAutomation appears to still work too, once I updated the minimum OS version in the Xcode projects, albeit with a bunch of deprecation warnings. While I’m no fan of Lattner’s language (“rubberized C++”), looking at SwiftAutomation afresh I’m impressed by just how usable it was. Had Sal taken it when I offered, he could’ve saved both his own job and Mac Automation after his JXA debacle—SwiftAutomation would’ve won a LOT of new Mac Automation users. Oh well.

#2 Back in 2019 I prototyped an “AppleScript successor” named Iris for my own entertainment, seeking to marry the simplicity and consistency of Seymour Papert’s Logo language with the power of Mac Automation:

tell app “com.apple.TextEdit” to do
make new: #document at: end of documents with_properties: {name: “Test”, text: “Hello again!”}
get text of every document
done

➞ [“Hello again!”]

Totally extensible and richly introspectable, it was designed from the beginning to interface with generative AI too, tackling one of the biggest challenges frustrating non-programmers and other new users: how to turn what they know they want doing and can describe in conversational text into its formal human- and machine-readable equivalent.

I wasn’t entirely happy with the experiment’s result: while Iris’s syntax and semantics are much simpler and easy to explain (“everything is a command”) than AppleScript’s unpredictable magic, it was still more complex than Logo and especially needed a smart code editor to assist the user with the additional punctuation. (Punctuation’s always a pain for users to type right. The included REPL supports rudimentary code highlighting, history, and multi-line entry, but not much else.) And tradeoffs inherent to operator syntax—easier readability at cost of adding more language rules which must be learned by users—drove me up the wall.

Still, anyone with a curiosity in how to design a next-gen scripting language that could appeal to both non-programmers and professional coders should take a rummage. Iris really condensed everything I learned over 20 years as end-user learner, amateur scripter, professional automator, documentation author, and language developer; and there’s ideas and solutions in it I’m fairly sure still haven’t been done by anyone else.

Obviously none of this stuff is supported by me any more; but it’s there for taking if anyone wants to play around with it. A glimpse of what could’ve so easily been, had Apple’s Mac Automation department been run by someone like Cal or Mark who knew what they were doing.

#3 A few years ago I also started developing an AppleScript-to-JavaScript transpiler to assist with migrating a mass of legacy Photoshop and Illustrator AppleScripts to UXP. The job I was creating it for didn’t pan out so I stopped pretty early, but if anyone really wants that code I might be persuaded in DM.

p.s. Anyone curious what I’m up to nowadays is welcome to find me on LinkedIn.

#22

Thanks for providing an update about your projects! I’ve been watching Python-AppScript with great interest since 2012 & really wish I’d built most of my personal automations around that instead of AppleScript. I was unfortunately scared off by the deprecation warning.

Do you mind shedding some light on the future (if any) for SwiftAutomation? I’d really like to start using it for personal projects in order transition away from AppleScript, but Swift has made so many changes on the way to Swift 6 that a lot of older code is broken.

I think Apple has hugely missed the mark by not providing much in the way of proper scripting support in Swift… there’s still so much friction. Even trying to use AppleScript from Swift is harder than it should be. I’ve tried using Swift for small command-line executables (to work around missing functionality in AppleScript-ObjC), but it still ends up being easier to just use Objective-C.

I’d really like to use Swift to get first-class access to Cocoa & use SwiftAutomation for all of the application scripting, but I’ve been hesitant to make any big time investments if there’s no future for it.

Regardless, thank you very much for releasing so many capable tools over the years. I really wish that Apple had taken the approach you outlined instead of letting automation wither on the vine.

#23

It wasn’t a deprecation; rather a polite warning that you were utterly on your own:

  1. It’s working today but there’s zero guarantee it’ll continue working tomorrow.
  2. If it does break, there’s zero guarantee it will/can be fixed…
  3. There is zero support when you get stuck on how to use it.

“Stick to AppleScript” was the best recommendation back in 2012. Now both are equally unsupported, if you’re mad enough to trust AppleScript with all your work, it’s not that much more insane to trust appscript fo AE stuff. I’d say use the best language for the job, and the Python lang is both supported and far better than AS for all the non-AE code.

Caveat emptor, E&OE, YMMV, etc.

Python appscript would have died off years ago, except:

  1. Felix took over maintenance released and creates new binary packages when Python is updated. His Excel automation software uses appscript, so obviously he had an interest in keeping it working.
  2. My kiwi v2 Illustrator automation engine was written in Python and uses appscript too, so I needed Felix to keep it working too. :slight_smile:

Do you mind shedding some light on the future (if any) for SwiftAutomation? I’d really like to start using it for personal projects in order transition away from AppleScript, but Swift has made so many changes on the way to Swift 6 that a lot of older code is broken.

I have no future plans for SwiftAutomation. Last time I used Swift was several years ago when I wrote my experimental iris language and needed to add some useful real-world commands to play around with, so I hooked it up to Apple events as that was quick for me (I am not very original). You are welcome to help yourself to what you find on my GitHub, and if you make something interesting or cool out of them, Go You!

If you use SwiftAutomation (or iris, appscript, etc), you will really have to figure it out on your own. As with Felix, if you want any sort of guarantee it will keep running, you have roll up your own sleeves and take on maintenance yourself. I am not beyond the siren call of a fine bottle of scotch for clarifying some AE arcana but I must prioritise my current work—roof over head, etc.

Being slightly circumspect, all my work now must be multi-platform, so Apple langs are out. I still use Python for some little scripts, but my primary work for the next several years locks me into JS and C. (Maybe some C++ if our universe really hates me.) If I get those right, I can add kiwi as well.