AppleScript: Graphic User Interface (GUI) Scripting | Hacker News Reader

AppleScript: Graphic User Interface (GUI) Scripting

macosxautomation.com

71 pointsbehnamoh30 comments

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:

    $ osalang -l
    ascr appl cgxervdh  AppleScript
    jscr appl cgxe-v-h  JavaScript
    scpt appl cgxervdh  Generic Scripting System

But, there are constants defined in Swift for a bunch of scripting languages: https://developer.apple.com/documentation/uniformtypeidentif...

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.

https://developers.google.com/apps-script/reference/url-fetc...

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.

I never knew that it works with JavaScript.

> AppleScript is a HORRIBLE language.

Agreed.

> But it never worked that well in reality.

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.

³ https://github.com/electron/electron/issues/4418

⁴ https://developer.apple.com/library/archive/releasenotes/Int...

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.

> and Apple's HIGs set fairly high expectations for the quality of this documentation.

Ah. And herein lies the problem with modern day Apple

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.

It's been said that Perl is a write-once, read-never language. Applescript is the opposite: read-many, write-never.

> 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.)

…

For those who wish to see what could have been:

https://appscript.sourceforge.io -- appscript (Python 3 works; the others are bitrotted)

https://hhas.bitbucket.io -- SwiftAutomation (probably still works)

https://www.npmjs.com/package/nodeautomation -- nodeautomation (works)

https://sourceforge.net/projects/appscript/files/ -- ASDictionary and ASTranslate tools for translating AS commands to their Python/JS/Swift equivalents

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.

As usual a lot of discussions about AppleScript are about the english-like syntax, adopted for inexperienced users, less than the - in theory - amazing object based App scripting.

Fun fact: Apple in 1991 in fact planned to have alternative dialects of AppleScript, meaning divorcing the logic of the script from its textual representation and storing the script in a language-independent representation.

One application would have been internationalization, instead of writing english-like writing in french-like or japanese-like and early 90s Apple seem to have released those dialects for a little time, although they depended on localization of the AppleScript dictionaries of the scriptable apps.

Also planned was a Professional Dialect, but sadly not released. According to William Cook, creator of AppleScript (the language/dialect) that would have look something like this:

English-like dialect:

  the first character of every word whose style is bold

French-like dialect:

  le premier caractère de tous les mots dont style est gras

Professional dialect:

  { words | style == bold }.character[1]

I would have really liked something like that. One wonders what would have been. William Cook himself believes in hindsight that AppleScript should have adopted the professional dialect.

AppleScript from Mac OS X onwards had adopted the Open Script Architecture with bridges which can be awkward because of some mismatches between features and syntax of the bridging language. Even Javascript (JXA), the most prominent, needs a somewhat awkward `whose` function to replicate the builtin filtering of AppleScript.

[1] Cook’s paper about AppleScript: https://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf

AppleScript’s dialects trick was clever, but many app developers didn’t have budget to localize their GUIs, never mind their scripting interfaces as well. Nowadays, with automated translation tools fast improving, localizable scripting languages should be, if not the norm, then at least the next-generation ground breakers.

Anyway, once OS X came along, a programmer dialect for AS would’ve been unnecessary as Mac OS X included the massively popular Perl, Python, Ruby languages as standard. Apple’s priority then should’ve been to put AppleScript-quality app scripting support[1] into those languages too, but as I noted upthread the Mac Automation team utterly wrecked that.

…

Here’s a working, testable example of your query:

    tell application "TextEdit"
      tell document 1
        get first character of every word whose font is "Helvetica-Bold"  
      end tell
    end tell

And here’s your filtering example, done right, in Node.js[2]:

    #!/usr/bin/env node

    const {app, its} = require('nodeautomation');

    const textedit = app('TextEdit');

    let doc = textedit.documents[0];

    let ref = doc.words.where(its.font.eq('Helvetica-Bold')).characters.first;

    console.log(ref.get());

    // => [ 'b', 'b', 'k' ]

…

Cook’s paper is a terrific read, btw: a true lightbulb moment. ’90s Apple management were ranking idiots for driving Cook and Harris off. Here a video of them discussing their work and its goals back in happier days:

https://www.youtube.com/watch?v=1MaHJ_mzrTU

Both authors tragically passed in recent years too, still young. It is a shame that their amazing if imperfect work is probably not far behind now. They deserved far better.

[1] https://appscript.sourceforge.io

[2] https://www.npmjs.com/package/nodeautomation

I love Office, yet one of the "features" I really hate is how Excel adapts its programming language to each locale.

