Petition Apple for AppleScript 3.0

TL;DR — If you’d like to see Apple resume development of AppleScript, please reply ‘I agree’ below.

AppleScript as a scripting language is one of the most beautiful, unique, and unparalleled features of macOS; and don’t let anyone tell you otherwise. It has always been one of the pillars of what makes a Mac a Mac, and what makes a Mac stand out from the crowd.

Over the years, certain loud individuals have given the impression that AppleScript is clunky and, although useful, needs to go the way of the dinosaur. It has built a “reputation” of being loathed by programmers. This couldn’t be further from the truth. I, as a Software Engineer, have found myself repeatedly returning to AppleScript since I first took the time to learn it years ago, not only for its fantastic and unmatched automation capabilities, but also as the perfect platform for writing executable pseudocode. The syntax is nearly identical to the generally accepted format of pseudocode, and is thus worthy of continued development for that fact alone. It is always a refreshing change when switching context from an obtuse programming language to the English-like syntax of AppleScript.

Unfortunately, Apple has apparently acquiesced to the undeserved “reputation” and since the departure of Sal Soghoian (lead of Automation technology at Apple), development and promotion of the AppleScript language has apparently come to a halt. There have been certain murmurs by some that Siri Shortcuts is the future of Mac Automation. However, this is an unfounded assertion due to the significant limitations of Siri Shortcuts. Being a GUI based drag and drop system, Siri Shortcuts is little more than a rebranding of Automator, and inherits the same limitations that any GUI based system inherently has. Additionally, Siri Shortcuts on macOS has direct support for executing AppleScript code blocks, suggesting Apple is well aware Siri Shortcuts is in no way capable of superseding the functionality of AppleScript. At the end of the day, the ability to write out your commands can never be replaced, and the english-like syntax of the AppleScript language is the perfect, most ‘Apple’ way of doing it. Additionally, many well known Applications already have vast scripting libraries that individuals and corporations have written scripts for and which they continue to rely on for their workflow. This includes Apple themselves as you will see the need for AppleScript sprinkled throughout some of their macOS APIs. This is because Apple Events, the foundational component for automating with AppleScript, is an integral part of macOS to this day.

The goal of this thread is to hopefully build enough support to let Apple know AppleScript is worthy of continued development, new features, and overall general improvements. A revival of AppleScript promotion and development from Apple would ensure Apple’s system will remain ahead of the pack in the field of powerful end-user automation, and will spark a renaissance of developers adding significant and useful scripting libraries to applications as part of their development strategy. I would argue that, although script based automation will probably never be used ubiquitously, it creates the most ardent and loyal supporters from those that do. When a manual, time-consuming process or workflow is able to be replaced with a fully customizable end-user created script that can be run with a single click (or even executed on it’s own depending on certain event conditions), the result of executing said script is the fulfillment of the inherent power of computers, finally unlocked to whomever is willing to learn the language. That is truly powerful and an asset Apple should hold on to.

If you agree and would like to see Apple resume development on AppleScript as a language and as one of the primary pillars of it’s automation strategy, please add your comments below. A simple ‘I agree’ would help, and you can also add any other thoughts or ideas for why/how AppleScript has been useful to you and/or how you might like to see it further developed.


I agree. Long live AppleScript!

I agree. Without Applescript my day would be much less productive. I use Applescript scripts for tasks every day of the week.

I agree with the sentiment, but not the language. Sorry.

1 Like

I agree! Life without Applescript would be a complete bummer!

Good grief.

  1. Please use clearer paragraph breaks. That is unreadable.

  2. Please accept that AppleScript is an elderly and not very popular scripting language in the long tail stage of its life cycle.

  3. There is probably a billion dollars of business, largely print, quietly passing through AppleScript workflows every year. That’s a big deal for those businesses. To Apple though? It’s chump change down the back of Tim Cook’s couch. Especially when Apple receives $0 of that money directly, and even indirectly (from Mac sales) it’s barely a blip.

  4. Print hasn’t been a core market for Apple in 20 years. iOS is where Apple makes all its money now; the only reason Apple still makes Macs is so that iOS developers have an Apple-controlled platform to develop iOS Apps on. If Apple could get rid of Macs, they would, and they’d be absolutely right to do so. But they can’t, not without handing control of the iOS development platform to a competitor. Still, any macOS technology that doesn’t exist on iOS too had either be utterly critical to the Mac platform and iOS App development (Xcode) or else just some old legacy tech which is more hassle than it’s worth to remove/replace.

  5. Sal Soghoian got himself sacked by Apple and the entire Mac Automation department disbanded for very good reason: in 20 years, that team’s products completely failed as products. Protip: it does not matter in business if you’ve created the best technology in the world: if you fail to put bums on seats with it, it ain’t worth squat.

  6. And when I say “completely failed”, what I mean is catastrophically. By 2007 there were probably 10 million scripters and programmers on Mac OS X: Python, Ruby, Objective-C, JavaScript. By 2016, that and millions of shiny new Swift programmers too. If Sal and team had won even a million of those users over, they would still be in their jobs. And yet, I doubt they even scraped a thousand, and most of those user eventually got pissed off at just how technically poor their AppleScript alternatives—Scripting Bridge and JavaScript for Automation—were. (I bet as a “Software Engineer” OP wasn’t even aware that programmer-friendly alternatives to AppleScript existed, never mind which of those alternatives were excellent vs complete crap.)

  7. Seriously, I kid you not: Scripting Bridge and JavaScript for Automation made AppleScript look fabulously competent and capable by comparison. That said, merely being technically crap isn’t what killed them (e.g. just look at the incredible success of Windows 3.1). What killed them is that Sal and team never lifted a finger to market them to users. They just stuck them in the OS, half-baked and buggy, and then wandered off. Protip #2: If you don’t sell your product loud and hard, no-one knows about it. And since no-one knows about it, no-one uses it. So your product dies.

7a. There were people—expert users—out in the community who would’ve enthusiastically marketed and supported SB and JXA for them, for free. But Sal (and team) arrogantly blew them off.

  1. I do not say this lightly: Sal Soghoian was totally unfit to be Mac Automation’s Product Manager. He lucked into his job by being in the right place at the right time, and being a natural charmer. But he had zero clue how to do the job itself, and in 20 years never tried to learn either. Sal literally ran Mac Automation into the ground.

  2. I told Sal in 2015, a year before he was sacked, that he was mismanaging Mac Automation into its grave. (Sal took that blunt truth about as well as anyone with a large delicate ego would.) When a big company like Apple publicly says they’re “eliminating your position”, what they actually mean is one of two possibilities:

    “Your awesome competence is embarrassing your lazy and incompetent bosses,” or

    “Your awesome incompetence is embarrassing your lazy and incompetent bosses.”

