Now that iOS 13 has been released to the public, SwiftUI and Combine are looking more and more attractive as you choose how to build your next greenfield app. But what about your existing applications? If you’re ready to drop iOS 12 and blaze new trails with SwiftUI, congratulations–and prepare yourself for an exciting journey.
So you’ve shipped your app’s iOS 13 updates, added dark mode, and dropped iOS 12 support… now what?
As with any refactor or paradigm change, you’ll want to create a plan. Translating all of your UI code into SwiftUI or rewriting your whole networking stack to use Combine probably isn’t worth the effort. Instead, for each piece of new work, consider if it would be a good candidate to use with one of the new frameworks.
Luckily, these frameworks are designed to play nicely with the existing ones. For example, you can write new views in SwiftUI and nest them in your existing views, or start writing a new API client with Combine and use it as you consume new API endpoints. Your new code will benefit from the new abstractions and your old code won’t need to know or care.
As for actual project files, you won’t need to mess around with your app’s Info.plist or your Xcode project’s structure unless you’re planning on taking advantage of same-app multitasking in iPadOS. You can jump right in!
SwiftUI and UIKit views can talk to each other very easily since SwiftUI is largely an abstraction built on top of UIKit. Here’s a simple example of walking the two-way street between the frameworks.
If you have a new feature that’s a perfect candidate for SwiftUI, UIHostingController is going to be your BFF. UIHostingController is a ViewController that wraps SwiftUI views and lets you integrate them into UIKit views.
Since it’s a subclass of UIViewController, you can use it exactly as you’re used to–subclass it for custom behavior, use it in your storyboards, or just add it as a child ViewController.
In fact, even “pure SwiftUI” apps use a UIHostingController for their window’s rootViewController property.
One of the biggest benefits of using UIKit components in SwiftUI is that your UIKit components get the same reactive capabilities as your SwiftUI components if you’re using Combine.
UIViewRepresentable and UIViewControllerRepresentable let you port existing UIKit components to SwiftUI. One of the simplest examples is UIActivityIndicatorView, which at the time of writing doesn’t have a corresponding SwiftUI component.
If you’re not familiar with Swift 5’s property wrappers, the Data Flow Through SwiftUI WWDC talk is a wonderful introduction. (Note that some of the property wrapper names have changed in the short time since WWDC! It is a bleeding-edge framework after all 😁)
You may have noticed that the ActivityIndicatorView reads the @Binding in the example above. Writing to an @Binding variable from UIKit is as simple as giving your UIView or UIViewController a Coordinator.
Here we construct a simple view that will greet the user if isGreeting is true. It provides a button for the user to toggle the state of isGreeting.
Next we have the GreetingButton, a UIViewRepresentable that wraps a UIButton. Pressing this button shows or hides the greeting.
Finally, we have a Coordinator that handles the UIButton’s target-action events and modifies the bound isGreeting value. This Coordinator can be its own class or it can be nested inside the GreetingButton structure.
Consider what this implementation would look like pre-SwiftUI. Your button’s tap handler would need to edit the state, update the button’s UI, and then update the greeting labels. Add a ViewController and you’d need to manage multiple sources of truth. This example may be trivial, but it is a great demonstration of how SwiftUI allows for single source of truth (isGreeting).
Now your GreetingButton’s tap handler just toggles a piece of state and each UI element is re-rendered by SwiftUI. A good piece of boilerplate is removed, your views are simpler, and they can react to state changes automatically by doing a lot of the hard work for you.
These examples only scratch the surface of SwiftUI. While you are likely to find yourself reaching for the new frameworks more frequently as the platform matures, don’t forget the power of SwiftUI and UIKit’s interoperability if you find yourself scratching your head. SwiftUI is still young and it will certainly evolve as its paradigms are refined. With some foresight and ambition, you can even influence the direction the community takes the platform.
Welcome to SwiftUI!