As jitl mentioned, macOS can be scripted also with JS [1]. You can also create GUI in an imperative style. Or write a React reconciler and have something like React Native via JXA, without any ObjC bridge. Not that you should do it, but its possible.

https://developer.apple.com/library/archive/releasenotes/Int...

If you really want to script macOS apps using JavaScript, try nodeautomation:

https://www.npmjs.com/package/nodeautomation

JXA is buggy and crippled, with abysmal documentation and zero community or official support.

nodeautomation is provided without warranty or [unpaid] support, but at least it works right and I will keep maintaining it for as long as I use it myself (maybe 3-5 years, as it’s part of my AppleScript-to-UXP migration toolkit for Adobe CC scripters).

If you can run[1] the ASDictionary and ASTranslate support apps they answer 95% of “How do I…?” questions for you.

That all said, you really are best sticking to AppleScript. The language sucks and its community moribund, but at least there are people there who understand how to use it with the various “AppleScriptable” apps who can help you when you get stuck.

[1] Both apps are written in Python3 and py2app, and I haven’t bothered to codesign those releases (it’s a chore) so M1/M2 Macs will probably refuse to run them. (If anyone really cares, they can jump up and down on me to do so or, even better, codesign them for me so I can just post those builds.)

Hasn't Apple effectively deprecated all of the scripting interfaces? They fired the guy that was in charge of this stuff years ago, and the last updates to the JSX documentation are for El Capitan. Apps that didn't previously have scripting dictionaries no longer support them. I believe that the issue ultimately is that these scripting interfaces are a security issue since they allow malware to leverage a built-in general programmatic interface without having to load any additional tooling. I'm surprised that Apple hasn't disabled them already.

Well, “effectively” in “effectively deprecated” is doing a lot of work there. :) I think one could make a plausible argument that the old Open Scripting Architecture is on its way out, but given that they’ve brought Shortcuts to the Mac, it’s obvious that the idea of having “a built-in general programmatic interface” isn’t being deprecated. Shortcuts will probably replace both Automator and OSA in the long run, but it’s not going to get there for a few years.

Apple Script is a weird but cool feature. There's also another thing called "Remote Apple Events" which essentially lets you use Apple Script over the internet via some weird RPC system. It's super bizarre and I have yet to find a legitimate use for it but it works nonetheless.

Remote Apple Events were super useful back in the classic Mac days - it used it for instance to dial up or hang up the 56k modem on the Mac that was acting as our router. It also made it super easy to write networked games in HyperCard.

I guess it lives on since enough people have some vital QuarkXPress workflow they can't abandon...

Remote Apple Events are pretty fantastic. Back in 2002/2003, I wrote an AppleScript Studio application (with a little bit of Objective-C) that let you control iTunes on another machine.

It seemed like absolute magic at the time to me and my friends - from my PowerBook on the couch, we could change the song playing on the iMac on the other side of the room! Wish I still had that source code to look at.

If I'm not mistaken, that is still used in some parts of the pre-Home Sharing remote Library and remote playback functionality in iTunes (pre-Music.. man, that's a lot of prerequisites).

Remote events even worked across AppleTalk and TCP/IP, across macOS and Mac OS Classic, so you could make use of some of the features between computers on different networks, with 10+ years difference in software, and it would still 'magically' work.

After RAOP and mDNS etc. the event system was less used and most of the newer features are implemented as classic client-server applications. But it still exists, and still works. Apple Events are even advertised over Bonjour!

I must admit, I don't think I've ever seen centered code.

For those complaining about bizarre centered code formatting...

Seems like it's a bug where this one page isn't loading the CSS/formatting the rest of the site has.

The parent page:

https://macosxautomation.com/applescript/learn.html

shows the site's intended formatting.

AppleScript pops up every once in a while on HN and the general consensus seems to have been: It can be powerful and in some instances it works well, but the syntax is insane, the JavaScript isn't documented, the edge cases are numerous, security updates and popups can be frustrating, it never really works as expected and takes you way longer to make it work than it should. It's a neglected part of the OS and given Apple's focus on consumers not developers, it's likely a dead-end feature not worth your time to learn.

I use it for "launcher" apps that I can add to the Finder toolbar to do things like create a new text document or open the console in that directory [1]. I wrote that a decade ago, and little has changed since. You use it when you have to, but then once whatever itch is scratched, you'll avoid it like the plague.

1. https://www.russellbeattie.com/blog/fun-with-the-os-x-finder...

Are Electron apps going to bring an end to Apple script?