9a. My old dad was the first sort. In 20 years, he worked his way from electrical engineer to junior manager to senior executive, with the honest habit of informing the board the full costs of their money-grabbing decisions, in an industry where the phrase “Whoops!” is often followed by a fatal accident enquiry. (At least the board were good enough to tie him to a golden parachute when they pushed him out.)

9b. Sal Soghoian is not the first sort. Back in 2013, when Apple handed Sal their JavaScriptCore engine to turn into a new Mac Automation product, Node.js was just starting to take off. All Sal had to do was package and sell Apple’s own JavaScript as a competent, Apple-owned alternative to Node.js. There are millions of JavaScript developers who use Macs. If Sal had won just 10,000 of them with JXA, those thousands would’ve promoted and sold JXA to the millions of others. Sal straight up handed those millions of JavaScript developers to Node.js.

3c. Node.js is Google’s V8 JavaScript engine, packaged as a command-line node tool, with excellent library and tool support.

3d. Read 3c again: Google’s V8 JavaScript engine. Apple’s JavaScriptCore engine is nothing outside of Safari.

  1. By effortlessly handing what should’ve been Mac Automation’s greatest victory over to Apple’s biggest competitor, Sal didn’t just kill Mac Automation as we know it, he turned its mention into future career poison. Seriously, who inside Apple is going to admit that, actually, the fundamental technology is great; it was the selling of it that was an absolute disaster? Certainly not any of Sal’s line managers, as to do so would declare their own negligence! I can’t see any of the Shortcuts engineers stepping up either: no-one advances their career by fixing up the last guy’s mistakes, they advances it by selling their own brand new shiny (which is probably also full of mistakes…but as long as it sells, who cares?!).

This is why AppleScript is already dead, and why Apple sees the future of Apple Automation as being built on cross-platform Siri Shortcuts. Apple event IPC had multiple chances to prove itself, and failed them all. Thus the Blocker now isn’t technological, it’s political. AppleScript’s reputation inside Apple has been so completely destroyed, it cannot come back from that; not without the people capable of bringing it back admitting that they allowed it to be destroyed in the first place. Yup. #GLWT.

Shortcuts may be far less powerful (and also a right sack of knackers, technologically speaking), but if by pursuing Shortcuts as Automation 2.0 Apple manages to put a million bums on seats then it will be a far greater success than AppleScript ever was, and quite right too.

BTW, in case anyone is tempted to argue with me: Don’t. I am THE world expert in this particular technology—what it is capable of, and what Apple is throwing away. In the last 22 years I have probably invested 10,000 hours of my life in learning, building, using, and teaching it. I am the only person on the planet to build Apple event bridges for Mac OS X that are competent to replace AppleScript. I have also done a good deal of research into end-user scripting and automation languages, from Papert’s Logo onwards. I have designed, built, used, and trained, my own domain-specific end-user automation language, kiwi (videos below). And I have over the last few years developed several prototypes for a general-purpose scripting language capable of replacing both the end-of-lifed AppleScript and Shortcuts’ godawful XML-based engine (iris is the one to look at, btw; and, yes, the name is an obvious hint at how to position and market it correctly).

The only person here who is qualified to argue any of this with me is Mark, and while he knows some aspects of OSA better than me I’m sure he’ll agree that when it comes to Apple event IPC. And, much as I enjoy chatting with Mark, the only person I’m interested in talking to about the future of Apple Automation now is Vivek Bhardwaj, so if you’ve got his email in your rolodex then you can help me; else, nope.

TL;DR: Apple does not care one whit for your feels, only for your $$$$. And those $$$$ come from iOS products and services, not Macs (and definitely not AppleScript users).

p.s. Related reading (one from William Cook, RIP, who back in 1990 designed AppleScript at Apple, and the rest with pawprints of yours truly):

p.p.s. Do I sound salty? Hell yes. For multiple reasons, including (though not limited to) 1. my own ignorant incompetent failure to get appscript bundled in Mac OS X 10.5 after Apple personally opened the door for me; 2. freely providing Sal 6 weeks of unpaid expert consultancy to get JXA fit and ready for market, only for him to completely piss my time ($40K in today’s money) and goodwill (worth an entire JXA community) up against a wall; 3. my own ignorant incompetent failure after 1 & 2 to recognize PEBKAC and offer SwiftAutomation directly to the Swift developers and managers, instead of to Sal (again!) who threw it back in my face (again!).

p.p.p.s. I can say a lot more about Mac Automation’s “hidden history”, and how two total idiots—Sal and myself—managed to kill it without even trying. However, I’m done for the night. Instead here is what a halfway decent scripting language looks like, driving the most advanced Adobe Illustrator automation engine on the planet, and doing it all via Apple event IPC too because that technology genuinely rocks once unshackled from the underpowered obfuscated mess that is AppleScript. (A crappy mess that despite its crappiness has nevertheless enabled many thousands of Mac users to build truly incredible automations over the last 30 years, but which could have, and should have, enabled many millions instead.)

1 Like

@hhas01 This was an interesting read. However the intentions behind it remain somewhat obscure as there is much blending with bad personal experiences with developers of AppleScript. As stated in the topic post, the goal of the thread is merely to encourage Apple to revisit development and promotion of AppleScript, both as a language and as one of its pillars for automation technology. Apple should always have 1 unified GUI automation platform (now Shortcuts) and 1 unified Scripting automation platform (AppleScript) depending on the needs of the end-user. Although you mentioned no one, save Mark, is qualified to respond to this post, I still wanted to offer my 2 cents and address some of the points you raised for anyone else who may have been confused as pertaining to the goal of this thread.

  1. AppleScript being “elderly” and “not very popular” are not convincing arguments for its demise. In the 90s, macOS was also not very popular, but continued development and promotion finally turned the tables. AppleScript simply needs renewed support from Apple in its development and promotion and the tables can likewise be turned. There are so many angles Apple can take. For example, seeing as how Apple is adamant on promoting ‘everyone can code’, the simplicity of the AppleScript syntax could be an option as an approachable introduction for those who are allergic to regular code, and they could learn the principles of code in the familiar setting of AppleScript’s English-like syntax. There are many other angles they could take to make it catch on this time around.

