Introducing SwiftCurrent
An open-source library for managing complex workflows in Swift and built-in support for UIKit and SwiftUI app-routing.
What is SwiftCurrent?
It’s a library that lets you manage complex workflows in Swift applications. It comes with built-in support for UIKit and SwiftUI app-routing. In SwiftCurrent, workflows are a sequence of operations. Those operations are normally showing views in an application. The workflow describes the sequence of views and manages what view should come next. Your views are responsible for performing necessary tasks before proceeding forward in the workflow, like processing user input.
Think about when you’re designing a user workflow for account registration. You probably have a view to collect information about the preferred username and password, a view showcasing the terms of service, and a view to collect profile information. SwiftCurrent is an abstraction layer that lets you define your app in terms of workflows and easily reorder items in those workflows as necessary.
Why should I use SwiftCurrent?
Architectural patterns and libraries that attempt to create a separation between views and workflows already exist. However, SwiftCurrent is different. We took a new design approach that focuses on
- A Developer-Friendly API: The library was built with developers in mind. It started with a group of developers talking about the code experience they desired. Then the library team took on whatever complexities were necessary to bring them that experience.
- Compile-time safety: We tell you at compile time everything we can so you know things will work.
- Minimal Boilerplate: We have hidden this as much as possible. We hate it as much as you do and are constantly working on cutting the cruft.
From there, we created a library that:
- Isolates your views: You can design your views so that they are unaware of the view that will come next.
- Easily reorders views: Changing view order is as easy as ⌘+⌥+[ (moving the line up or down)
- Composes workflows together: Create branching flows easily by joining workflows together.
- Creates conditional flows: Make your flows robust and handle ever-changing designs. Need a screen only to show up sometimes? Need a flow for person A and another for person B? We’ve got you covered.
Where can I use it?
Works with SwiftUI and UIKit: We’ve got 1st party support for SwiftUI and UIKit, with an API that feels natural for each. You can even interoperate between SwiftUI and UIKit seamlessly when defining your workflows.
Multiple platform support:
- 📱 iOS ✅
- 📺 tvOS ✅
- 💻 macOS ✅
- 🖥 macOS (Catalyst) ✅
- ⌚️ watchOS ✅
- 📱 iPadOS ✅
Works with the latest version of Swift: From Swift 5.0 to 5.5, we’ve got you covered. We’re even keeping track of all the pre-releases to keep us feeling natural and operating efficiently.
What else can it do?
- Optionally skip screens: Create onboarding experiences that only appear once or have screens that appear in a workflow based on other data conditions.
- Delegate to UIKit or SwiftUI: When you use SwiftCurrent, you’re just using an abstraction. We do not hold onto a view stack; we don’t have our own UI system. We abstract what you would’ve written in UIKit or SwiftUI for view navigation.
- Manage your view stacks: Workflows can contextually set up navigation views and modals for you. Check out our example app for more details.
- Reuse views between workflows: Sometimes, you need to use the same view to collect data but pass it to a different workflow. Using SwiftCurrent, you won’t have to change anything about your view code.
- Preview friendly: SwiftCurrent ties into the SwiftUI ecosystem, so your previews can render your workflows without having to run the app.
- Efficient: SwiftCurrent preserves all your type information, so when using SwiftUI, you still get the optimizations you expect, no AnyViews here!
- Animation Friendly: The animations you attach to views work just as well with SwiftCurrent, as they do without it.
- See all your workflows in one spot: We surface the complex paths of your app upfront, making it easier to reason through.
- Views, not screens: In SwiftUI, workflows can be just a view on your screen. You can even have multiple workflows on the same screen.
- You do you: We value your ability to choose. We checked our assumptions when designing so you could do the most with the best.
- Respond to change: If somebody wants to change the workflow in your application, it’s just a matter of deciding what workflow you want. You can A/B test new workflows, you can change based on preconditions, and you can respond to new design requirements, all with minimal tweaks to your code.
- More than UI management: We separated our logic so you can build on top of it. UIKit ✅ SwiftUI ✅ What do you want next? You can make it!
What’s next?
Start by checking us out on GitHub. Be sure to give us a star or leave us feedback on how we can earn one. We’ve got some guides for getting started in SwiftUI and getting started in UIKit, as well as comprehensive developer documentation.
This article was originally published on the WWT Platform. It was written by Richard Gist and Tyler Thompson.