Well, given the disruptions to Apple’s supply chain (by decoupling, especially following tightened regulation of access to US microprocessor technologies), they may be scrambling with more basic priorities for quite a while now …
See, for example: Apple Finally Falls Victim to Never-Ending Supply Chain Crisis - Bloomberg
AppleScript is a distinctive and defining feature of Macs and macOS.
I have written literally hundreds of AppleScripts.
Some are one-use knockoffs, like renaming files in specific, complex ways.
Some expand the functionality of my Macs, like a global tags management system that ensures I have a single, central repository of tags that can be selected from and pasted into any text field, in any application; and plays a large role in my webpage clipper that deletes extraneous garbage from webpages; and in creating a PDF of the cleaned content.
Other scripts simply fix broken things in macOS that Apple seemingly can’t be bothered with, like new Finder windows always opening too small, despite having set individual folder, and global, defaults.
I use these scripts every day, many times a day.
Whenever I come up against a problem that isn’t natively solvable, or an opportunity to automate some process that I do frequently, that has no solution either in the app in question or in the OS, I turn to AppleScript, augmented with shell scripts (called via “do shell script”) and keyboard automation utilities, as needed. These, in conjunction with the apps on my Mac (if not natively scriptable, driven through GUI automation) comprise the automation ecosystem on my Macs.
AppleScript is part of what makes macOS customizable, efficient, and actually usable. There is no parallel that I can see in any other platform.
Many macOS apps contain embedded AppleScripts in their bundles.
None of Automator, JavaScript, and Shortcuts can replace AppleScript.
Apple: deprecating, crippling, or letting AppleScript die of neglect would be simply unforgivable, to me, and to many hundreds of thousands (millions?) of your Mac customers.
AppleScript deserves to be maintained, and expanded.
AppleScript is an essential part of Macs and macOS.
Sure, but don’t hold your breath.
( The kind of worthiness on which decisions turn is slightly different )
I’m not sure I could answer the question if Apple asked me, what I like they include in AppleScript. I know how to talk to Python and JavaScript from AppleScript so its not a big deal anymore for me what Apple do or not do.
Of course I will be happy if Apple had more care or a vision what scripting language is.
Well, they probably do, but they’re mainly an iOS company now, so we have to look at what they are doing there.
( macOS can still thrive as a satellite of those systems )
For me Apple is a main hardware company who build software, service to improve people’s lifes. The last part is what they always say: improve people’s life. I still think a iPhone is very bad experience to surf the web but still many do. Apple is also a company who like to own every technology they make and see what happen to HomeKit… was that a success? or why did it take many years for Apple to realize it needs a new API (it calls Matter). Alliance between Google, Apple, Samsung and other companies to build Home Automation.
Scripting language is macOS feature not iOS and sometimes ideas from one platform do not work in other. (Shortcuts)
Scripting language is macOS feature not iOS
Apple’s JSContexts are embedded for scripting in a number of iOS applications.
All the Omni Apps, Drafts, Scriptable, 1Writer etc
Have you done anything cool to share ??
I believe iOS apps are isolated from each other. It means app A couldn’t manipulate app B’s data. So I guess it would be limited in that regard or other technology need to drive it.
Well, it depends a bit what kind of thing would be useful to you – there are, for example, a number of JSContext plugins which work both on the macOS and iOS versions of Omni apps.
@unlocked2412 contributes interesting things of that kind on the Omni forum, and Omni Automation is some kind of an introduction to the basics.
Automators Talk might be a more obvious forum for looking at what is going on in the use of JSContexts generally.
(The tighter security requirements of mobile devices make custom url schemes the main mechanism for inter-application processes on iOS)
@ComplexPoint Thanks, I will check it out.
The last month I have been using XMLRPC call to both Python and JavaScript. And my knowledge in industrial automation and embedded devices brings me to Node-Red (JavaScript event-driven communication). I’m also interesting in protocols and reason is there are so many ways to communicate to perform action specific target.
When you read about IPC vs RPC
IPC is a set of method to communicate with two process which may be in same computer or different computer.it includes direct & indirect communication,synchronous & asynchronous communication and explicit buffering. But RPC is a method to call a procedure from sever to client and get back its result as message.
It makes me to think IPC is less limited, and RPC that use client/server approach. Little bit like Modbus Protocol in Industrial communication. Client talk to the server set/get address. In this type of environment it could only be 1 server but multiple clients. IPC is not limited to this any data could be sent to return from any target in the process.
So far, everyone has contributed valuable input to this thread (including those not in favor as it’s important to see both angles and have your own ideas challenged to verify if your original premise is valid while seeing where there’s room for improvement). As I’m sure we’re all aware by now, the introduction of ChatGPT has created a new paradigm shift in technology. In my humble view (and I may be wrong), we are at the tipping point of a revolutionary and historic change that will exceed the impact of the internet’s introduction a few decades ago. Only time will tell, but it seems this is the first time A.I. has finally left the lab in a meaningful way and entered into the lives of ordinary people similar to how the internet finally did in the early 2000s. This will touch every industry in ways that even the internet had not previously done. It may, however, be a gradual process that will only be obvious in hindsight.
Where does that leave us with AppleScript, and its usefulness going forward? As I mentioned in one of my previous posts, my hope for the revitalization of AppleScript included thinking outside the box and modernizing its capabilities. After getting a chance to try ChatGPT for the first time, I had the nagging thought in the back of my mind that there was an air of familiarity to it all. Finally, it hit me. I am speaking to a computer in English, just like with AppleScript. And immediately following was the thought that this is exactly how Apple could breathe new life into AppleScript; this could very well be what AppleScript 3.0 may look like (at least a brand new informative side of it).
But what about the automative side? The other thought I had using ChatGPT, particularly when it was writing code, was that AppleScript (the current manifestation of it) has now been made more relevant and useful than ever before to potentially the widest target audience it has ever had. Being a generative transformer, the text output we can get from it allows us to generate executable AppleScript instantly. Automation enthusiasts and non-techies alike can now fully take advantage of macOS’s automation capabilities, and this will only get better with new iterations and as bigger players enter the market. As an example, Pixelmator Pro released full AppleScript support relatively recently. Because of this, users can take advantage of its new scripting functionality with the help of ChatGPT to accelerate their artistic workflow as well as expand their artistic capabilities (unlike Affinity Photo). Any and every app that has, or will have, a rich scriptable library will be fully prepared to take advantage of the avalanche of generative transformer capabilities that is both already here and imminent; ChatGPT is just the start. This will allow non A.I. based apps to stay relevant and not get left behind in the upcoming months and years.
Finally, we arrive at AppleScript’s value proposition as a programming language in and of itself (in contrast to its Apple Events based foundation which any language can theoretically take advantage of). I believe it has never been higher for the following reason. If a macOS user, who has never touched code in their life, wanted to create a script via ChatGPT in order to automate a task on their computer, the code that is output would be completely understandable if it were in AppleScript rather than, for example, JavaScript. Although everyone can’t write AppleScript code, the design of the language is such that virtually anyone could read and get at least a rough idea of what is going on. And after generating a few useful scripts, they could very quickly recognize the patterns of the language without any training in computer science. ChatGPT has opened programming to the masses, and there is no language more suitable for this new reality than AppleScript.
In short, the potential AppleScript has for its future is more exciting and convincing than ever. It now, suddenly, has a newness of life. This is a golden opportunity for Apple and all macOS developers.
You make some very interesting points, but I think one of the big issues with AppleScript is that’s it’s easy to read, but difficult to write. The “English-Likeness Monster” (as Matt Neuberg called it in AppleScript: The Definitive Guide) is very real. AppleScript tries to look beginner-friendly with English-like syntax, but it’s just a veneer over a very old, inflexible language underneath.
I think most of us love the language not because of the language itself, but because of what it can do. There still isn’t a suitable alternative that “just works”.
The big threat to AppleScript & to macOS automation in general is the neglect of scriptability in applications (in part, I’m sure, because of how fragile & tedious it is to implement). Apple could revolutionize automation by providing first-class scripting capabilities in Swift, but they probably don’t see it as enough of a priority (which is the real shame). Barring that, there are still a lot of changes that they could make to the AppleScript language itself to make it easier to use, but again, they probably won’t. A sad story all around.
Off the top of my head, a native dictionary type, dynamic record creation, default values for positional parameters, and anonymous functions would all be low-hanging fruit. I haven’t seen square brackets used in an AppleScript in the last 2 decades, yet these very useful tokens are still reserved for linked lists (and old type of list).
Large language models (chatGPT3 and the competitors now overtaking it) are probably irrelevant here. They’re:
They involve no model whatsoever of propositional dependencies – only of word by word linguistic probabilities. They have no means of making a distinction between a hallucinatory invention and something underpinned by experiment, institutional imprimatur, or deductive derivation. Even their imitation of arithmetic often goes wrong. The pitch is that this can be fixed by manual post-editing, but the scale of the problem is far beyond the reach of such remedies.
Potemkin-pretty, but no foundations – don’t move in. They’ll be gone when the tide comes in.
They’re best understood as a caricature of our deference to glib fluency.
Personally, I’ve been hoping for years now to see something like @hhas01’s SwiftAutomation get to a stable v1.0 release. The would allow a lot of the logic of my scripts to move to Swift, and if Apple gets their act together & releases native Swift scripting, it would be fairly easy to migrate the Apple Event code over too.
Right now, bridges like SwiftAutomation require generating a “glue” to look up the AppleScript event codes from the scripting dictionaries, but if this could be done by the script editor, I think it would be revolutionary. Script Debugger already has all of the explorer/lookup functionality built in, so if a future release had a Swift-mode that could dynamically resolve the AppleScript terminology, I would be delighted.
Mark/Shane, I don’t know if anything like that has been considered/proposed, but I would definitely be interested.
I’ve been quietly applescripting in the printing biz for 30 years. Making tons of money for my employers who then buy macs. I would speculate my productivity is 50% more than non scripters. The inter-application tasks just work. And are immediate solutions that are custom for my situations. Without it I am sunk, when it goes, then i will go. The lithography part has been exploited by corporations and automation. But the flexographic product world is unique, where you don’t really get predictable products that can easily be slapped into an automated world. Why? it is because they are created by creative people that come in every shape and size as do their products. They want unique, AI and automation is programmed on repetitiveness, sucked from the mundane on whats taken from the public, where boredom lives. That is where applescript shines, with 100 scripts at my fingertips a human can switch up the combination of scripts to run as the unpredictable arises. And it arises everyday.
We are the silent creative people, solving real problems, getting things done without alot of noise.
Apple used to be, think different, cut out the beams and girders on which it was built …well bury me in the ruble.
That’s the same reason I’m using Applescript.
Great story! Great reason why Apple should stick with AppleScript.
I agree
I expect Apple listen and acts
I agree strongly . Just in the last few years I’ve written hundreds of AppleScripts to make my everyday life as a software engineer more fun.
I agree.
(The site rules won’t accept a reply of under 20 characters.)
I still agree with near-rabid intensity.
The state of macOS automation is tragic. AppleScript is moribund and worse, every new OS release breaks something.
Automator is dead and I for one have never grieved its loss.
Shortcuts is a bad port from iOS, and even if the macOS app is some day improved, will likely remain horrifically clumsy and very limited. Developers appear to have little if any interest in extending their apps to take advantage of it. More generally, there has never been a graphic interface to coding that wasn’t awful. It’s a blind alley.
JavaScript for Automation is a mess, has even more problems than AppleScript, and is poorly documented besides.
Apple once understood that every part of its interlinked ecosystem was important, and that while some aspects were not profitable in and of themselves, still contributed significantly to the aggregate and deserved attention and resources.
Support for power users has been decking for a decade. macOS itself is moribund. But for the Unix subsystem, Apple would offer almost nothing for serious computing.