3-4. The idea that Apple should abandon a technology because it doesn’t receive direct or easily decipherable financial gain from it is a very dangerous path to take. Many successful companies have risen from nothing based on the implementation of a great idea or beautiful design, and many have also fallen when they lost touch with those ideals and focused too heavily on accounting, making virtually everything a financial decision, even to the detriment of the allure of the product.
The golden age of Steve Jobs’ Apple was a philosophical one, not just a financial one, and this was how he turned Apple around from its tailspin. It is the reason Johny Ive has the revered remembrance in Apple culture. It is likewise why Steve, and not Tim, is known as the visionary. Additionally, tech companies that build products solely based on certain accounting calculations or analysis from actuaries tend to make the most boring and uninteresting products. Likewise, when a company builds a roadmap only from financial analyses to the detriment of interesting and innovative features, it tends to catch up with them as boredom begins to set in and longtime loyal customers begin looking elsewhere. This is a slow, gradual, but certain process that no actuary is equipped to foresee.

In addition, I perceive there is an attempt to have your cake and eat it too: the point is made that a tech that supports billion dollar companies is not worth Apple’s time, but Siri Shortcuts, which will never approach this kind of dependence, should be Apple’s focus for automation. This is a clear contradiction and a logical fallacy. If point 3-4 were true, both Apple and all tech companies should abandon end-user automation altogether (along with a host of other features).

Additionally, in light of the anthropomorphism of the post, you can think of macOS as a body. AppleScript is not distinct, it is part of the body. It is rare that an individual feature in a system can be singled out and be given a dollar value.

You may still argue ‘who cares, Apple’s job is to make money’ to which I would respond, this thread was designed for end-users of Apple systems, particularly fans of Apple automation, not Apple stock holders. My goal is to get Apple to realize at least some of its users still care and are enthusiastic about AppleScript and would like to see it revived.

5-10. These points seem to stem from an apparently bad personal experience with Sal and historical development of the AppleScript language, rather than a clear reasoning for why AppleScript should not be improved by a new team with a fresh approach at Apple. In fact, in arguing these points, it would seem to imply an improvement in AppleScript would be welcome (since it is apparently in such a bad state currently)

The post, while taking a decidedly antagonistic stance, has supported the main premise of the thread (i.e. AppleScript is in need of improvement and promotion in order to succeed; the very purpose of this thread). This may be due to bitterness from your past experience. In other words, whether you currently love AppleScript and look forward to more features and improvements, or you wish AppleScript wasn’t ‘as bad as it is now’, both parties would agree that a new and improved AppleScript is a good thing, not a bad thing.

Apple has more than enough capital to revive AppleScript. And they have more than enough current user base to justify doing it. The only problem is it has not seen a modern approach. You made it clear that the problem had more to do with those who previously were developing the technology, rather than the worthiness of the technology of itself. At the end of the day AppleScript is not Sal, AppleScript is not hhas01. Rather, AppleScript is an idea; an idea that Mac power users can learn one unified approachable English-like automation language and control their entire machine and every app with it. This is what we would like to see in the improvement to AppleScript 3.0. This is leaps and bounds preferable to each App having it’s own scripting platform or being limited to a GUI based platform.

It is mentioned that AppleScript is a failure because it has thousands of users and not millions. This is misleading for a number of reasons: the value of those thousands who believe firmly in the platform can be much more valuable than millions of another platform that have no true attachment to said platform. When 1 person takes the time to write an AppleScript to fulfill a certain workflow that they regularly depend on, that is worth more than 10 people who create a Siri shortcut that reminds them to take their vitamin. One of these is virtually irreplaceable while the other is easily replaceable. I can’t speak for others, but I have already made use of countless AppleScripts that added a real and critical value while, on the other hand, have never created or come across a Siri Shortcut that I couldn’t easily do without. Additionally, there’s no reason why those numbers can’t increase if the goal of this thread is accomplished. You said it yourself; AppleScript ‘failed’ because it is buggy and was never properly promoted. This is exactly what would be fixed if, as this petition advocates, AppleScript is improved and promoted.

GUI automation cannot be the future of automation. There needs to be at least 1 unified scripting automation platform, and unless Apple wants to start from scratch, build a whole new system, wipe away all the apps that already have vast scripting libraries in the hopes they will all jump on board and make an equally useful library, and wipe away all the scripts already written by end-users, revisiting and improving AppleScript is the only option. For example, both Microsoft Office and Adobe CC have vast AppleScript libraries throughout their suite of applications. These were created at a time when AppleScript was heavily promoted and adding such support was more in line with said companies’ business strategy. Since they have already built the support, continued work on that existing foundation is a reasonable expectation (especially if Apple renews the AppleScript platform). However, if AppleScript was deprecated and removed from macOS for Siri Shortcuts or some new language, it is doubtful these Apps would ever implement a new automation library for whatever was the successor. The result would be either little to no automation, or fragmented automation in which each app would need to create its own automation platform, as some have apparently started doing such as the one you mentioned for Illustrator. The end result is even less users of automation, not more.

If there are people at Apple with whom AppleScript has a bad reputation, they simply need to get over it because there is no other viable option that will not significantly set automation back on Apple systems to a point which they may never recover from.

Throughout the post, I notice multiple allusions to AppleScript being dead. AppleScript is not dead or alive. To say it is dead would be to anthropomorphize it in order to achieve a certain goal (in this case to abandon a beautiful technology). It is simply code. Code can always be improved; a point you have made clear in your post. I do not doubt you know more about the history of AppleScript and its past development, but it is possible that your past personal experiences have clouded judgement on where we should go from here. It is also mentioned that it is buggy and a mess. Typically, buggy software is fixed, not scrapped. Else we would have never reached macOS 12 or iOS 15 for that matter. In other words, this is reason for its improvement, not its demise. Regardless, this point (of AppleScript being irreversibly buggy) is overstated. 99.99% of my experience with AppleScript is that it has executed flawlessly, so I’m not sure where this buggy / messy property of AppleScript is coming from. But whatever it is, I’m sure it’s nothing that can’t be fixed.

With all things considered, including the valid points you raised, AppleScript’s revival is the only way that makes sense. I sincerely can’t imagine any logical reason why any end-user of macOS would be against the improvement of the AppleScript automation platform without some personal or ulterior motive. Whether you love it, are indifferent, or hate its current state, a modern objective improvement should logically be a good thing.

