🔒 Let’s see how to integrate a SQLite database into a SwiftUI view. We will explore the tools GRDB provides to query the database so that we can display its data in our UI, as well as build and enforce table relations to protect the integrity of our app's state. And we will show how everything can be exercised in Xcode previews.

🔒 Interfacing with SQLite's C library from Swift is possible, but clunky. Luckily there are friendlier, "Swiftier" interfaces the community has built, so let's take a look at the most popular: GRDB. We'll explore how it can help us avoid pitfalls and boilerplate required to use the C library, and how its typed SQL helpers can even help us avoid runtime issues at compile time.

🔒 SQLite is one of the most well-crafted, battle-tested, widely-deployed pieces of software in history, and it's a great fit for apps with more complex persistence needs than user defaults or a JSON file. Let's get familiar with the library, starting with a crash course in interacting with C code from Swift.

🔒 We zoom out a bit to get a greater appreciation for how `Equatable` and `Hashable` are used throughout the greater language and ecosystem, including actors, standard library types, SwiftUI, and more.

🔒 We've studied `Equatable` and `Hashable`, their laws, and saw how value types as simple bags of data easily conform via "structural" equality. What about reference types? Reference types are an amalgamation of data _and_ behavior, and that data can be mutated in place at any time, so how can they reasonably conform to these protocols?

🔒 While the documentation for `Equatable` discusses the notions of "equivalence relation" _and_ "substitutability", there are conformances in the Standard Library that run afoul, but for pragmatic reasons. Let’s explore them and then dive deeper into a related protocol: `Hashable`.

🔒 In this series we go back to basics with a deep dive into the subject of `Equatable` types. Equatability is a deceptively simple topic. It is a surprisingly tricky protocol that has some very specific semantics that must be upheld baked into it, and there are many misconceptions on how one can or should conform types to this protocol.

🔒 We round out our series with one more feature: the ability for our users to manage a list of their favorite facts. It will allow us to explore a complex side effect, persistence, and show how the same Swift code can save and load data across iOS app launches _and_ web page refreshes.

🔒 We've already covered a lot of ground and could have ended the series last week, but let's do a few more things to show just how powerful cross-platform domain modeling can be by adding a _new_ feature to our cross-platform application and see just how easy it is to integrate with SwiftUI, UIKit, _and_ WebAssembly.

🔒 We will introduce UI controls and focus logic to our SwiftWasm application by leveraging a binding type inspired by SwiftUI, and we will see how similar even our view logic can look across many platforms.

🔒 We will introduce navigation APIs to our Wasm application, starting simply with an alert before ramping things up with a `dialog` tag that can be fully configurable from a value type that represents its state and actions.

🔒 Let's dial up the complexity of our Wasm application! We'll introduce some async logic in the form of a network request. We'll take steps to not only control this dependency, but we'll do so across both Apple and Wasm platforms, and we'll isolate its interface from its live implementation to speed up our builds and reduce our app's size.

🆓 We are going to take a Swift feature _into the browser_. We will set up a WebAssembly application from scratch, show how to run and debug it, and even set up some basic UI. And then we will integrate our existing model into it, all powered by the magic of Swift's Observation framework.

🆓 It's time to go cross-platform! We will take a feature written in Swift and use it in vastly different situations, including not only SwiftUI and UIKit, but beyond Apple's frameworks and ecosystems. We will start with a baby step and introduce our feature to a third party view paradigm, Airbnb's Epoxy.

🔒 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 `UIControl`s 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.

🔒 While SwiftUI bindings were almost the perfect tool for UIKit navigation, they unfortunately hide some crucial information that we need to build out our tools. But never fear, we can rebuild them from scratch! Let's build `@Binding` and `@Bindable` from scratch to see how they work, and we will use them to drive concise, tree-based navigation using enums.

🔒 We have built the foundation of powerful new UIKit navigation tools, but they're not quite finished. Let's improve these APIs to handle dismissal by leveraging another SwiftUI tool: bindings. We will see how SwiftUI bindings are (almost) the perfect tool for UIKit navigation, and we will see where they fall short.

🔒 Now that we have a tool that brings the power of the Observation framework to UIKit, let's put it through the paces. We will use it to build state-driven navigation tools that can drive alerts, sheets, popovers, drill-downs, and more, and they will look a lot like SwiftUI's navigation tools.

🔒 It's time to build modern tools for UIKit from scratch, heavily inspired by SwiftUI and using the Observation framework. Surprisingly, Swift 5.9's observation tools _can_ be used in UIKit, and in fact they work _great_, despite being specifically tuned for SwiftUI.

🆓 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.