When I wrote “” (21 December 2014), I had no idea how literal that title would prove to be. Apple has now  and the team behind it.
As you may recall, the Apple Design Award-winning Workflow is an automation app for iOS in the same vein as Automator on the Mac (see “,” 10 June 2015). You can use it to perform actions in supported apps automatically. For instance, you can use Workflow to send your estimated time of arrival to a friend, upload photos, or shorten a URL.
Apple usually pulls acquired apps from the App Store, but not this time. Instead,. Unfortunately, Apple has dropped support within Workflow for Google Chrome, Google Maps, LINE, Pocket, Telegram, and Uber, and Workflow Gallery submissions are no longer being accepted. Developer Marco Arment  that may be more because of legal issues than any particular strategy.
Recent Automation News -- This acquisition is a plot twist in Apple’s ongoing automation saga. In November 2016, Apple eliminated the position of Product Manager of Automation Technologies (see “,” 21 November 2016). The man who filled that position for two decades was Sal Soghoian, a legend in the Apple power user community who championed technologies such as AppleScript and Automator. Among other consulting projects, Sal is now  with automation in their apps.
Apple’s unceremonious elimination of Soghoian caused much concern in the Mac community,, Apple’s senior vice president of software engineering. It certainly did nothing to alleviate concerns that Apple no longer cares about professional users. Many of you made your concerns heard loud and clear in “ ” (19 January 2017), which collected amazing stories of how you’ve used the Mac’s automation technologies. And yes, Adam did send the collection to Craig Federighi and Tim Cook. No, he didn’t hear back.
Our curiosity was piqued further when Soghoian publicly cautioned Apple to not replace existing automation tools with app extensions (see “,” 12 January 2017).
So what does Apple’s purchase of Workflow mean for Apple’s professional and power users? Overall, the acquisition seems like a positive sign, but big questions remain. I don’t want to speculate about the future of Apple automation too broadly, but we can make some inferences based on what we know about the company.
Apple Sees the iPad as the Future -- Despite declining sales growth, Apple appears committed to the iPad as the future of computing, releasing products like the iPad Pro, accessories like the Apple Pencil and Smart Keyboard, and iPad-only apps like Swift Playgrounds.
One big missing puzzle piece for the iPad’s professional future is system-wide automation. Tools like Workflow,, and  have existed for years on the iPad, but they lack the system integration, ease-of-use, and capabilities of Automator and AppleScript on the Mac.
If Workflow were integrated into iOS with a system for third-party app integration, it could become a powerful, easy-to-use automation tool. However, Apple would have to build out the automation underpinnings in iOS before that could happen. Workflow currently uses a kludgy system called x-callback-url, developed by Greg Pierce and Marco Arment. It was a clever workaround when they introduced it in 2010, taking advantage of iOS’s URL schemes to let apps communicate with each other, but Apple could do much better.
In a Twitter conversation with Pierce, Arment said, “The crazy thing is that URL-scheme bouncing between apps is still necessary for so many useful things on iOS. I always assumed that it’d be a few-years-long hack until iOS caught up and gave us something better. Maybe now it will.”
Sal Soghoian has pointed out the difference between app extensions and true user automation; the question is if Apple sees app extensions as being sufficient for Workflow’s underpinnings. That would be better than nothing, of course, but app extensions are more akin to what Services provide in macOS (if you don’t remember Services, check out “,” 5 February 2016).
One big question about an automation scheme based on app extensions and a Workflow front end is just how powerful it could be. Could it compare to what can be achieved with Automator and AppleScript on the Mac, or would it be closer to Workflow’s current limits?
For a far more capable system, Apple could create something in iOS like the Apple event system that enables apps to communicate with one another on the Mac. In an ideal scenario for those who support Mac automation, Apple would bring actual Apple events to iOS. Then a developer would have to build on that by creating a terminology — a scripting dictionary containing commands and objects — and having the app listen for and respond to incoming Apple events. On the Mac, AppleScript is one of the main ways that users can interact with apps via Apple events, but I can’t see Apple porting AppleScript to iOS.
The challenge Apple events face in iOS is the tension between scriptability and security — the kinds of hooks that are necessary for scriptability can be used as an attack vector unless the system has been designed carefully to limit that. The Apple event system on the Mac treads that line by operating at the user level; to avoid being exploited, any iOS approach would likely have to be similarly or even more restrictive.
Apple Sees Swift as the One Language to Rule Them All -- Along with the iPad, Apple sees Swift as the future of development, going so far as to open-source it (see “,” 3 December 2015) and build the friendly Swift Playgrounds iPad app to help kids learn how to use it (see “ ,” 13 June 2016).
Beyond its role in developing traditional apps, what’s interesting about Swift is that it can be used as a scripting language. Developer Filip W proved this concept years ago — see “” (6 August 2014), although we haven’t heard much about Swift’s use as a scripting language since.
I bet Apple would like to have Swift become the preferred scripting language across all its platforms. Then, people could start with scripting and move on to full-fledged app development without having to learn another language. By bridging the gap between scripters and developers, Apple could expand its ecosystem.
Apple Wants macOS and iOS to Share Common Foundations -- Since the beginning, iOS has shared a common core with macOS. Over time, the two platforms have traded capabilities — usually new features developed on iOS going “back to the Mac.” In the case of scripting, it would make more sense for Apple to move the Apple event model to iOS, likely in a restricted way, than to come up with something completely new for iOS that would then need to be evangelized to all Mac developers in the other direction.
The question is how closely the iOS system will match up with the Apple events that Mac automation relies on now. If Apple were to start supporting a subset of Apple events in iOS, giving users access in iOS via Workflow and Swift, it would be easy to imagine Workflow coming to the Mac to replace or supplement Automator (Swift is obviously already available for Mac users).
It seems likely that Apple will announce something related to Workflow and iOS automation at WWDC in June 2017, with an eye toward it shipping in some form in iOS 11 in September. Or, if my excitement is getting the better of me, it might all have to wait until iOS 12 in 2018.
Perhaps Apple will split the difference, and do what it did with Siri. At first, Siri could perform actions only with built-in iOS functionality and Apple apps. With iOS 10, though, Apple opened Siri up to a few types of apps, including apps for messaging, ride booking, payments, VoIP calling, workouts, and CarPlay. iOS automation might similarly be limited to a small subset of what’s possible on the Mac today, enabling Apple to feel out the security implications before making it more capable in future releases.
How that would affect Workflow coming to the Mac is hard to guess. It might come with macOS 10.13 this September, or it may be an iOS-only feature for a year, and show its face on the Mac with macOS 10.14 in 2018.
Beyond any speculation, we can see one thing for sure from Apple’s acquisition of Workflow: the company hasn’t lost interest in automation, which is good news. But the devil is in the details, especially in a system that has to balance user capabilities against security.