Each year we get a new macOS update. The new features are rarely added based on a dollar value that Apple believes it will generate. They are usually simply features Apple engineers thought would be useful for the improved workflow of some of their end-users. This is precisely what AppleScript automation is, and perhaps one of the best examples of it; an undeniably useful improvement in workflow for some of their end-users.

Finally, I am passionate about AppleScript and believe it is worth defending more than nearly any other feature offered by Mac. This is because, old or new, it creates a complete paradigm shift and this is something that has never and will never change as long as it’s around. It is the first and still truly best personal assistant. When we look around at the industry, it is clear that personal assistants have become the focus of many companies, whether its Siri, Alexa, Ok Google, Cortana, etc. And they have their place. However, none of these, although built upon much more complex algorithms and implementations, hold a candle to the real world usefulness of AppleScript. What AppleScript allows you to do is delegate hundreds of hours of real, boring, and/or repetitive work to your computer. It essentially allows you to communicate with your computer via texting (i.e. scripting). For most people, a computer is a tool that is brimming with potential. But for those who take a few weeks to learn how to speak with the computer by studying its native language (AppleScript), it truly becomes a robot that will do as you say, with very few limitations. And those few limitations can be virtually cleared with Apple renewing development and promotion as well as modernizing it with new features, motivating developers to let their apps understand this universal language for your benefit by building out a scripting library, allowing full automative control of their apps. All apps, not just the obvious ones, should ideally support scripting because end-users have always been creative in finding uses for automation (ref. @alldritt 's Illustrator scripting implementation which at the time was not an obvious choice, but won over Steve and was highlighted by Sal at WWDC of that year). My hope is that, if Apple returns to AppleScript, those behind it will approach it with fresh minds, thinking outside the box of all that AppleScript 3.0 could be. For example, bringing modern concepts like machine learning (e.g. tell application “Photos” to get every picture containing a dog with properties {breed: Golden Retriever}), graphing capabilities (tell application “Graphing Events” to plot someStreamingRecord with properties {type: Line Graph, time: Real Time}). The possibilities are endless, and with developers motivated to be fully on board by proper promotion at WWDC and more streamlined implementation APIs, the possibilities of what end-users could create are likewise endless. The reach could span from power users to students to scientists to insert any profession or use scenario here since computers have become ubiquitous in our lives. Today’s Apple is more capable than ever in accomplishing this; let’s encourage them. In other words, fixing whatever is broken, confirming everything that works, and expanding to everything that could be.


Applescript, to my knowledge, has never been marketed or sold separately. Making it impossible to equate a dollar value to it. It is a part of the whole, much like Safari, Mail, Calculator, Books, Calendar, Finder, Music, News, Photos, etc. All parts of the whole that make a system interesting and usable.

To state Apple is only keeping the Mac around because they don’t want to hand over the OS control to someone else is implying Microsoft. When we all know if Apple had no interest in Mac and OSX they could easily move to a Linux environment for the iOS development. I’m sure the Mac is a profitable portion of Apple’s business or they wouldn’t keep developing the platforms. They even give away the OS with it.

I have 35 scripts, 18 of those controlled with keyboard shortcuts in FastScripts, that I use daily. A few of these are complex scripts of 500+ lines of code. That is why I use a Mac. I use Applescript to, as a book I read on Python stated, “Automate the boring stuff”.

I agree, for the passion alone.

I agree – Apple should make it better or dump it and move everyone to Swift. I first used AS because I thought it was simple and quick (yes, I’m lazy and want quick results). 5 years later and I still make numpty mistakes (posix/non-posix is a favourite). As my objective was to create a GUI front end for a Python script, I should have moved quickly to Swift. If not for Shane’s excellent dialog toolkit, I would have. I guess whether Apple invests in AS or dumps it will depend on how much work is needed to keep it functional with every new macOS. So far it seems it’s not been too much effort. But, every year a new macOS increases the chances of something (else) in AS breaking.

I had a much longer reply written yesterday, laying out in great detail why everything you just said is not 100% wrong it is 100% irrelevant, but I’m not going to post that.

Instead, I will respond to just one sentence, because it perfectly illustrates why you do not understand what you’re talking about:

This is where you go Wrong. Because AppleScript is not an “idea” or a “technology”. It is a product which has a market. That market is already dead; therefore the product is already dead.

To understand why, you need to understand Who killed it. Two people did: one is Sal, the other is me.

These two people had all the technology they needed to not just save it but to turn it into a multi-million user success. They had multiple markets who would fall over themselves to embrace those technologies. They had the position and authority within Apple to get those technologies into macOS. They had the skills and community network to evangelize, educate, support, and grow those markets. They were gifted multiple unique opportunities by Apple to do so.

So, if you can explain to everyone here (yourself included!) just how and why these two people utterly failed to capitalize on their myriad advantages and—when they should have been busy winning those million-people markets and riding them to mass success and influence to a new golden age of Mac Automation—instead between them left their beloved platform a walking corpse, then maybe, just maybe, you are competent and qualified to attempt to tackle this problem yourself.

Here is a pair of truisms to get you started:

  1. All Technology is Automation.

  2. All Automation is People.

Note the 3 parts. If you can tell me—correctly—which of these three components is the least important and which is the most important, then we have a basis for future conversation. If you can’t, or just say the answers that you think I want to hear without understanding the reasoning for yourself, then we have nothing to discuss: it just means you are one more arrogant, ignorant, naive fool, no different to me (at least until Apple and others in business took the time to school me… the hard way).

Now, because people consistently mis-understand what motivates me, here is a long, boring aside:

I am not saying any of this to be arrogant, dismissive, or cruel to you. I am saying it to be kind. To help you see what you currently cannot see, and which I know you do not see, because I see you. Where you are now? I was there first.

My goal here is lift your understanding of your chosen problem space. Fast.

Right now, your thinking is where my thinking was 14 years ago. Since then, I have had 14 years of learning by doing, failing (repeatedly!), and learning from those mistakes so that, while I continue to make new mistakes, at least I don’t repeat old ones as well. If I can advance your game by 14 years in a few weeks, all that raw well-intentioned enthusiasm of yours might yet do real, useful work.

Also, to provide some persective at a level on which everyone here can relate:

My last mistake (2017) cost me $200,000 of life savings, 2 years of my life, and lost me my first technology startup without even trying. That is a very expensive lesson in how not to business for any one person to make. And now I am offering you that lesson on a plate, completely for free, along with all the other lessons that I have picked up from myself from others along the way.

Personally, I would call that a gift.

And I know that 90% nerds will instantly turn up their noses at this gift.

Because it does not contain anything that immediately interests and excites them, so they assign it an importance of zero and scorn it as “luser nonsense” that is “beneath them”. They like tech, they want to do tech, they know they can do the tech better than anyone on the planet. So they do the tech, and they fail, and they fail to understand why they fail. Because tech is all they know and care about, and tech is all they want to do.

This is the reason the tech world is already filled with angry impotent techies outraged at how the rest of the world doesn’t listen to them or respect their superior knowledge, experience, and years of hard graft, while their awesome, empowering, beloved tech sinks wholly unnoticed by everyone but themselves.

So if you already know you are one of the 90% that is unwilling to change: kindly sit down, shut up, and save all of the the trouble of watching as you deliberately fail too.

Rule #1 of How to Succeed in the Tech Business as a Techie Yourself: Look at all of the things that others in business are doing and which you are not—i.e. all of the things which you do not currently know how to do/care how to do—and learn how to do all of those things right now.

Once you are doing all of those other business things right, your tech can look after itself. If you don’t? Your tech will never be anything more than some self-indulgent code masturbation with and for an audience of one which utterly fails to change the world.

I am offering you a quarter-million dollars-worth of free education. Take the compliment.

Now back to business:

Until you stop seeing Mac Automation as a technology problem in need of a technology solution, you are NOT competent and qualified to do jack… except for waste your own and any other suckers’ time on a futile exercise that makes even my own two decades of grandly tilting at windmills look positively productive.

So stop thinking as a myopic self-indulgent tech geek, thinking all about yourself and how many ponies you want for Christmas, and start thinking as an ambitious, ruthless, utterly unsentimental businessman. That is, start thinking like Apple itself. Ask yourself what Apple wants; what motivates Apple to sell one product and kill another. Align your interests with theirs. Not demand like an absolute douche that they align theirs with yours.[1]

And then understand that Apple itself is people too. Because once you understand what interests, drives, and rewards those people, you are in a position to craft a market pitch, a product story, to them—and maybe, just maybe, you will succeed where Sal and I both failed.

Here, by the way, is The Person [2] you will need to sell your awesome new vision to:

And here is The Why:

Okay, Saturday sermon’s over.[3] There’s homework tasks above for you to do, if you are genuine about achieving your goal. I will grade any answers Monday.

[1] I kid folks not; some absolute idiot actually wrote this:

“If there are people at Apple with whom AppleScript has a bad reputation, they simply need to get over it because there is no other viable option”

The arrogance and hubris in this is astounding! BTW, if I was a mere code monkey grafting at Apple I would pin this quote on the wall of my cubicle (printed on the back of an old TPS report cover sheet, of course), and laugh at it every day that I came in to work. And invite all my other cubicle mates to come laugh at it daily too. Best medicine.

And you would be lucky too. ’Cos, believe me, if you said to any manager at Apple with the actual power to give you what you’re after to “get over themselves”, the only possible action they would ever take is to use that power to ensure you get the exact opposite—assuming they could even be bothered with you at all.

Seriously, dude. There is one person who needs to get over themselves. Don’t do it again.

[2] However, if you even attempt to contact Mr Bhardwaj—or anyone else in Apple—before you have fully addressed all of the above and have your entire sales pitch scripted and field tested to a fault, I will personally reach out and slap you twice as hard as Canonbie Dick.

There is a right order and a wrong order in doing things. I have slapped myself for doing the wrong one more than once. And now I offer all those lessons to you, so you have absolutely no excuse for duplicating any of the mistakes that Sal and I have made first.

[3] I have one last post to make on this thread, which I will prepare for next week. You will like it too: it’s all about the technology bit. Which is, as I say, the least important part—however, if you can approach Apple with a robust, highly attractive market proposal, and a working prototype of the technology they need to build in order to construct the Product that will win that Market for themselves, you’ll maximize your chance that Apple pays any attention to you. Because the moment you can make them notice you, you will have your foot in their door…and then your real sale begins!

ETA: @lite: My apologies: While I’m lecturing you on the importance of doing your due diligence, yada-yada, it occurred to me that I had not; as if I had I could’ve saved you all the trouble of penning that second post. Top search result:

Read the date and read the signee count.

I knew just from the title of your post, before I’d even clicked on it to read, your petition plan was 100% guaranteed a total waste of everyone’s time. I just forgot one thing: I’d already seen it all before. One of the hazards of my being a bear of very little brain: terribly slow thinker.

So, having now (belatedly) supplied you the receipts that your petition idea was always a dead duck, if you would like to move past that painful truth and onto plan B, we can pick it up next week from where I left off. If not, just enjoy AppleScript for as long as we have it.

Have a good weekend,


“long-winded, opinionated, and impolitic”—Dr Drang

1 Like

A little preview of next week’s post:

tell to do
    make new: #document at: end of documents with_properties: {name: “Test”, text: “hello again!”}
    get text of every document

➞ [“hello again!”]

That, by the way, is working code[1]. You can build it and run it today, if you like[2].

It is also NOT what you think it is.

(If anyone wishes to guess what it actually is, bearing in mind what I’ve been saying above, you are welcome to DM me and I’ll tell you if you got it or not. If you do guess right, I’ll pop $20 to your charity of choice. If not, I’ll pop $20 to mine; up to 5 wrong answers max.)

[1] With exception of the UTI namespace, which is not yet implemented. The working example on my GH uses old-style app “” as a stopgap. However, the UTI scheme is key to script-level sandboxing and sandbox security is essential to selling scripting back into Apple for obvious reasons.

[2] If you don’t mind monkeying around in Xcode and Swift a bit. Get the iris-script project off my GitHub, plus its AppleEvents and SwiftAutomation dependencies). It doesn’t currently include a target for building a standalone command-line interpreter for batch/REPL use, but that would not be hard to add if someone wanted to add it themselves/pay someone else to add it.

