Wednesday, January 11, 2017

App Extensions Are Not a Replacement for User Automation

Sal Saghoian (via Federico Viticci, Todd Ditchendorf):

Let’s imagine that Apple decided to combine their engineering resources to form app teams that delivered both iOS and macOS versions of applications.

In such a scenario it may seem logical to retain application features common to both platforms and to remove those that were perceived to require extra resources. Certainly Automation would be something examined in that regard, and the idea might be posited that: “App Extensions are equivalent to, or could be a replacement for, User Automation in macOS.” And by User Automation, I’m referring to Apple Event scripting, Automator, Services, the UNIX command line utilities, etc.

This is pretty much what I feared was Apple’s thinking.

Based upon the information presented in this overview, it is clear that App Extensions do not provide the same abilities and functionality as the User Automation technologies of macOS, and objectively should not be considered a comparable replacement for them.

Previously: Tell Us Your Mac Automation Stories, Thank You, Sal.

Update (2017-01-12): John Gruber:

I’d prefer to see iOS gain serious automation capabilities — even if it’s an altogether new technology. But I’m dreadfully afraid of a future where MacOS is devolved to iOS’s state, with no supported automation technologies.

2 Comments RSS · Twitter

"This is pretty much what I feared was Apple’s thinking."

But isn't Apple's convenience in converging iOS and macOS code bases a small price to pay for losing something that merely makes pro and prosumer users much, much more productive?

It's similar to the recent PDF bugs. Sure it sucks if you use PDF's on the Mac, but just think of how much easier it all makes things for Apple!

something that merely makes a small percentage of pro and prosumer users much, much more productive when it isn't just shitting on them instead


I have part of a plan. It may only be 12% of a plan, but that's still 12% more than Apple in general or Sal Soghoian in particular has been able to come up with in the last 10 years. They're fucking useless, and quite frankly the AppleScript community hasn't done any better either.

But first things first... How about MY Automation story?

I have now been scripting and automating for 16 years—the last 8 professionally—and have barely even begun to realize the true full potential of text-driven computing, and what it could/should/would be doing—not just for me but for every woman, man, and child on this entire planet!

When I was a child, an 8-bit microcomputer that did almost nothing was a huge middle-class first-world indulgence, a tiny glimpse of what potential might be hidden in those even tinier silly-con chips, to someday change the entire world. Today humanity owns TWO BILLION supercomputers-in-pockets alone, and doesn't even think about what that unimaginable capacity for true personal computing that represents.

Which is really lucky for the global computing industry, cos the moment that penny does drop, and this soon-to-be 2.2Bn realize just how massively, unforgivably, a tiny tyrany of tech nerds and salesmen have used and screwed them in order to get rich and powerful themselves in return for their shiny glass beads with infinitely indentured strings attached...

Ah, but now you got me Revolutionary dander up, and I'm already looking towards my hoped-for future before I've even answered about my current past. So here it is:


Over the last 3 years I have very quietly been building up and beginning to field-test the most advanced Apple-event-based automation system on the planet; a unique, one-of-a-kind technology solution that actually does what it says on a tin, solving a problem that many large established ridiculously resource-rich industry vendors have spent the last 20 years repeatedly trying—and failing—to crack.

For context: we're talking here about a $1Tn global industry, packaging production. Just look around you: every bottle, every box, every tag in every shop and retail chain across the developed world; every one of those has labeling that has been assembled on a computer—and right now almost all of that assembling is still being done by manual operators; traditionally in the first-world countries where those products are most marketed, though increasingly moving to the likes China and India as manufacturers and retailers demand more, better, and quicker results year-on-year, as artwork packaging suppliers desperately tries to cut costs and improve productivity every way they can.

Huge industry-standard vendors like Esko have, over the last couple decade, massively and successfully automated every single step in the pre-press production chain... except for one: artwork assembly.


Unsurprisingly, a typical mid-size graphics shop will delighted drop six-figure checks at a hat, to every flashy salesman who knocks at their door declaring that his brand new big-iron artwork automation system will slash their artwork production costs in half across thousands of SKUs per-year, yielding for them $100Ks more in cost savings and quality improvements within the next two years.

