Merging macOS and iOS at the app level

Don’t worry about iOS being too Mac-like. Imagine a world where there is no Mac, and then let it be everything it can be.

Rene Ritchie has been covering Apple and the personal technology industry for almost a decade. Editorial director for Mobile Nations, analyst for iMore, video and podcast host, you can follow him on Snapchat, Instagram, or Twitter @reneritchie.

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 is, based on my understanding, exactly what’s been happening. For a while now Apple’s had a CoreOS group, among others, that worked on the underlying technologies central to both iOS and macOS. Now the same is increasingly true at the app level. And it makes a lot of sense. What differentiates the Mac from iPhone or iPad isn’t the inner workings of Safari or Mail, Messages or FaceTime, but the interface layer that we use to interact with them.

Those parts will stay distinct — the mouse and pointer from multi-touch — but the the code bases will gain efficiencies. In an ideal world, that would include the modernizations iOS enjoys by virtue of being fresher starts, and the functionality macOS has developed over the years.

Unfortunately, we don’t live in an ideal world. So, initially, we’ll get a subset of features that work on both. Long term, we’ll get whatever, philosophically, Apple chooses to add back in and evolve further.

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 platform’s history. It enables interoperability while maintaining privacy and security. They greatly accelerate the perceptive speed of the system and they’re incredibly convenient, but they’re not automation.

Workflow is an iOS app that enables an amazing amount of automation. 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 nice more mainstream friendly. Make it something that, if and when discovered, sets off a lightbulb and begins a lifetime of delight.

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.

For me it comes down to this: Don’t worry about iOS becoming too Mac-like. Imagine a world where there is no Mac and let iOS be the best damn mainstream computing platform possible in that world.

Check out the rest of Sal’s article and let me know what you think.


iMore – The #1 iPhone, iPad, and iPod touch blog