1 Like

As I have stated: there is 0% of “make AppleScript better”. The language is already a decade into the long tail of its lifecycle and 6 years into minimum maintenance mode, and the department that used to develop it ceased to exist in 2016. It will continue in its current state until the that day it stops, whether actively by Apple’s hand or passively as its declining userbase approaches 0.

Moving everyone to Swift for [text-based] coding could well be Apple’s roadmap: Swift for pros, Shortcuts for everyone else. That’s a pretty decent business: fewest moving parts, fewest development costs and support overheads, clean simple message to market.

In terms of hitting its targets, this plan is ultimately capped by the ever-swelling complexity of Swift language—which limits how many people can learn text-based coding—and by the low, fixed ceiling and poor scalability and learnability of Shortcuts as it exists in its current form. Even so, this plan only has to be “Good Enough” to secure a few percentage of Apple’s 1Bn iPhone customers (plus a steady supply of App vendors providing new features), and it will be an emormous success. That will be more than sufficient to prove that their new Automation strategy is the correct one, and confirm they can retire its unsuccessful predecessor on whatever schedule they choose.

Moving to Swift only addresses the language part of your problem, however. It doesn’t tackle the application automation part: the ability to control applications remotely from another app or script.

At the moment, it looks like Apple’s roadmap for app-to-app communication is to move to app extensions and intents. These are both limited in capability and “expensive” to deliver (in terms of the complexity that goes into adding each one), which makes their power-to-weight ratio quite poor—the same problem Automator Actions had (and look at the app support for those).