No. Cross-platform Siri [Shortcuts] plus App Extensions and App Intents will. That’s where Apple sees the future of end-user automation now: providing 1% of the power to 1000× (it hopes) more customers.

Will Apple’s new strategy actually work? Eh, maybe. It is not a great plan, but Apple has more than enough resources to brute-force it to “[Barely] Good Enough” status so at least its backers can declare great success.

And, to be fair, if Siri plus App Itents can enable even 10 million iOS users to tell their phones to perform trivial tasks for them, that will be a huge, genuine achievement on Apple’s part. While transitioning from AppleScript to Shortcuts takes away the Lego Techniks for anyone to build new functions (only professional Swift developers will have power to do that), the Duplo blocks it provides in return are easier to use.

…

That said, a more cunning plan could provide 100% of the capabilities to 1000× of the users, and probably more. ’Cos what AppleScript sits on is a huge trove of [mostly] standardized query handling applications, and Siri itself is a query builder.

Anyone suffering terminal insomnia and compulsive sado-masochism is welcome to read the alternative (independent, community-driven) plan I proposed in these 2 posts:

https://forum.latenightsw.com/t/petition-apple-for-applescri...

(Be warned: most of that thread is just me showing my ass to the world’s last entrenched handful of reactionary AppleScripters who do not want to imagine a future without AppleScript, because that future is not all about them any more, so they don’t. Ah well, I suck. My offer stands to anyone mad enough.)

Oh do Tell.. #roflmao

Seriously, this is not The Way. It was The Way, but hasn’t been for a long time (notice it was never included on iOS/iPadOS?)

Worst possible formatting for code examples. Did the author even look at the rendered page?

Yeah, that page’s .css import is broken (404). The page should look more like this:

http://www.macosxautomation.com/applescript/firsttutorial/02...

That site is Sal Soghoian’s, and my own opinion of the man’s work and his ability to accept criticism is well known. Still, if you can find a way to give him a heads-up his CSS is broken (and probably has been for a decade), crack on. I think even he’ll concede and hopefully thank you for drawing it to his attention.

…

The other thing I’ll say about that particular page is that GUI Scripting is absolutely the worst of the worst, the “Bad Automation” approach to be used only when an app doesn’t provide an “AppleScript” (Apple event IPC) interface of its own.

With GUI Scripting, your script is literally mimicking the interactions of a human user: pushing buttons, reading and typing text in text boxes. This is far from optimal when talking program-to-program.

The whole point of a GUI View layer is to present the data held in the app’s Model layer in a format that is easy for human users to visually read and write with keyboard and mouse.

Conversely, an “AppleScript” View layer presents the same Model data in a format that is easy for other programs to automate. The data is presented as a queryable tree of “objects” (an Apple Event Object Model), with a set of standard commands for manipulating those nodes.

Sal’s tutorial pages I linked to above describe the “Good Automation” which AppleScript is rightly known for.

It’s actually a pretty awesome API and the [few] developers who genuinely “get it” genuinely love it too. Way more REST-ful than what most webapps today call “REST APIs”[1], a powerful, elegant, and very high-level user-queryable abstraction (it’s closest to SQL, *not* OOP). You can find my own (now very old) attempt to explain its conceptual model to programmers at:

https://appscript.sourceforge.io/py-appscript/doc/appscript-...

Not a great explanation, but still way better than Apple’s. Someone else also linked Dr William Cook’s AppleScript paper up-thread, which is a must-read for understanding these principles.

…

Alas, for historical reasons Apple events and AEOM got shackled to AppleScript early on. And while AppleScript speaks Apple events flawlessly, as a general scripting language it is horrible obfuscated crap. But the app-to-app IPC that sits underneath is [when it works right] damned awesome.

[1] “REST API” is an oxymoron: REST describes how “REST-ful” apps’ *UI/UX* should universally behave at a high-level. How the interface should look and feel to its users, regardless of whether a given user is a machine or a human; not list low-level procedure calls and arguments. Like HTTP, Apple events suffered terminally weak, unhelpful, incomplete early documentation, and all the misconceptions and dysfunctional implementations subsequently arose from that.

Fielding’s thesis should’ve been the web’s equivalent to Apple’s Human Interface Guidelines, but was published a decade too late to have any influence, and lacking good and bad working examples of real-world design for non-academic readers to follow/avoid. Likewise, Apple didn’t publish its Scripting Interface Guidelines (https://developer.apple.com/library/archive/technotes/tn2002...) until over a decade after AppleScript’s release.

Reply on news.ycombinator.com