Skip to content

Data Driven Workflows

No due date 75% complete

If you've got an idea that really works, take that idea as far as it will go, right??? Well, Workflows WORK, they work so well and provide such configurability that there's really no reason to stop at defining them in Swift. We could create a specification in JSON and/or YAML and have that define a workflow. The app could consume that specifically and dyn…

If you've got an idea that really works, take that idea as far as it will go, right??? Well, Workflows WORK, they work so well and provide such configurability that there's really no reason to stop at defining them in Swift. We could create a specification in JSON and/or YAML and have that define a workflow. The app could consume that specifically and dynamically create them.

The available FlowRepresentable items would have to be driven from the AST output of the Swift code, and there'd have to be some kind of linter to enforce the same kinds of things we have the Swift compiler enforcing, but there's really some interesting things you could do with this.

Think about the white-label capabilities this would enable, you could define all kinds of workflows for an app. Take it even further, there's no reason a server couldn't ultimately drive this meaning that you could change a workflow to suit the needs of a business without redeploying an app. I don't believe this really even fundamentally violates the Apple Review Guidelines because we're not talking about fundamentally changing the behavior of an app at all, simply the workflows it launches, it has all the exact same capabilities.

We know we are successful with this milestone when:

  • There is a clear, versioned specification for creating a workflow with common configurations (e.g. JSON, maybe YAML)
  • Workflows can be created at runtime from that specification
  • Workflows are safely created, if the spec asks for FlowRepresentables that simply don't exist, the Workflow cannot create.
  • The API space makes it abundantly clear that creating a Workflow from data could fail, and gives consumers a way to deal with that (throwing, compile-time errors, something....)
  • We have tested Workflows of absurd sizes and have some minimum support for that (a 1,000 item Workflow seems a little ludicrous right now, let's at least have tests and support for that, scale that up as far as you feel you reasonably can, a million item Workflow? If the tests don't take too long, sure!)
  • Our sample app is updated to make use of these data driven workflows, perhaps that's local configuration like white-labeling or server-driven configuration just to showcase that it's possible and how cool it is.
Loading