That said, with a 1Bn potential market for these features, there should be no lack of App developers eager to support it anyway. It might not be as elegant but sheer brute force will do nicely when there’s a pot of money as big as Texas to pay for it!

Remember too, any automation technology that does not already/will not work across all Apple OSes—Mac, iPad, iPhone, iWatch—is a non-starter for Apple’s future plans. Thus if a new automation tech were to support legacy Apple event IPC, it could only do this as a stopgap while a new cross-platform IPC architecture is being grown to succeed it. Look at where Apple wants to be in future, not where they already were, and design your product and market pitch to appeal to that that. “Oh, and it’s backwards-compatible too” is a footnote to slip in at the end, when they’re too busy salivating at the thought of profits ahead to notice you did it.

Needless to say, I did some “prototype development” on a modern, cross-platform, pure-Swift successor to Apple event IPC a few years ago.

Of course, I did it by rebuilding my existing Swift Apple event bridge, SwiftAutomation, fully decoupling it from the Mac-only Carbon Apple Event Manager, so that it now assembles and unpacks AppleEvent record data structure directly. There’s just a tiny bit of glue code where it uses the AEM to send those AEs via AESendMessage, but replacing that with a direct hook into Mach Services would not be hard.

(Observe me here: burying the lede! After successfully reverse-engineered the undocumented serialization format used by AEFlattenDesc, I was pissed to discover that AEM doesn’t actually use that format when it packs AE data into Mach messages; instead it uses a completely different undocumented format instead—augh! I stopped at that point, as reverse-engineering black-box Mach stuff is far harder: best person to do that would be a macOS security researcher, and I’m not paying for that.)

The other task, which I never did get around to starting (ostensibly cos SwiftUI was barely in existence and not nearly mature enough at the time), was creating a pure Swift alternative to the CocoaScripting framework, specifically built to work with SwiftUI apps. The logic there being that SwiftUI’s Model-View model is quite prescriptive in how Model objects should present their data to View APIs, so if a SwiftAutomation View layer can talk directly to those same Model objects then a SwiftUI app that architects its Model-View correctly can add a second View (a scripting and automation interface) for very little additional cost[1].

(Again, burying the lede here: Implementing an Apple Event Object Model is a giant PITA; architecting a reliable general reusable framework for it 100x worse. CS tried; failed. Hell, even SQL never quite nailed it, at least not from an end-user-accessible UI/UX perspective. This is a Hard Problem[2]! The only reason to push through that massive pain anyway and build an AEOM-style query-handling framework now is because Apple’s Siri is already a query builder, so if users can say stuff like “Please forward all the emails I received today from Bob Smith over to Janet Brown” to their Mail app, it is infinitely easier for them to say just that, instead of for (i = inbox.emails.count - 1; i >= 0; i--) { blah-blah-blah-BS; }. One of these reaches an audience of several million, the other several billion! Those are the numbers that Apple will notice.)

Anyway, had I finished building a high-quality, cross-platform-portable SwiftAutomation framework, I’d have pitched that tech to Apple’s Swifties as a modern turnkey successor to the ugly shambolic old mismatched mess of Mac-only Apple event APIs. (Accompanying the market and product pitch, of course, because it’s awesome markets Apple wants to hear all about, not the tech itself.) Sadly there are practical financial and mental limits to the amount of on-spec work I can/will do, and cross-platform SA hit that limit pretty early on.

So, hey, if you want to continue that development where I left off, or generate funding to pay someone else to do it, be my guest. Plus, you know, it’s just a really cool, AppleScript-qualitt AE bridge to play around with in Swift. (With usual Caveat Emptor, E&OE, etc, that I no longer do [unpaid] support for SA or my other surviving AE bridges, Python 3 appscript and nodeautomation.)

[1] This is what CocoaScripting tried to do for ObjC-based apps, BTW, but CS was originally designed by a NeXT dev who didn’t grok the Apple Event Object Model, and later somewhat patched up by the AS team who did their usual, so that CS, just like the Space Shuttle—consistently over-promised and under-delivered and periodically blew up.

[2] A full AEOM framework essentially grafts a classical relational query (SQL) engine on top of thousands of classically object-oriented (MVC) applications all wildly different. Batch operations like move, duplicate, and delete work beautifully on unordered Set and Dictionary collections; when applied to order-sensitive Arrays they are Absolute Hell on Earth. (Off-by-1 errors are the least of the problems facing it.) And OO apps like using lots of arrays to hold their Model data too…

1 Like

I agree. I love AppleScript!

1 Like

I agree.

Either update AppleScript, or provide a more capable replacement. As it stands, Apple’s automation - and therefore support for power users - suffers from ADHD. Multiple mediocre options, none of them of much use.

I agree. Hope this help.

Okay, so I [very belatedly] nobbled the “Apple petition plan” by finally remembering this exact same plan had already been proposed and attempted before, and made exactly as much of a forgotten fool of itself as I could predict it would. Simply because none of those involve ever paused to ask What do I need to do in order for my goals to be successful?

Honestly, it was a mercy Apple never even noticed that earlier silly, self-important, self-indulgence. If they had, their only reaction might have been “Oh, huh, AppleScript? Yeah, we totally forgot all about that.” and then, upon noticing, that in fact the only positive growth markets for AppleScript technologies over the last 10 years are white-hat and black-hat Mac security hackers respectively.

