I’ve loved Workflow since the first beta I was sent in August 2014. Workflow is my most-used iOS app of all time, and, in many ways, it is the reason my iPad Pro can be my primary computer. I’ve written thousands of words on the app and have created hundreds of workflows for myself and others over the course of two years.

I referred to Workflow as Minecraft for iOS productivity and the modern bicycle for the mind in the past. I stand by those analogies. There’s nothing else on iOS like Workflow, which deftly walked the fine line between absurd innovation and Apple rejections with a bold vision and technical prowess. Workflow embraced the limitations of iOS and turned them into strengths, resulting in a power-user app with no competition. After two years, no app gets remotely close to the automation features shipped by the Workflow team.

And now Workflow and its creators are going to be part of Apple and the company’s bigger (and more secretive) plans.

Somewhere in the back of my mind, I had always kept the possibility that Workflow could eventually be discontinued or acquired. In a somewhat prescient move, Stephen quizzed me on this problem a few weeks ago on Connected. My “worst-case scenario” of Workflow going away became the new reality of iOS automation last week.

Workflow as an app is an incredibly good acquisition for Apple, but there’s a deeper subtext here. Workflow represents a movement from a large number of users who enjoy working from iOS devices so much, they want to optimize the experience as much as possible. Workflow’s goal wasn’t to merely provide a capable alternative to the Mac’s AppleScript and Automator; Workflow wanted to eclipse legacy scripting environments and usher iOS users into a new era of mobile automation. There’s the Workflow app and team – technically impressive and absolutely talented – and there’s the bigger theme behind Workflow.

But what has Apple acquired, exactly? Under Apple’s control, can Workflow continue on its mission to make automation accessible for everyone? If Apple sees a future in iOS automation powered by Workflow, what else can be done with a virtually infinite budget and stronger ties to the platform? And what does this acquisition mean for Apple’s commitment to pro users on iOS?

I’ve been mulling over these questions for the past week. I don’t have any absolute answers at this point, but, after building workflows and following the app’s development for two years, I have some ideas on where Workflow can go next.

Below, you’ll find two possible scenarios for Workflow as an Apple app, as well as some considerations on how Apple could evolve Workflow into a native feature of iOS devices and a new developer platform.

Worst Option: Workflow Is Abandoned Without a Replacement

If you follow tech startup news, you’d be hard-pressed to get excited about your favorite app shutting down because its founders are going to work for a bigger company. Most of these announcements follow the same playbook:

• TechCrunch/other publication breaks the acquisition news;
• Bigger company confirms the deal;
• Startup confirms the acquisition in a Medium post, says the team is “excited to join Company” and “continue on their vision” for Product;
• Casey Newton writes a fantastic “behind the scenes” obituary;
• Product receives no updates for 6-12 months. If it is updated, changes focus on removal of existing features or basic bug fixes;
• Product is unceremoniously discontinued. A shorter, less inspired Medium post mentions the team’s “bigger mission that now goes beyond Product”.

In startup lingo, these acquisitions are referred to as “acqui-hires”: a bigger company hires a startup’s talent by buying their Product, but the purchase is only skin-deep. This is an over-simplification, but, in most cases, the corporation is only interested in the people who built Product and have no motivation whatsoever in continuing to invest in it, its customers, and legacy tech. If Product stays around for a few months, it’s because the startup managed to convince the new owners to enable a grace period out of respect for existing users. Both parties are acting in their best interests, but Company has the upper hand. The only constant is customers losing access to the original service sooner or later.

I don’t know if Workflow will follow the same path of most startups acquired by Apple and other large companies, but initial signs are already there. The latest version of Workflow has removed some actions (which might be due to legal reasons) and the curated Workflow Gallery no longer highlights user profiles. The app has been made free, Apple has promised to keep it on the App Store for now (grace period), and the core engineering team has joined Apple.