And two years of installation, training, and, shop-floor deployments later?

That vast, new, massively expensive artwork automation system isn't generating anything more cost-saving than a new director's business cards. These systems sound amazing on paper, look even more incredible in canned demo, and are an unmitigated disaster in production for anything beyond a tiny sliver of job types, that aren't even the types of jobs that most agencies do. Because every time senior managers desperate to justify their massive up-front time and money investment demand that production staff start using it, the entire business's productivity goes straight through the floor, leaving both artworkers and customers frustrated, furious, and late as, instead of making production more efficient, all these new systems do inject massive new volumes of rigidity and make-work, and, instead of assisting, constantly blocking and frustrating the production staff from getting their work done.

Production rebels against this demonstrably insane diktat, reverting everything quickly to manual before all their customers cancel their contracts and sue them to death for massive breach of service; the obligatory scapegoats are located and blamed; and a couple years later when clients are squeezing costs and upping volume at the next contract renewal, the whole circus starts all over again.


Huge convoluted top-down big-iron artwork automation systems just can't cut it in real-world use. They're 100% inertia, 0% adaptability; claiming to do everything, they end up doing nothing. Whereas small, simple, scrappy, totally agile automation that can freely and incrementally chip away at the overall problem one tiny corner at a time, yielding both small immediate benefits and an increased understanding of what the job really entails and and where the next most easiest saving can be had next.

Sound familiar (albeit at a slightly different scale to the usual iTunes Cleaner and Desktop Broom)? It should.

Small, quick, messy, exploratory, incremental, iterative, cheap; and ultimately successful, precisely because achieving successful real-world everyday automation isn't about Big Plans, Big Systems, Big Experts, Big Money, Big Egos, Big Excuses, Big Fails. It's putting small, simple, quiet tools into the hands of the people who do all these jobs every day—the real domain experts—and allowing those users to grow into those tools as, when, if, and where they find them of use.

The users grow with the tools, the tools grow with the users. Start small, work small, slowly build up, sometimes accummulating small wins, other times new lessons and insights for next time. Automation isn't about replacing humans: it's about giving them superpowers.

It is how AppleScript was supposed to work; it is how the special-purpose automation language and toolset I've developed for this one problem space work. And it is how user automation could in future work in not only macOS, but also iOS and even someday Windows, Android, Linux et-al too.

If the general-purpose end-user language I'm now seeding as my next study project proves it practical to deliver similar opportunities to not just a few thousand artwork operators but the hundreds of millions of everyday personal computing users we have now. Cos there's a reason and timing I've unofficially nicknamed my next end-user language project "SiriScript".

Oh, and I'd absolutely love to be learning and building that new language right now, cos while the prototype isn't even finished yet I'm already pretty damn confident it'll have some amazing legs. But right now I am in Limited Company startup mode with the goal of building a multi-million dollar organization over the next five years, and cashing out at the end of it to go pursue my next grand adventure with financial security for life. Or perhaps one of the two major Esko competitors who've already expressed interest to me could make a cash-down offer I simply can't resist—in which case I can pocket an easy quarter-mil, this year, and use that to bootstrap my Next Big Thing just when the time to strike is right.

So who knows where my Automation story is going to go next? The next twelve months is going to be one hell of a scary, incredible, open-ended ride for me. I may win everything, I may lose everything; one thing's for sure, I'll definitely be learning faster and harder than ever before, and having some eye-opening experiences along the way.


Oh, and One More Thing: my own story would not even have begun without the wonder and pain of AppleScript and Mac Automation's discovery. I've long since outgrown and superceded it with my own far more polished and capable technologies (and once I start building a Windows version I'll no longer be tied to Apple events either). So the only other question worth asking today is:

With so much unimaginable potential to change users lives in infinite ways, both great and humble, why over all of 20 years has Apple's Automation only produced one of me, and only a few thousand others, instead of producing THOUSANDS of me and MILLIONS more? The technology's there, so why has Apple so utterly failed to build the Products and Markets on top of it needed to generate all that return?

Leave a Comment