AppleScript is damage, a still barely-tapped liability just waiting to happen, that exists in macOS today only because Apple has not yet had sufficient motive to do the work to take it out.

Mac scripters thought the same about Python and Ruby, also stable stalwarts of Mac OS X for the last 20 years. Each 100× more popular than AppleScript. Both gone now.

There are more Mac Sysadmins in the world than there are Mac AppleScripters. Ask those Sysadmins how they feel about Python’s summary removal. Then ask them precisely how many f***s Apple gives for their feelings.

Apple has zero obligation to keep AppleScript in macOS. And, at this point, a negative obligation to invest in it.

And since I missed @sawz post at the time, let’s dissect it now. Because learning what does—and doesn’t—motivate Apple to do things is the first small step towards getting what we want from it, by making what we want compellingly align with what Apple itself wants, thereby giving them motive to make it so.

(Emphasis mine.) Nonsense. Any product can be assigned a dollar value. And if you assign it a revenue of $0 (because you lack the rigor, creativity, etc to come up with a positive figure), that still leaves an expenditure of significantly greater $0, which means that product is costing money just to keep around, without generating any money to actually justify doing so.

Failure to produce those hard numbers on demand is a surefire method to get your product canned. No matter how good a company’s tech is, the moment it doesn’t put food on its table, it isn’t doing its job. A product has one job. That job is putting food on its owner’s table. Not whatever it is that you, their customer, may fancy the product is for. That is orthogonal to Apple’s interest. Far better products than AppleScript have died at Apple for not doing their job well enough. And I don’t mean gone gently into that good night, I mean the Full Mary Queen of Scots. Ask Apple’s many Aperture fans how this works.

All this is Business 101 stuff. Anyone who doesn’t understand basic business principles can sit down now, because you have nothing of value to Apple to add. Yes, we know AppleScript is useful to you and you will miss it when it is gone. But AppleScript is useless to Apple and they won’t miss it at all.

Oh, my sweet summer child. Apple is not in the business of making systems that are interesting and usable. Apple is in the business of making money. That’s it. Therefore, if you cannot convincingly demonstrate to Apple how AppleScript makes Apple at least $1M a day, Apple won’t even notice you enough to laugh you out their room. That’s because Apple makes $1BN a day. $1M revenue isn’t profit; it’s liability.

And please don’t start the usual nonsense that since Apple now has giant pots of money they can totally afford to invest it in $pet_project now. That is not how business works. At all. Apple didn’t get to making $1BN a day by throwing half their money away on futile, indulgent, indigent causes. They did it by looking hard at what they’re spending their money on today and asking: are we getting value for our buck?

Spending money without knowing what that expenditure is earning in return is a surefire method to go bankrupt. Early 1990s Apple did this: invested billions in all manner of awesome new technologies, and not a penny was earned back by any of them. Taligent, Dylan, OpenDoc, … the list is long. Hell, OpenDoc is what essentially killed AppleScript before AS was even out of its crib, before proceeding to unalive itself too. (Read Dr William Cook’s HOPL3 History of AppleScript.) Steve Jobs 2.0 immediately, rightly, axed every single one, and he would’ve axed AppleScript too had it not been for one Cal Simone.

If a product is unprofitable, or even if it’s moderately profitable but Apple could make loads more profit spending that money on something else, killing that product and redirecting their cashflow into something else that does provide significant returns is the ONLY correct business decision to take.

It is negligent of company directors not to do this. They are legally obligated to do what’s in the best interest of the company (and thus its shareholders), not what’s in the best interest of its customers (or, even worse, a miniscule fraction of customers), nor what’s in best interest of the directors themselves. Plenty of directors will do so anyway, of course, human nature being what it is. But you cannot propose that behavior as a valid argument: in doing so you are demanding the Apple directors should be incompetent at doing their jobs. Did I mention being laughed out the room? There you go.

To all practical purposes, yes, since Microsoft is the only other vendor on the planet to offer a consumer-level OS. But that’s irrelevant. Even if there were a dozen such vendors to choose from, Apple still could not dare to do it: because whoever they ceded their App development platform to would instantly possess the master key to Apple’s entire kingdom.

Oh good lord. Computer geeks are the biggest bunch of know-everythings who know nothing about anything except how to turn it off and on again.

Apple cannot “move to Linux” for a development platform. Linux is GPL 2; the GPL license is explicitly designed to be viral, to infect (benignly but absolutely) all code it comes into contact with in order to make that code become GPL too. That is the GPL’s entire purpose. And, in part thanks to Linus’s choice of the GPL license, Linux is a fine and empowering platform for many categories of customers; which is why, for example, much of the global internet runs on Linux today.

(Contrast BSD, which has an extremely liberal license that is fully compatible with Apple’s requirements. GPL Linux destroyed BSD in the marketplace.)

Apple is *not one of those customers. Of course, Apple use Linux servers themselves, as host to iCloud and all their other internet-based services. But Apple can never adopt Linux as their public App development platform.

First: because its GPL license would force them to release a very large part of their iOS codebase; the entanglements are impossible to avoid.

Second: because Xcode is only one essential App development tool out of many. To be of any practical use, the App development must be able to run at least some of those other tools too. This may be simply summarized as: “Will it run Adobe Photoshop?” If the answer is no, sit down already.

Complete rank nonsense. The Mac platform can be a $100M/day loss leader and Apple will still support it (albeit under huge internal business protest). The Mac platform is what makes the $1BN iPhone platform possible. No Mac? No iPhone App Store. No iPhone Apps, no iPhone. It is that simple.

Anyone who still cannot see any of this, please sit down. For your own safety, as much as my sanity.

I am telling you all of this because I personally can put a precise dollar price on not understanding this stuff:


That is how much money I personally lost when I failed to differentiate between building and using a technology, and building and using a technology business.

You imagine what losing $200,000 of your own money would do to you and your family. (Damn near killed me. Fortunately, I’ve had plenty practice.) Yet you presume to tell Apple how to spend theirs? Hubris does not begin to cover it!

The business of tech is why I have huge respect for ISVs like Mark, who chug away quietly year on year, reliably (if not necessarily easily) putting food onto their tables and roofs over their heads. That right there is a far, far, far greater achievement than inventing cool tech loved by you and your chums.

I have zero respect—negative respect—for pompous preening self-important geeks who think that they are not only qualified but entitled to tell a global business behemoth like Apple what it should do. Get Out.