It’s easy then to imagine the following scenario: Apple has acqui-hired the Workflow team for their talent, but they have no intention of operating Workflow in its current form going forward. The app will live on the App Store for 6-12 months while the team begins working on something else unrelated to a standalone automation product. Sometime later this year or in mid-2018, Apple will remove Workflow from the App Store and links to public workflows shared by users will redirect to a ‘Goodbye’ webpage. Following outrage by the community, Apple will issue a statement citing the “great new technologies” in iOS 11 that obviate the need for Workflow and provide a better solution for everyone. Finally, changes in a build of iOS 11 will introduce compatibility issues in the last, abandoned version of Workflow that will prevent normal usage of the app. With no actual replacement, millions of users will forever lose access to the best automation app ever created for iOS, and new features in iOS 11 won’t be able to compensate for the demise of Workflow.

Following Apple’s acquisition, this is my new worst case scenario for Workflow. While I don’t personally believe in such a dark timeline, it is plausible and it has precedents with hundreds of startup acquisitions and discontinued products that came before Workflow.

I should also mention how Apple’s spotty performance in automation and recent tumult within the organization lend credence to the common belief that Apple doesn’t care about Workflow as a dedicated iOS automation app.

On the Mac side, Automator (the app that inspired Workflow in the first place) has been languishing without major updates for years, while scripting technologies such as AppleScript and JXA have hardly received any attention. Sal Soghoian, former head of Automation Technologies at Apple, left last year and later urged users to be vocal about the need for scripting and automation features. Apple’s recent approach to automation and other pro software features epitomize a company that is focused on consumer products. And automation, sadly, has never been a tentpole feature that could appeal to millions of consumers.

From Apple’s perspective, it would arguably make sense to kill off a product that doesn’t directly contribute to the bottom line of the company, despite the quality of the software and affection from the community.

Best Option: Apple Turns Workflow into a More Powerful, Native iOS Feature

When it comes to high-profile acquisitions of popular iOS apps and services, the modern Apple has a fairly solid track record. The three examples I can think of – Siri, TestFlight, and Beats Music – all blossomed into native successful services that are much better as Apple products today than they could have ever been as third-party additions to the iOS ecosystem. The evolution of Siri is particularly impressive, as it went from a third-party assistant app to an integral part of the entire iOS experience.

Just like abandoning those three services would have destroyed goodwill among existing customers and put Apple at a competitive disadvantage, letting Workflow wither away without a proper replacement would be a deep setback for iOS productivity and send the wrong message to a community of committed users who are embracing iOS devices as post-PC computers.

In a more optimistic outlook, Apple has seen the unparalleled functionality and unique potential of Workflow and convinced the team that the only way to reach the next level of system integration was to have Workflow become part of iOS itself. Similarly to Siri and Beats Music, the vision behind Workflow is ripe for unlimited resources with no restrictions on access to private APIs and system features. Under Apple’s guidance, Workflow could grow into a safer, more integrated, extensible automation service and developer platform unlike anything that has ever been attempted on the Mac before.

Workflow was already reshaping iOS automation; as an Apple app, Workflow could lay the foundation for the future of iOS productivity.

I’ve been thinking about the future of Workflow for a while – ever since I started imagining what “Workflow 2.0” could have been. Apple has a lot of work ahead and I don’t think we’ll see the results of their automation efforts in iOS 11 this year. With no knowledge of the Workflow team’s (or Apple’s) actual plans, I’ve compiled a list of smaller additions and major changes that we could expect from an Apple-made Workflow in the next few years.

Short-Term and Other Obvious Improvements

Bearing in mind that Apple is likely going to rewrite Workflow from scratch, these are some of the less visionary improvements I expect the company to bring to the app.

Workflow Folders and iCloud Sync

Workflow needs better organization for user-created workflows.

While the team has done a remarkable job with the ability to easily reference workflows and a larger collection of icon glyphs, there should be a way to create folders for workflows and control their appearance (with folder icons) and sorting settings. Folder navigation would introduce new challenges¹, but the current single-view model doesn’t scale anymore.

Furthermore, I expect Apple to replace Workflow’s proprietary Workflow Sync service with their own iCloud-based² solution with support for versions and public sharing. While App Store guidelines prohibit third-party apps from syncing executable code between devices³, I suspect Apple’s future Workflow app will eschew such limitations and securely sync your workflows between devices.

A More Flexible Action Extension

