We finish building a modern UIKit application with brand new state-driven tools, including a complex collection view that can navigate to two child features. And we will see that, thanks to our back-port of Swift’s observation tools, we will be able to deploy our app all the way back to iOS 13.

As we approach WWDC24 and 5 years of SwiftUI, let’s talk about… UIKit! 😜 We love SwiftUI, but there will still be times you must drop down to UIKit, and so we want to show what modern UIKit development can look like if you put in a little bit of effort to build tools that allow you to model your domains as concisely as possible.

We conclude the series by stretching our use of the @Shared property wrapper in isowords to two more features: saved games and user defaults. In the process we’ll eliminate hundreds of lines of boilerplate and some truly gnarly code.

While we rebuilt SwiftUI bindings in UIKit to power state-driven navigation, that’s not all SwiftUI uses them for! Let’s see what it takes to power UIControls from model bindings. And finally, let’s ask “what’s the point?” by comparing the tools we’ve built over many episodes with the alternative.

We round out our stack navigation tools with support for an @Environment-like feature for holding onto the stack’s path, a NavigationLink-like feature for pushing features onto the stack from anywhere, and we’ll handle every corner case from deep-linking to user dismissal.

We have now implemented tree-based navigation in UIKit, driven by the Observation framework, but there is another form of navigation to think about: stack-based navigation, where you drive your navigation from a flat collection of states rather than a heavily-nested type. Let’s leverage Observation to build a really nice tool for stack-based navigation.