There is a very basic principle to successful business, one I did not grasp until already too late:

Fire Your Own Customers.


  • Customers who don’t pay their bills on time? Sack ’em!

  • Customers who are needy and demanding of you, who suck up lots of resources without generating far greater returns? Give ’em the boot!

  • Customers who provide steady if modest returns for your investment? The moment you secure more profitable customers, replace ’em too!

That’s how business works. Until and unless y’all learn that game, and how to play it effectively, you don’t have a seat at the table, you don’t deserve a seat at the table, and—most critically—you never will.

Ray Kroc once said:

“The definition of salesmanship is the gentle art of letting the customer have it your way.”

Ray Kroc was a sales genius; the Steve Jobs of his day.

Pay attention to what these people are really teaching you; instead of what you want to hear. For as long as you listen with your silly, cosy, nerd-colored spectacles, you are as deaf as a post and twice as dumb.

Kroc, Jobs, Rockefeller, Hearst, Bezos, Musk, etc. each had his own vision of how our world should look and feel, and each one willed his world into existence through unceasing dispassionate learning and sheer unrelenting graft.

(And yes, I do hate it’s so frequently “his”. But even the nerd from Barbados is a piker in their class. So it goes. Baby steps.)

Huffing and puffing about how all of those men are also giant a-holes is irrelevant. They succeeded. Sticking them on pedestals and saying “They were truly exceptional giants; no ordinary person could ever have done the same.” Ray Kroc made his living for 30 years, out on the road, selling paper cups. Ray Kroc was 52 when he launched his first McDonalds franchise. When he died, he was personally worth $500M. McDonalds revenue is $20BN/yr; that’s as big as Adobe. Steve Jobs started in a garage.

Y’all want to nerd out? That’s terrific, more power to you! You know what you want out of life, so go do it!

But don’t even presume to think you can ever get off telling AAPL what they need to do. You have not earned it; you most likely never will. Go sit at the small table, with Steve Wozniak and Seymour Papert, Alan Kay and the McDonald brothers themselves, and be contented there with all that you have. Because that is your rightful place in the world; not because Apple decreed it but because you chose it.

For those who want—demand—better, and are willing to get over themselves, roll up your sleeves and be ready to work like a dog to achieve what it is you wish for. And not only work really hard, but repeatedly fail, learn by your errors, and try again; until either you finally give up or, just possibly, succeed at last.

I am working to draw up a [hopefully] viable plan for that. Later, folks.

1 Like

I think you’re 100% wrong as well as 100% irrelevant. The title of the post has to do with a petition to Apple for improvement of AppleScript from someone asking to reply “I agree” (if they do) and add (if they want) a comment of their own. In short, it means, or so I think, that if you don’t agree, you read on and move on. Instead, you wrote not one long post but many in which you went large and away about people you worked with and, fittingly, were incompetent (or implied so) and got fired, you along as well. That’s typical workplace story. And this (bitter) experience would be enough to have enlightened you so much that you feel entitled to be rude with people in this forum that wish for a better AppleScript? Enlightened and entitled by what ? By the fact that you realized that Apple Co. was taking a good care of its bottom line? Hey, c’mon.

BTW, I agree because it’s convenient, useful and fun for may purposes. And it’s not that buggy. It’s seems there’s always a work-around for any problem.


@TMartin: Respectfully, as I know I buried the lede something awful first time around (My Bad for being a slow thinker):

[quoth me] While I’m lecturing you on the importance of doing your due diligence, yada-yada, it occurred to me that I had not; as if I had I could’ve saved you all the trouble of penning that second post. Top search result:

applescript petition - Google Search

Read the date and read the signee count.

There is no “petition”. It was already tried back in 2016, the year that Mac Automation fell, and nothing happened at all. It won’t work. It can’t work. If it can’t muster 1 million signatures—the minimum number before Apple will even notice—don’t start.

A “petition” is just a tiny handful of upset computer nerds being egotistically whiny, believing that Apple must pay more attention to them, just because. That is not effecting Change, that is virtue-signalling for entitled clueless twits to self-congratulate themselves while the ship sinks all around them.

Apple does not care what you think.

Apple cares about Markets.

Not technologies, not products, not you. Markets.

Y’all are techies, so you automatically view every problem as a tech problem, in need of a tech solution. This is why you fail. It’s why I failed before: I made the exact same mistakes you now do.

At least I learn (finally) from my errors. Can you?

The reason I keep making this discussion to be about people, not about tech, is because ALL of this is a People Problem.

  1. People made the tech.

  2. People failed to market the tech to others.

  3. The tech failed. Not as a technology. As a Market.

I’m thick as a brick and even I grok this principle. What’s everyone else’s excuse?

If you wish to save Mac Automation, you need to step outside your tech comfort zone and figure out the answer to this question:

How can we sell Mac Automation to Apple?

Specifically, to the people inside Apple. Who have already written it off.

You genuinely care about Mac Automation, all 10 of you? Brilliant! You genuinely intend to save it and not just posture and huff?

Get in line. I have come far closer to saving Mac Automation more than once than any of you ever have! And failed, because I did not educate myself about what I did not know. I offer you all that experience to learn from (a quarter million dollars worth), at no cost to yourselves, to give you the best chance of success yourselves. Take the compliment, and then answer this too:

How can you possibly make 10 people do more productive work than 1 million signatures, and in under 6 months too?

Apologetics for teh techy. But I am here to be kind, not nice, and “Well that’s like, just your opinion, man” is not a competent response. It’s embarrassing.

A petition won’t work. A Sales Plan just might.

This stuff is not hard. It is trivial math:

There are 8BN people on this planet today. 1BN of them carry iPhones in their pockets. 3BN carry Android, which is slowly and surely stealing Apple’s lunch.

If you can come up with a sales pitch for Apple Automation that promises to make even 1% of that 1BN adore their iPhones even more than before, and perhaps even steal back some of the 3BN billion lost to Android, Apple won’t just be eating out of your hand—they’ll be ripping your arm off to have it!

(And if this exciting new plan also just happens to rescue our poor, forgotten, beloved Mac Automation from oblivion, and remake it as a foundation for cross-platform Apple Automation 3.0, well, isn’t that just a bit of coincidental good luck?)

And that is where you are wrong. Applescript is a technology within a technology (OSX) that is within a product, Mac computers…that is what Apple markets and sells, Mac computers.