Workflow’s customizable action extension is one of the strongest arguments in favor of opening up user automation on iOS. By integrating with any app or system feature that supports the share sheet, Workflow’s extension enables users to create their own (safe) improvements for iOS apps and make their devices work better for them. There’s a lot more to done with the extension, though.

Most notably, Workflow’s extension needs more filters to specify where and when a workflow should be available as an extension. Currently, Workflow supports basic type filters for items passed to the share sheet such as “Safari webpages” or “Files”. In a future version of Workflow, I would like to see filtering capabilities to control, for instance, workflows that should appear as extensions only at a specific website (filter by domain), with a specific file type shared from an app (“any JPEG shared from Photos”), or for email messages that come from a certain sender or that contain a keyword in their subject.

Some of these ideas can be implemented with a series of manual workarounds in the current Workflow app, while others would require direct access to restricted parts of iOS. As an Apple app, Workflow should make it easier to pick workflows for the extension, and it should also allow users to choose from more options previously not available to a third-party app.

New Privileges

Speaking of limitations in the old Workflow, becoming a first-party app gives Apple the opportunity to grant Workflow new exclusive privileges in terms of performance, iCloud Drive integration, and private API usage. If the company is committed to Workflow, I fully expect them to take advantage of technologies that aren’t available to third-party apps.

There are dozens of areas Apple could consider for new Workflow-only integrations. iPad users could gain an option to assign system-wide keyboard shortcuts to workflows and run actions from any app at any time – like they can with scripts on the Mac. Workflow could access device settings such as WiFi, Bluetooth, AirPlay, location, or Accessibility options, and provide contextual actions to modify the behavior of a device depending on the user’s preference, network condition, and other criteria.⁴ Apple could consider giving Workflow full access to iCloud Drive and let the app read files from and write them to any folder from any app – not just the sandboxed /Workflow folder.

Apple could even make special exceptions for increasing the memory allocation to the Workflow widget and extension, enabling users to perform more power-intensive tasks and for longer periods of time in multiple parts of the OS. Combined with extended background execution times, these advantages could allow Workflow’s automation engine to become more pervasive and integrated throughout iOS.

My favorite idea, however, is attempting to imagine new “real-time workflows” that would intelligently react to device conditions/environmental triggers and adapt their interface and actions accordingly.

Imagine, for instance, a workflow capable of accessing HomeKit controls, Apple Music, and HealthKit workouts at runtime. A user who goes running every morning could easily assemble a multi-step routine which locks their front door and brings up a collection of music playlists before the run starts. While the user is running, an underlying Workflow engine would put workout-optimized music controls and run details front and center on the Apple Watch or iPhone. Finally, the same routine that “prepares” a new run could automatically unlock the front door, continue playing music on a wireless speaker, and display summary stats for the completed workout on a big screen via the Apple TV as soon as the user gets back home. This automation wouldn’t be a standalone “workflow” that is manually executed as much as it’d be an invisible, integrated, and secure automation engine connected to every piece of the Apple ecosystem.

It may sound too futuristic, but many of the key elements required for these ideas are already in place, both in Workflow and in Apple’s own frameworks. Workflow can already integrate with Apple Music and control music playback; it doesn’t have any HomeKit actions, but it fully supports HealthKit. With iOS 10, Apple added a basic routine-building UI for HomeKit automation, which would greatly benefit from Workflow’s more intuitive interface.

Once these two worlds collide, it’s reasonable to envision a deeply integrated Workflow that supports Apple technologies such as HomeKit, CloudKit sharing, CarPlay, Siri, and iMessage; it also makes sense to see Apple embrace new home and lifestyle automation features to foster more powerful (and yet secure) connections between all of their services.

As iOS continues to split system apps and features into atomic units available as extensions and widgets across the OS, and as services evolve into a new pillar for the company, Apple’s Workflow could be the connective tissue between them all, going far beyond the rudimentary app automations we’ve seen so far. Rewriting Workflow with exclusive access to iOS features and services would be an obvious first step.

A Bigger Idea: WorkflowKit

