AppleScript is an amazing facility and undervalued strength of macOS. I've found it useful for automating content management workflows for people that prefer a GUI over a shell script. You can also use it directly from a shell script via `osascript -e "XXXX"` to show pop-up windows or take simple inputs.
It's really a pity that AppleScript / Open Script Architecture doesn't have more documentation love, and that support in the macOS ecosystem for scripting is falling off as developers adopt web-focused or iOS-focused app architectures.
AppleScript itself is a weird, slow language, but you can use JavaScript (executed by JavaScriptCore) instead with the same scripting libraries. In fact, there's a whole architecture to extend the macOS scripting system with different interpreters. On my system, the following are available:
More amazing and undervalued is Google Apps Script which allows for attaching JavaScript to Google Docs (most useful with Sheets). Including a "fetch(url)" function for calling APIs.
AppleScript is a HORRIBLE language. It still gives me nightmares, as I needed to do something non-trivial there. In... I think Tiger days? Brrr.
I liked the idea that all apps will be easily scriptable - lots of apps back then even exported some AppleScript actions. But it never worked that well in reality.
And nowadays, with all big and important apps being Electron, it doesn't really matter anyway.
Disagreed. As bad as the AppleScript syntax is, it’s the only way to automate certain things in macOS and it generally does it competently. Plus it has an Objective-C bridge, allowing you to run lower-level commands from a scripting language.¹
> with all big and important apps being Electron
Chromium itself (and all major browsers derived from it) has a fantastic AppleScript dictionary which is even better than Safari’s.² Firefox is the single major browser without AppleScript support. Plenty of apps still include an AppleScript dictionary and Electron has an open issue for it.³
> I never knew that it works with JavaScript.
It was added in Yosemite.⁴ It’s not perfect and has some bugs compared to AppleScript, but it also makes other things significantly easier or possible, such as dealing with JSON.
¹ Technically one can use Swift as a scripting language too, but it requires installing the Developer Tools.
² Quick example: one can’t open a new private Safari window via AppleScript, except by scripting the GUI.
AppleScript's syntax was a mess of pseudo-english that was a pain to write (although considerably easier for newbies to read). The editor helped here quite a bit.
That said, the infrastructure backing Applescript was amazing (especially for the time). The MacOS scripting interface was just as powerful as /proc, but far more structured. Every application and system service defined its own object-relational schema, and Applescript provided a SQL/Sparql-like language for querying that schema ("set foo to all of the Documents"). The schema and associated documentation were self-contained within the applications themselves via the resource fork, and Apple's HIGs set fairly high expectations for the quality of this documentation.
And of course, as the GP notes, other languages could tie into the scripting framework (I have fond memories of using both Frontier and Hyperscript in this way).
“Every application and system service defined its own object-relational schema”
On the minus side, every application and system service had to implement its own object-relational schema, and there was little support for doing that.
In theory, you could tell any text editor or text processor such things as
“tell every sentence whose third word is "foo" to set last word to first character”
and that entire code fragment would then run in the process of the editor, but in practice nobody implemented the support for such complex commands.
That every application basically chose its own subset of the language is part of the reason AppleScript is so hard to write.
> On the minus side, every application and system service had to implement its own object-relational schema, and there was little support for doing that.
This was true in classic Mac OS. ObjectSupportLib provided some building blocks but there was no OS framework for implementing a “scripting” (Apple event IPC) View layer, comparable to what the OS provided for building a GUI View.
Mac OS X 10.2 finally introduced the Cocoa Scripting framework—which wasn’t… great: Object-Relational mappers are Hard to do right when manipulating ordered Arrays (which OO-based apps love to use) instead of unordered Sets (as in traditional RDBMSes)—but was just about Good Enough.
Alas, while CS made it a lot easier for Cocoa app developers to add “AppleScript” support to their apps, the fact the whole platform was shackled to the AppleScript language by default killed its ability to grow market. 10 million geeks on Mac OS X, and maybe only 50 thousand who could stand to touch AppleScript at all.
But, as I noted up thread, when Apple tried to create geek-friendly alternatives to AppleScript, Scripting Bridge and JXA (which should have been pure catnip to y’all because Apple event IPC itself is awesome) they screwed the pooch so badly they didn’t only ruin those products but wrecked all the third-party alternatives as well.
…
> In theory, you could tell any text editor or text processor such things as
>
> “tell every sentence whose third word is "foo" to set last word to first character”
>
> and that entire code fragment would then run in the process of the editor, but in practice nobody implemented the support for such complex commands.
Yup, queries are awesome. And there were in fact some apps that implemented robust query support at this level very, very well—e.g. Tex-Edit Plus, Adobe Illustrator—but those tended to be apps written pre-OS X by developers who worked very hard to nail it. (Adobe Illustrator’s scripting support was written by Mark Alldritt, better known for his [Script Debugger](https://latenightsw.com/) editor.)
In fact, you can run a query much like the above (replacing `sentence` with `paragraph`) in Apple’s own TextEdit, which uses Cocoa Scripting’s Text Suite to implement its text object model. The query itself works, but the `set` command silently fails. Commands like `move` and `duplicate` are even less reliable, often disappearing text entirely!
The CocoaScripting framework needed a really good mathematician to engineer it, but got a random NeXT dev instead; and with AppleScript’s original creators long gone from Apple they just bodged it as best they could.
…
> That every application basically chose its own subset of the language is part of the reason AppleScript is so hard to write.
Nope. No harder than using third-party Python libraries in a Python script is. Each library has its own API, with commands and objects specific to its particular task. The real problem was twofold:
1. Each app’s own API documentation was almost always massively inadequate. There was no way for a human user to tell which object queries could be used in which commands, except by actually trying it and seeing if it worked. Horribly opaque and unpredictable. I doubt most app devs even realized how inadequate their docs were, because most devs didn’t use AppleScript themselves.
2. AppleScript then compounded the confusion by layering the IPC stuff in mountains of syntactic sugar, enough to rot the teeth out a sperm whale, ostensibly to make AppleScript “simpler” but instead just making it impenetrable. The road to Hell is paved with good intentions… and AppleScript’s with the arbitrary injection of keywords. Pedagogical nightmare.
…
There is a postcript to all this, which is that Apple really are fools to throw away all these decades of work despite its flaws. Because they have Siri now, which is a query builder, and that, combined with what is probably the most powerful and flexible general-purpose user-level query handling architecture ever built outside of google-dot-com, ought to be THE killer USP across all of their platforms ny now.
Alas, best tech in t’world can’t fix Stupid. PEBKAC.
People who think AppleScript is horrible probably aren't familiar with HyperCard, whose scripting language had a similar syntax. But when AppleScript was introduced in the 1990s, it was a reasonable assumption that most people wanting to use it were HyperCard users. Personally, I think languages that actually try something new are more interesting than yet another C/Java clone with only minor syntax differences.
> AppleScript is an amazing facility and undervalued strength of macOS.
True and false. Apple event IPC is pure awesome. The AppleScript language is a dumpster fire. AppleScript remains because Apple’s own alternatives, JavaScript for Automation (aka JXA, which you mention) and Scripting Bridge framework, are even worse.
Sadly, the whole AE/OSA/AS platform is the walking dead now. Following two decades of ignorance and mismanagement, and in the wake of JXA’s 2014 failure, Apple finally fired the PM responsible and disbanded the Mac Automation department back in 2016. Whether they actively pull its plug or just let it fade away in its own time, Mac Automation as we know it is, as far as Apple’s concerned, a failed product for a non-existent market. iOS is the only market of significance to Apple now. This sucks, but so it goes.
Apple is now moving to App Extensions and App Intents for user-level IPC, which has maybe 1% the power of AEs but is cross-platform and far easier for App developers to implement; and for front-end they have cross-platform Siri with Shortcuts providing just enough customizability to make it useful (Apple hopes) to the other 99% of users for whom Swift, AppleScript, and all those other text programming languages are “too hard” for non-programmers to use.
(They’re wrong in this: text is easy; it’s languages designed by and for programmers that are hard by design, Shortcuts—ironically—included. A modern version of Papert’s Logo would smash the problem. But Apple’s own thinking is not exactly… advanced.)
All 100% capable alternatives to AppleScript for app automation, and the programmers who used them loved them. But given how thoroughly Apple wrecked the whole platform I killed support after 2012.
Now even stalwarts like Python and Ruby are gone from macOS, and the enormous JavaScript market is 100% owned by V8’s Node.js, which says what Apple priorities are regarding scripting and scripters now. Not that I can blame Apple, but Mac Automation’s failure was always a people problem, not a tech problem, not that they know (or care) the difference.
It's really a pity that AppleScript / Open Script Architecture doesn't have more documentation love, and that support in the macOS ecosystem for scripting is falling off as developers adopt web-focused or iOS-focused app architectures.
AppleScript itself is a weird, slow language, but you can use JavaScript (executed by JavaScriptCore) instead with the same scripting libraries. In fact, there's a whole architecture to extend the macOS scripting system with different interpreters. On my system, the following are available:
But, there are constants defined in Swift for a bunch of scripting languages: https://developer.apple.com/documentation/uniformtypeidentif...