The writing has been on the wall with AppleScript for awhile now. No significant updates for years. The entire team at Apple assigned to different projects. It is only a matter of time before Apple drops it entirely. I was curious what the future of scripting with DEVONthink will look like…
There is no indication that AppleScript is going anywhere. As Twain said, “The reports of my death are greatly exaggerated,”
AppleScript is too deeply entrenched in too many lives and processes. Unless Apple ever came up with a viable solution that was superior, was able to fully convert legacy scripting, and be backwards compatible with existing scripts, it would be the biggest mistake of Apple’s history to just deprecate it.
2 Likes
Interesting double-entendre 
Nor is JXA “going anywhere”, as it’s at the same stand still as AS.
Didn’t we think that about parallel and serial interfaces, FireWire and whatnot? Apple never shied away from cutting hardware ties, and they’ve already deprecated other scripting languages.
I doubt that they are above making big mistakes. At least, they don’t do anything to evolve automation in general or scripting in particular. They simply aren’t interested at all in that topic anymore.
There’s shortcuts but doesn’t that include scripting?
Shortcuts – originally called Workflow – was created for mobile automation. Apple purchased it and later brought it the Mac, intended to replace Automator. However, Automator is still around, as is AppleScript and JavaScript for Automation. And yes, Shortcuts has an action to execute AppleScript on a Mac.
It does not include scripting on iOS. Nor does it on macOS, since it relies on AppleScript/JavaScript. And shortcuts are … no, I don’t find a nice word to describe that. Let’s just say that Apple tends to start something that looks promising (AppleScript, JXA, Automator, Shortcuts), and then they lose interest. Abandoned ships, floating on an ocean of possibilities.
1 Like
A point of comparison would be the route taken by Omni ( an embedded JSContext, independent of the osascript interfaces ).
It makes code faster to execute, because the JSContext is part of the application itself (OmniGraffle, OmniOutliner, OmniFocus) and there’s no inter-application traffic, but much more importantly, it’s also cross-platform – allowing code written for the macOS versions of these apps to also work on any iOS or iPadOS versions of them.
Needless to say iOS/iPadOS is (for better or for worse) a much bigger market for Apple now than macOS, and the JavaScript interpreter used by JSContext objects is Safari’s, which remains in active development.
(Apple’s JXA – JavaScript for Automation, of course, also continues to benefit, on major macOS version releases, from improvements in the Safari JS interpreter. On Sonoma for example, you can use Array.findLastIndex in a JXA script, whereas on Big Sur, you only had Array.findIndex).
(Another example of the embedded JSContext approach is Hogbay Software’s TaskPaper. Hogbay’s Bike, for which I understand that an iOS version is also planned, also seems to have the addition of a scripting JSContext on its development map.
There’s also Drafts, going the same way. Personally, I, of course, prefer JavaScript to AppleScript (and enjoy the added benefit of cross-OS portability). But this approach is, afaik, outside the traditional AppleEvent ecosystem. I have no idea how difficult it is for developers to implement a JS API compared to one based on AppleEvents. It certainly requires more documentation efforts (and permits to provide better documentation, otoh, than what Apple’s scripting environment allows).
But the benefits of using JSContext are obvious: State-of-the-art JavaScript, better OO semantics and available cross-OS. DTTG would be scriptable … well, I don’t hold my breath.
1 Like
For me, one crucial aspect of the traditional AppleEvent ecosystem used by AppleScript/JXA is its inter-application scripting possibilities. Scripting a single app can be very useful, but (for me personally at least) the real power of AppleEvent-based scripting lies in the possibility to combine various apps with your scripts.
Per-app scripting efforts like JSContext are welcome for better language features and the cross-platform scripting possibilities. But if these apps as a result loose support for AppleEvent-based scripting, I see this as a loss for unified inter-application scripting on the Mac.
3 Likes
Though we are probably far into off-topic land now: I was wondering if one could send Apple events from JXA, using the ObjC bridge. If that were possible, it could be used together with JSContext to offer per-app scripting.
Until now, I am getting nowhere with this:
ObjC.import('CoreFoundation');
ObjC.import('CoreServices');
(() => {
const targetAD = $.NSAppleEventDescriptor.descriptorWithBundleIdentifier($('com.apple.SystemEvents'));
console.log('targetAD ',targetAD.aeDesc.descriptorType)
const status = $.AEDeterminePermissionToAutomateTarget(targetAD.aeDesc, '****','****', true);
})()
getting a “Ref has incompatible type” back from osascript. The code is adapted from this thread in Apple’s developer forum.
Also, targetAD.aeDesc.descriptorType is supposedly undefined. I someone has any ideas on that, I’d appreciate a PM.
If Apple ever drops AppleScript & JXA, I wouldn’t hold my breath that AppleEvents will survive. But I don’t expect this to happen as it would break too many things.
1 Like
I recently read that AppleEvents are used under the hood for a lot of the inter-app communication in macOS (drag&drop to/from the Finder, for one thing). It that’s true, they’ll certainly stick with it for a long time.
…and then there’s no real reason to get rid of AppleScript & JXA, IMHO, as they’re based on AppleEvents 
Right. Instead, they just let them compost silently. There was a petition for AS 3 over at Late Night Software last year, which got 72 up-votes. I guess if someone were to do the same for JXA 1.0, the overwhelming response would be “Huh?”.
The communities are small (and, I think, not exactly growing). Probably no incentive for Apple to do anything about their scripting support.
Well, there might not be a lot of Mac users scripting on their own but probably many of them, maybe even most of them use AppleScript/JXA in some way (usually even without knowing).
Exactly. That doesn’t create traction to amend anything since it seems to be “good enough”.
Replying to myself: The call to AEDeterminePermission… fails because JXA doesn’t pass a correctly typed first parameter but a dictionary. I don’t see a way to fix that.
At least DEVONthink’s script suite will be extended as long as there will be AppleScript/JXA 
An upcoming release will especially improve the JXA support and fix all the reported issues.
5 Likes
The best indication on the future of AppleScript is that Apple has no team working on expanding or improving it. There used to be WWDC sessions concerning AppleScript, but none for years now.
At best, there are a couple of people merely maintaining it.
I agree, Apple will not formally announce it has been deprecated until they have a viable replacement.
What do I think will become their replacement?
It will be based on Swift. Swift Playgrounds provides a basis for a scripting environment. The support Swift has for DSLs will allow Apple to abstract out what makes swift difficult.
When will AppleScript go away completely? Who knows.