One of the unique traits of iOS devices – particularly the iPad – is how they’ve redefined the concept of modern productivity. As portable screens that can transform into anything, iPhones and iPads are enablers of new jobs to be done that supersede the association of “work” with spreadsheets and meetings. Once the computer is not on every desk but in every hand, the possibilities for productivity and work communications become endless.

Apple has played an essential role in the redefinition of modern productivity with the App Store, but we’re reaching the point where Apple and app developers can’t make one-size-fits-all solutions for millions of users with ever-changing needs and priorities. Apple can’t possibly develop all the productivity features for all the creative professionals, small business owners, educators, and enterprise customers who are adopting iOS.

With Workflow, Apple could lead us into a second generation of iOS productivity apps by turning automation and inter-app communication into an extensible, integrated platform.

In my mind, the next logical move for Workflow is to open up to apps with a new framework that does not require users to edit URL schemes. With a WorkflowKit (my own imaginary name), apps could offer some of their functions and data as discrete modules. These actions would allow users to build more complex and yet easier, faster, and safer workflows that let multiple apps collaborate on the same task in a visually automated fashion.

One of Apple’s goals with iOS 8 was to remove the need for URL scheme-based automation by offering extensions to invoke certain app functionalities anywhere on iOS. However, by relegating extensions to the share sheet and preventing developers from referencing individual third-party app extensions, Apple’s strategy partially missed the point. Developers who wanted to call a specific extension still couldn’t, and remained stuck with the extra step of the share sheet (see: how the 1Password extension has to be embedded in apps). Meanwhile, those developers who wanted to ship third-party app integrations and automation features still had to rely on URL schemes – usually, the popular x-callback-url spec (there are plenty of examples around, including ADA winners and Workflow itself).

As a result, extensions were a fantastic addition, but they didn’t address the lack of true inter-app communication and automation on iOS.⁵

WorkflowKit could help Apple move past URL schemes for good and offer a robust automation framework for developers. The system could be built on iOS’ current extensibility model, where a container app offers sandboxed access to extensions that users can invoke outside of the main app experience. Behind the scenes, Workflow’s Content Graph engine would take care of connecting any input to any app action, creating a safe automation environment where everything “just works”.

This way, rather than exchanging plain text data with a URL scheme (which forces users to jump back and forth between Workflow and apps), an app could offer multiple WorkflowKit extensions (called “actions”) to display content and perform rich tasks in Workflow. Permission to use such actions could be granted by users on a case-by-case basis, and actions could be grouped in categories that include running functions from external apps with or without an interface, managing documents, displaying specific app content in a custom QuickLook preview, and more.

Consider the current version of Workflow. The app is effectively split in two macro categories: native actions and third-party app ones. Native actions can be executed inside Workflow and offer features such as displaying menus and lists, opening webpages with Safari View Controller, formatting text and numbers, and more. Third-party app actions try to abstract the complexity of URL schemes with a pretty UI, but, in the end, they’re still based on launching URLs and leaving Workflow to open another app.

WorkflowKit could dramatically improve the second category of actions and make any app action a native one. Without leaving Workflow, an app like Pixelmator could provide a ‘Resize and Crop’ action to perform an image editing task inline. A note-taking app like Bear could have an ‘Append to Note’ action to save some text at the bottom of a note. A task manager could offer an action that presents you with a list of active todos to share with someone in your contacts. None of these actions would ever leave Workflow – they’d always run in-place and they’d come bundled with an app just like extensions and widgets currently do. Users would always grant permission to read, write, and delete third-party app data for WorkflowKit actions, and developers would have to support both visual and headless modes for every action they offer, with mandatory Accessibility integration. The entire system would be heavily influenced by Apple’s NSExtension framework and the Workflow team’s Content Graph engine.

This isn’t an easy task for Apple, though. To achieve such integration between iOS and apps, the company must first build a framework that enables apps to communicate directly with each other in a non-destructive manner. This implies a new set of privacy controls and permissions to avoid the problems inherent to URL schemes, as well as a fundamental rethinking of the iOS sandboxing structure. That system would then provide a new foundation for Workflow 2.0, which would leverage new inter-app communication APIs to deprecate URL scheme automation and allow users to mix and match functions from multiple apps. The Workflow Gallery, now limited to discovering workflows from other users, would also showcase apps that come with Workflow actions, providing a new discovery avenue for developers and, for users, a way to add more powerful functionality to their workflows simply by downloading new apps. Everyone wins.

