Sal Soghoian, former Automation lead at Apple, writing for MacStories:
Here's a thought experiment. Let's imagine that Apple decided to combine their engineering resources to form app teams that delivered both iOS and macOS versions of applications.
This, based on my understanding, is exactly what's been happening in the software engineering division recently. The thinking behind it, though, is nothing new. For a long time Apple's had a CoreOS group, among others, that worked on the underlying technologies central to both iOS and macOS. They're built on the same foundation, after all, so continuing to build out that foundation in as unified a way as possible simply makes sense.
Likewise, new technologies have been designed for both from the start. Swift, the programming language Apple debuted a few years ago, is one example. It's how developers will code for macOS and iOS in the future. Apple File System (APFS), announced last year, is the same. It'll eventually run everything from Watch to Mac.
Now, the same is true at the built-in app level. Getting the original iPhone and iPad to ship required enormous efforts, dedicated teams, and a ton of resource reallocation. Over the years, that resulted in some disparities. A few years ago Apple brought all if it back together under Craig Federighi, and now that same strategy is being applied to apps. Safari will be Safari at the code level. Mail will be Mail, Messages will be Messages, Calendar to be Calendar... you get the idea.
Having different code bases behind apps with the same name was never meant to be what differentiated iPhone and iPad from Mac. Having interfaces that best served the interaction models of each platform was. That's what end-users experience — the interface and interaction model. Everything else is pipes and plumbing hidden away beneath. The more of that stuff that's the same, the better. It improves compatibility and efficiency.
The iPhone and iPad remain multitouch devices optimized for direct manipulation, a hyper-accessible and mobile reimagining of the computer for the modern, mainstream world. Mac remains a mouse and pointer system — okay, now with Touch Bar! — and a traditional computer for those tasks that still require one.
Ideally, iOS will continue to benefit from the deep foundations of macOS, and macOS will continue to benefit from the innovations of iOS. Unfortunately, we don't always get ideals. Sometimes, short term, we'll get subsets that'll work on both. Long term, we'll get whatever, philosophically, Apple chooses to add back in and evolve further.
I'll spare you another regurgitation of iWork here.
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.
I continue to believe that extensibility, introduced in iOS 8, is one of the most important developments in the history of the platform. It enables interoperability while maintaining privacy and security. Through Share Sheet and other manifestations, extensibility greatly accelerates the perceptive speed of the system and makes everything far more convenient. But extensibility is not automation.
Workflow is an iOS app that shows just how powerful "real" automation can be on iOS. It can also be accessed via extensibility. But that doesn't make extensibility itself a automator.
As much as I'd hate to see Workflow "Sherlocked" — copied at the system-level — by Apple, I'd love a base form of built-in automation on iOS. On the surface it's an incredibly niche feature but iOS has a way of making the niche more accessible to the mainstream.
Perhaps it is time for Apple and all of us to think of User Automation and App Extensions in terms of "AND" instead of "OR." To embrace the development of a new cross-platform automation architecture, maybe called "AutomationKit," that would incorporate the "everyman openness" of User Automation with the focused abilities of developer-created plugins. App Extensions could become the new macOS System Services, and Automator could save workflows as Extensions with access to the Share Menu and new "non-selection" extension points. And AutomationKit could even include an Apple Event bridge so that it would work with the existing macOS automation tools.
I sometimes think Apple is worried about making iOS too complex — making it too much like macOS — and so they take a long time figuring out features like copy and paste or drag and drop. I understand the concern but, in my mind, iPad and iPhone should be allowed to evolve as though the Mac didn't exist. (And vice-versa.) The only goal should be to be the best. Like Phil Schiller has said (paraphrase) — iPad should be so good it puts pressure on the Mac and Mac should be so good it puts pressure back on iPad.
Having one team responsible for Safari, Mail, Messages, etc. on both platforms is great and hopefully means that, going forward, "Sent with Fireworks" is something I'll never have to see on my Mac again. But it's also something I hope, eventually, elevates the built-in apps on both platforms in a way disparate teams never could.
Check out the rest of Sal's article and let me know what you think.
Update: I clarified some of the language above so my rapid change of topic wouldn't cause so much whiplash.
