Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

What Apple’s Purchase of Workflow Means for Automation

When I wrote “Workflow Is the Next Step for iOS Automation” (21 December 2014), I had no idea how literal that title would prove to be. Apple has now purchased Workflow 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 “Apple Announces 2015 Design Award Winners,” 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, Workflow is now available for free. 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 points out 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 “Understanding Apple’s Marginalization of the Mac,” 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 helping the Omni Group with automation in their apps.

Apple’s unceremonious elimination of Soghoian caused much concern in the Mac community, despite reassurances from Craig Federighi, 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 “73 Mac Automation Stories from TidBITS Readers” (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 “Is Apple Planning to Replace Automation with App Extensions?,” 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, Editorial, and Pythonista 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 “OS X Hidden Treasures: Services,” 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 “Apple’s Swift Programming Language Is Now Open Source,” 3 December 2015) and build the friendly Swift Playgrounds iPad app to help kids learn how to use it (see “Playing Around with Swift on the iPad,” 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 “Using Swift as a Scripting Language” (6 August 2014), although we haven’t heard much about Swift’s use as a scripting language since.

Of course, Swift can’t control Mac or iOS apps yet — it would need something like JavaScript for Automation (JXA), which is a set of special libraries that lets scripters use JavaScript instead of AppleScript for interapplication communication.

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.

 

PDFpen and PDFpenPro 9 add 100+ enhancements to improve your PDF
editing experience, with annotations, Tables of Contents, and more
export options. For PDF reviewing, editing, signing, redacting and
exporting, PDFpen has you covered. <http://smle.us/pdfpen9-tb>
 

Comments about What Apple’s Purchase of Workflow Means for Automation
(Comments are closed.)

Replacing AppleScript with a full-blown OO language is a bad idea. My scripts don't need classes, inheritance, object reuse, or data hiding. And requiring me to learn a completely obfuscated OO syntax and the complex rules that accompany OO development & debugging when I don't write scripts every day is simply user-hostile. I have no interest in "mov[ing] on to full-fledged app development without having to learn another language," and so, I disagree that "By bridging the gap between scripters and developers, Apple could expand its ecosystem." If Apple were to go down this path, it would be just another way of making Macs harder to use. AppleScript has its flaws, all right, but it is more accessible than Swift. But, for the reasons & assumptions you state, it is inevitable that one day AppleScript Editor, then osascript, will be discarded for Swift. (PS: I am a former Intel assembly language/C/VisualBasic system & application arch/dev who has always hated OO for the reasons above.)
Adam Engst  An apple icon for a TidBITS Staffer 2017-03-28 19:14
Our hope is that AppleScript wouldn't disappear even if Swift were to become Apple's focus.

I don't have a sense of whether Swift's OO features would get in the way when used for scripting. Did you see

http://www.strathweb.com/2014/06/using-swift-general-purpose-scripting-language/
@Adam: AppleScript is well into the long tail of its lifecycle. It should've been replaced years ago, but with a much better *end-user* language.

The real problem isn't the death of the AppleScript language, it's that the [now-ex] Automation team's repeated failure to make *App Automation* a success in ObjC/Python/Ruby/JavaScript/Swift/etc too, it has only thousands of users instead of millions, thus Apple has NO reason to fix, improve, or bother keeping the underlying Apple event IPC infrastructure and Apple Event Object Model.

It's that IPC infrastructure and the thousands of AEOM-aware apps that support it (and the many more that could) which is the incredibly valuable bit, not the language(s) that use it. The irony is that the Apple Event Object Model's very-high-level QUERY-DRIVEN interface should be the perfect complement to Apple's new QUERY-ISSUING UI, Siri! But if Apple's ostensible Automation Product Manager failed to see and sell that vision, what chance anyone else will?
Swift and AppleScript are both awful languages in their own rights. Swift is just C++ with rubberized corners. AppleScript to its credit was a genuine attempt to try something new; unfortunately its own excessive cleverness backfires something terrible. (BTW, given your background, surprised you don't prefer Perl or Bash, or even Tcl, for scripting?)

A good end-user [AND pro-user] scripting language would be a modern Logo successor. Frankly all Algol/C-descended languages suck: "Ugg bang rock!" is the absolute limit of their expressiveness, and even then you're being eaten by raptors.
(And yes, OOP is overrated and overapplied, though both Swift and AS support it and neither requires it unless you're writing, say, Cocoa apps. But if you ever used JavaScript or Smalltalk, you'd know the way that C* langs "do OO" is an abomination that hardly resembles the original concept. Blame the state of modern "CS education".)
"Of course, Swift can’t control Mac or iOS apps yet"

This is wrong: Swift *can* control Mac Apps via 1. macOS's crippled crappy ScriptingBridge framework (when it works, though it's even more awful in Swift than it is in ObjC), or 2. via the SwiftAutomation framework (https://bitbucket.org/hhas/swiftae/) I wrote a couple years ago which does provide *AppleScript-quality* application scripting support. (Apple previously considered appscript, SwiftAutomation's predecessor, for 10.5 but alas its internal bureaucracy nixed that.)

I even offered Sal SwiftAutomation for free back in 2015 cos I knew how important this was, and the idiot blew me off with incredibly asinine NotInventedHere BS. THAT is the reason why Swift doesn't provide AppleScript-quality application scripting support as standard; why Mac Automation has totally failed to win hundreds of thousands of enthusiastic new App Automation users AND developers; and why Sal Soghoian (rightly) doesn't have a job at Apple any more.