Skip to content

Category: SwiftUI

4 things you can do *right now* to be ready for SwiftUI and Combine

Many of us were excited about all the new frameworks at WWDC: SwiftUI and Combine being the biggest ones. You were probably all ready to start using them in your app, until you opened up the documentation and saw this:

And you felt at least one of these feelings:

😡 😭 🙄

You knew at that point, that even with the usual new iOS version adoption curve, unless you’re looking at sacrificing a significant portion of your user base, you’re looking at adopting all these new features in Spring 2020, at the earliest. If your app needs to support older OS versions for a longer period, it could be even longer.


You can’t fix your users: they upgrade whenever they do (but thank Apple for new emoji ever year). But you also don’t need to sit on the sidelines and wait until those features are widely available to start implementing them. There are some things you can do while you’re waiting for your users to catch up, so that you’ll be ready to deliver apps based on these great new frameworks. You can even do some of this work now, while those betas are less than stable. Here are a few things to think about.

Catch SwiftUI model updates from bad threads before they crash your app

It hasn’t yet been reflected in the official SwiftUI documentation (yay, betas), but the WWDC presentations and further guidance from Apple engineers have made it very clear about one point of SwiftUI: as with UIKit, you must send SwiftUI updates only from the main thread. The more things change…

The bad thing about this is that if you don’t make your updates on the main thread, you get away with it.

Most of the time.

The reality: updating the UI outside the main thread — in UIKit and in the newer SwiftUI — is going to be a source of hard to debug bugs, possible race conditions when updates are made to the UI, and at worst, app crashes.

Your BindableObjects may have many attributes, all that require you to do a willChange.send(). With so many places where your asynchronous code may need to trigger an update to your Views, what can you do to catch those missed main thread migrations before they become headaches? Xcode can save your sanity with its built-in Main Thread Checker debug functionality. Let’s walk through a basic example.

Frustrated by missing features in SwiftUI? Using UIViewRepresentable to wrap UIKit controls

When the SwiftUI announcement came out at WWDC 2019, you were buzzing about the new framework. Finally, a new way to build our interfaces. Out with ViewControllers, out with storyboards, in with declarative, programmatic UIs!

Now that we’ve all had some time to play with the framework, we’ve found out what we’re really trading away when we use SwiftUI, at least for now. One of the major things? The vast array of components and configurability available through UIKit.

You’ve probably found through experimenting with the new framework that there are things missing. Entire UIKit components are missing, and things like the broad number of properties you could set on TextFields, and the common pull-to-refresh control are missing.

You really don’t want to continue down the UIKit road. You want to go all in on SwiftUI now; it’s the future of development for all Apple platforms. “But how am I going to get back these features?”

This is where UIViewRepresentable comes in. Apple knew that SwiftUI was not going to be a complete port of UIKit for its first version, and so they provided this protocol which you can implement on a View struct to wrap a UIKit control, making it usable in SwiftUI. Let’s see an example how to use this: getting the pull-to-refresh functionality on a scroll view.