Well, this is pretty incredible.

In just a short amount of time we have been able to build a pretty complex UIKit app from scratch that features many of the things that real world apps need to deal with:

• Driving navigation from state, and we dealt with 3 forms of navigation: alerts, sheets and drill-downs.

• Forming 2-way bindings between our models and UI controls.

• Observing state changes in a model for updating UI elements.

• And dealing with complex collection views.

And we were able to accomplish all of this using precise, modern techniques, all thanks to the observation tools in Swift and our UIKitNavigation library.

And we want to remark again how important it was for us to perform our domain modeling exercise first and in complete isolation. We built 3 observable models for 3 of our features without ever once thinking about view specific needs. And instead, when it came time to build the view, we bent the view to the will of the model to make things work.

And that means we can reuse those models in a variety of view paradigms and platforms. We could rebuild those UIKit view controllers using SwiftUI, or we could build views for Windows, Linux, WebAssembly, or who knows what else! The possibilities are endless because we kept our domain models focused on just the business logic, and let the view flow freely from it.

So, this has been a lot of fun, but now it’s time to dig a lot deeper. We have showed off a lot of cool tools in the past episode, but what does it take to create these seemingly magical tools? Well, with a bit of hard work we can build them from scratch, and along the way we will get some deep insights into how SwiftUI works under the hood, and even get an understanding of why SwiftUI sometimes doesn’t work the way we expect.

So let’s begin.