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.

#24

Thanks for the updates.

I’m afraid that maintaining something like SwiftAutomation is beyond my capabilities, but I do plan on playing around with it to see how far it can go in Swift 6. In a perfect world, there would be enough commercial interest in using Swift for scripting to justify ongoing development & support.

Regardless – thank you for getting back to me, @hhas01. Appreciate it!

#25

Hi all,
I’ve lurked here for many years, but just made an account to comment on this news.
This may be a slightly off-topic. Sorry, if not allowed here. But given the state support for AppleScript from Apple, I hope it might help anyone looking for an ‘escape hatch’.

Some background…
I was once a huge Apple fanboy, since 17yrs old discovering 1987 HyperCard. I used it right up until Leopard killed off the Classic environment. I used HC often as a GUI front-end for AppleScript, a good 6+ years after Apple last updated it (1998), then stopped selling it (2004).

AppleScript never had a real built-in UI toolkit, there was only 3rd party ( like FaceSpan ), but HyperCard natively supported the Mac-Toolbox UI. HC had Extensibility (like AS Additions) through XCMD resources as well, so it was a good fit for me (until it wasn’t), Since AppleScript was sort of HyperTalk’s cousin, it seemed like the perfect pair to me.

I used the hell out of this combo in 1990s working in desktop publishing, early web-development (WebStar server) and PrePress / Printing industry automated workflows. It saved countless hours of work. We were even early adopters of scripting image processing with PhotoShop, v2.5+ (early plug-in called PhotoScript iirc).

When it was clear HC finally would be gone for good, I dabbled with ASObjC and Interface Builder, and at one point bought a copy of SuperCard (never got off of it’s ‘Carbon’ dependence), but it wan’t until discovering a descendant of a 1990s HyperCard-clone MetaCard, then called LiveCode (2013), which at the time had just did a kick-starter campaign and went open-source, that really got me back into rapid-script-app development.

Like HyperCard, The LC community ‘xTalk’ engine has built in support for calling any OSA scripting language; AppleScript (and the underlying raw AppleEvents) and JavaScript For Automation as alternativeScripting Languages, as well as ability to run shell scripts and open background processes for writing to / polling from. Like HyperCard it’s extensible with Externals (like XCMDs) as well as an ‘Extensions’ with it’s own xTalk dialect allowing for explicitly typed variables , foreign function interface (use Cocoa APIs), canvas rendering (libSkia) that compile to intimidate BytCole modules (similar to Java or wasm).

Not only is it a HyperCard clone, but it’s also cross-platform and has similar extensibility on Win, Linux, HTML5 (Emscripten port) and iOS & Android mobile.

I was really getting into working on adding to LC Community until, after 8 years of open-source development, LC Ltd. suddenly dropped all support for the open-source community edition, Sept. 1st 2021. Which left behind a last-version with no ARM64 build and a menuBar bug that made it crash on Sonoma.

Since then myself and another guy (Tom), have worked at keeping some sort of ‘xTalk scripting’ (the common term for clones of HyperTalk language) alive, and we’ve maintained and improved fork(s) of the FOSS community edition(s) called OpenXTalk. It’s been a struggle since it’s a huge project, some dependencies were missing or ancient (like using GTK+2 on Linux, now at v4), it’s all not well documented, the Engine(s) source is in C++, but we’ve still made progress anyway. Many of the problems with its IDE were fixed or worked-around with scripting (without recompiling of the app engines). We’re now at the point where Tom managed update the source enough to get it to recompile on all three IDE desktop platforms, and there’s an Apple Silicon build that’s working on Tahoe!

So I’d like to invite scripters, fans of defunct ‘xTalk/xCard’ HyperCard, SuperCard, Oracle Media Objects, Macromedia Lingo, AppleScriptObjC (eventually?), etc. scripters who are all now ‘homeless’, or people looking for a scripting language similar to AppleScript (HyperTalk was like its older cousin), that’s NOT chained to macOS, to please consider coming over to join the effort to keep an English-like scripting (with Live UI editing), language a reality.
openxtalk .org

Cheers.

#26

Hi Paul: I recommend you start a new topic for your post so it’s more visible and its title is obvious. (Might be best if you message Mark first just to confirm it’s okay, though I imagine it will be.)

For those wondering about LiveCode Ltd’s decision to stop maintaining the open source version, their announcement’s here:

https://livecode.org/

Credit to LC for allowing OSS community to adopt and run with it, and to Paul and Tom for rolling up sleeves and doing so.

#27

THE FINAL COUNTDOWN - FOR ME IT IS JANUARY 2027 WHEN APPLE EXPIRE THE DEVELOPMENT CERTIFICATE WE NEED FOR SCRIPT DEBUGGER 8. Does any one else plan on getting any scripted apps completed in Script Debugger and Noterized this year. I am seriously working on 3 apps for release in both Script Debugger 8 AND Xcode 13 BEFORE JANUARY 2027. I have a plan and would like to collaborate. It involves modifying Dialog Toolkit Pro 1.1.3 to position Alerts over the Script Window and simulate Big Sur “sheets”. This will aid APPLE NOTERIZATION. This change should NOT alter the Toolkit’s Dictionary. It may require a single function to widen the script Window to match the minimum Control width of the Alert Dialog. Otherwise, it is simply changing the default Alert window position and final width. Would anyone be interested in collaborating with this. I have emailed LNS for permission but may not receive a response given the status of the apps. I am not even sure if the Dialog Toolkit is “retired” like Script Debugger 8.

#28

What about swiftdialog?

#29

Would you care to elaborate what this means specifically to a dummie like me?
Who is “we”? Developers having to ship signed AS applications? Or who else, if applicable?
Will SD stop working, say, on Intel machines using Sonoma or Sequoia?
If so, can this be prevented by disabling SIP?
Thanks for just any info to gain a clear picture of what will happen!

1 Like
#30

Some intrepid soul just needs to get to writing a new AppleScript editor in Swift. Throw Claude at it. It’s my understanding that you can just point it at your project, tell it to match Script Debugger’s capabilities, go eat dinner with your uncle Bob, and come home to a new Script Editor.