The true potential for WorkflowKit lies, I believe, in going beyond workflows inside the Workflow app. WorkflowKit would give users a way to turn any action into a system-wide extension or widget. For example, workflows wouldn’t have to be grouped under a single ‘Run Workflow’ extension – instead, users could pin workflows as native extensions in the share sheet or other app toolbars. And if we follow this idea – that automation could trickle down into multiple parts of iOS – it’s easy to imagine workflow macros made specifically for Pages, sets of custom actions for Safari, or workflows that are designed as routines for Siri and HomeKit.

Thus, more than a rebranded Automator, an Apple-made Workflow 2.0 could be a comprehensive set of user automation tools that span an app and customizable extension points, all capable of integrating natively and securely with any iOS technology, app, and interface. A new inter-app communication framework and the subsequent WorkflowKit would be the core of this system. App developers (including Apple) would offer actions; users would ultimately remix them and connect them to anything they want.

At a fundamental level, I strongly believe that Apple doesn’t like the URL scheme-based app actions in the current version of Workflow they just acquired. Using URL schemes for app automation is an unreliable and unsafe workaround. I don’t see an Apple-owned Workflow introducing new features based on visible URL schemes.⁶

Therefore, if we buy into the theory that Apple wants to invest in the Workflow app without crippling it, it’s only natural to assume that the company is planning new inter-app communication features with an automation component. That would be WorkflowKit. If done right, WorkflowKit could reimagine iOS productivity by letting us completely personalize our work experience and favorite apps.

The Path Ahead

We’re on the cusp of a new beginning for automation on Apple’s platforms. With Workflow, Apple has acquired more than an app; they have gained a foothold in a new kind of user automation that is friendly, visual, accessible, and deeply integrated with iOS hardware and software unlike any scripting language before.

In this article, I have outlined the worst and best scenarios for Workflow going forward. Realistically, here’s what I expect:

I think Apple acquired Workflow with the intention of building their own automation platform on iOS. Like Siri, TestFlight, and Beats Music, I don’t think Apple bought Workflow just to abandon it. I believe both Apple and Workflow saw this as the best possible solution to continue growing the app into a more powerful tool for iOS users. Whatever Apple is planning, however, it won’t be ready for iOS 11 in June. I’d expect the Workflow app to remain (mostly untouched) on the App Store until Apple offers a replacement – possibly in Spring 2018 or in iOS 12. If and when that replacement becomes available, I expect it to be a complete rewrite of the app with little to no support for legacy workflows.⁷

I also assume that Apple wants their take on iOS automation to be tightly controlled by clear user permissions, and that URL scheme callbacks won’t be part of Workflow’s future. Unless Apple wants to outright remove third-party app support from Workflow, I suspect the company is building “Workflow as a feature” inside iOS with a framework that developers will be able to integrate with. That “WorkflowKit” framework will enable third-party developers to offer discrete app actions that can be embedded in Workflow and other extension points. WorkflowKit will be based on groundwork laid with iOS 11 this year, and it’ll tell a bigger story for Workflow 2.0 as the glue between every iOS app, service, or system feature. I’m guessing, but I’d say that all of this is at least a year away.

Apple acquiring Workflow could be a pivotal moment for iOS automation and productivity apps. Two years after the release of Workflow 1.0, we’re at a crossroads: Workflow has shown us a future where automation means an intuitive GUI, native integrations with iOS, and none of the baggage of desktop scripting. There’s a special beauty in Workflow’s underlying message: anyone, whether they consider themselves “programmers” or not, can make a computer their own. The software we use every day doesn’t have to be a static experience; with automation and creativity, any app can be remixed, extended, and personalized to our needs.

Workflow gives power back to the users. Now only Apple can turn Workflow’s promise into a reality, ushering us into a new era of automation for everyone, on every device, in every app.

I want to believe.