Diving Into SwiftUI

The world of SwiftUI is always evolving—with updates and changes constantly on the horizon. This webinar is for anyone interested in getting started or expanding their knowledge of SwiftUI. Led by a panel of Big Nerd Ranch SwiftUI experts, this webinar will help you understand whether now is the right time to start building with SwiftUI and talk through our first-hand experiences adopting SwiftUI across many of our consulting projects.

Bonus Q&A

This webinar was an especially popular one, and we weren’t able to answer all of the great questions our attendees had. Our engineers were able to answer them offline—check out their responses below!

Thoughts on CoreData + SwiftUI tandem? And to make the question more complex, please touch on CoreData integration with CloudKit as well. 

Core Data is Core Data, regardless of SwiftUI. What a SwiftUI project offers is a full Swift syntax and some nice wrappers around NSManagedObjectContext. Core Data hasn’t had a major update in years. 

SwiftUI didn’t really give it an update other than the syntax and wrappers mentioned. You can certainly use the two in tandem in a production application. One of our engineers is currently on a project that does just that.

What are your predictions for the future of SwiftUI, UIKit, Storyboards and Interface builder? Is SwiftUI Previews better than Interface Builder?

It’s hard to predict, but here’s what I imagine will happen. Apple will continue investing into SwiftUI. They are “dogfooding” SwiftUI in more of their own apps each year, and that should help accelerate progress addressing issues and filling API gaps. 

UIKit, AppKit, Interface Builder—these technologies are not going anywhere anytime soon. In a decade, I imagine you’ll still be able to write UIKit apps in Objective-C using storyboards. But I don’t anticipate major changes to these technologies. They will get small features here and there, but more of the engineering work will be going into newer technologies like SwiftUI.

On comparing Previews to Interface Builder: it’s hard to say whether one is better than another. While there is overlap in their purposes, Previews and Interface Builder have slightly different purposes. Interface Builder is more about the building and less about the previewing—but it can do both. Previews are more about the previewing and less about the builder—but it too can do both.

How do you write automated tests for SwiftUI code?

So, what I do is make sure write comprehensive unit tests for the model and the view model (if applicable), and then, test the view part using UITesting.

Generally you are going to unit test your model or view model code. For SwiftUI, you’d use UI tests. The process and flow for that is identical to UIKit.

Do you have tips on customizing UI (like background color) in standard SwiftUI components? It is notoriously difficult when there is no view modifier for that, or it does not work as one would expect.

I think background should work now. And if all else fails (I had one map that needs some customized behavior on the annotation and the resulting callout), there’s always UIViewRepresentable.

One challenge when learning SwiftUI today is understanding whether a feature is missing from SwiftUI, or if it is represented in a new way/place/name. If a feature is missing, you might benefit most from using one of the Representable types to wrap up UIKit code. There are also a few GitHub repos that do this too, including SwiftUIBackports and SwiftUIX. SwiftUI-Introspect is another useful tool to have for filling in gaps.

All of the articles that I have read about SwiftUI bindings use properties. Can bindings be made to methods and/or subscripts?

A binding is a “portal” to some data that needs to be read and written to. Because of this, bindings only make sense for properties on other types. If you need more control over the Binding behavior, you can manually instantiate a Binding type with a custom getter and setter.

To create a hybrid SwiftUI / UIKit app, I’m considering an architecture with pure SwiftUI model & view models, some SwiftUI views, and some UIViews w/ their respective UIViewControllers observing view models via Combine.

The main thing is pure SwiftUI model & view models for all views, whether the view is SwiftUI or UIKit. Thoughts?

I think you might need to adapt some minority part to work with UIKit, but the rest might be a good idea. View models as ObservedObjects with @Published properties that can be subscribed to seems sound as well.

Is SwiftUI the appropriate framework for building an application that will rely on inputs from multiple external micro-services? Provided this is on recent iOS version.

Yes, I think this should work. When I think about micro-services, I’m thinking less about the view layer and more about the model/networking layer. That will work well in either UIKit or SwiftUI.