🔒 While user defaults is convenient for persisting simple bits of state, more complex data types should be saved to the file system. This can be tricky to get right, and so we take the time to properly handle all of the edge cases.

🔒 We can now persist simple bits of state to user defaults using the `@Shared` property wrapper, but there is more work to be done. We need to observe changes to user defaults in order to play those changes back to `@Shared`, and we need to put in a bit of extra work to make everything testable.

🔒 Let's enhance the `@Shared` property wrapper with the concept of persistence. We will begin with user defaults, which is the simplest form of persistence on Apple's platforms, and that will set the stage for more complex forms of persistence in the future.

🔒 We will employ `@Shared`'s new testing capabilities in a complex scenario: a sign up flow. We will see how a deeply nested integration of features all sharing the same state can be tested simply, and we will see how we can leverage the same tricks employed by the test store to add debug tools to reducers using shared state.

🔒 The `@Shared` property wrapper can effortlessly share state among features to build complex flows quickly, but because it is powered by a reference type, it is not compatible with the Composable Architecture's value-oriented testing tools. Let's address these shortcomings and recover all of the library's testing niceties.

🔒 We finish building a complex, flow-based case study that leverages the new `@Shared` property wrapper. Along the way we will flex recently added superpowers of the library, and we will experience firsthand how simple this new model of shared state can be.

🔒 The various approaches of sharing state in the Composable Architecture are mixed bag of trade offs and problems. Is there a better way? We’ll take a controversial approach: we will introduce a reference type into our state, typically a value type, and see what happens, and take it for a spin in an all new, flow-based case study.

🔒 We tackle one of the biggest problems when it comes to "single source of truth" applications, and that is: how do you share state? Let's begin by analyzing the problem, and truly understanding what vague mantras like "single source of truth" even mean, and then we will be in a good position to provide a wonderful solution.

🔒 To celebrate our 6th anniversary we had another livestream! We updated an app from the most recent Composable Architecture tour to the latest observation tools, showed how these tools can improve UIKit-based apps, showed off some recent enhancements to the `@Reducer` macro, gave a sneak peek of a _highly anticipated topic_, and answered your questions along the way.

🔒 So what's the point of observation in the Composable Architecture? While we have seemingly simplified nearly every inch of the library as it interfaces with SwiftUI, let's zoom out a bit, explore how some integration tests that benchmark certain aspects of the library have changed, and migrate the Todos application we built in the very first tour of this library to the new tools.

🔒 We have iterated on how bindings work in the Composable Architecture many times, but have never been fully happy with the results. With Observation, that all changes. By eliminating view stores and observing store state directly, we are free to totally reimagine bindings in the Composable Architecture, and get rid of even more concepts in the process.

🔒 Observation has allowed us to get rid of a number of view wrappers the Composable Architecture used to require in favor of vanilla SwiftUI views, instead, but we still depend on a zoo of view modifiers to drive navigation. Let's rethink all of these helpers and see if we can trade them out for simpler, vanilla SwiftUI view modifiers, instead.

🔒 We can now observe struct, optional, and enum state in the Composable Architecture, but what about collections? Let's explore what it takes to get rid of the `ForEachStore` wrapper view for a vanilla `ForEach` view instead, while still observing updates to collection state in the most minimal way possible.

🔒 We've made structs and optionals observable in the Composable Architecture, eliminating the need for `ViewStore`s and `IfLetStore`s, so what about enums? If we can make enums observable, we could further eliminate the concept of the `SwitchStore`, greatly improving the ergonomics of working with enums in the library.

🔒 The Composable Architecture can now observe _struct_ state, but it requires a lot of boilerplate. Let's fix this by leveraging the `@Observable` macro from the Swift open source repository. And let's explore what it means to observe _optional_ state and eliminate the library's `IfLetStore` view for a simple `if let` statement.

🔒 One of the core tenets of the Composable Architecture is that you should be able to model your application's state using simple value types, like structs and enums. However, the `@Observable` macro does not work with value types at all, and so in order to enhance the Composable Architecture with Observation we will need to contend with this issue and explore what it means for a struct to be observable.

🆓 We're about to completely revolutionize the Composable Architecture with Swift's new Observation framework! But first, a sneak peek: we'll take the public beta (available today!) for a spin to see how the concept of a "view store" completely vanishes when using the new tools. Oh, and did we mention that the new observation tools in the library have been backported all the way back to iOS 13? This means you can use the tools _immediately_. 🤯

🔒 We have now totally reimagined the design of our case paths library to create actual key paths for enum cases, but there is some boilerplate involved. Let’s create a macro that eliminates all of it and explore a few of the possibilities it unlocks.

🔒 “Case paths” grant key path-like functionality to enum cases. They solve many problems in navigation, parsing, and architecture, but fall short of native key paths…till now. Let’s close this gap using macros that generate actual key paths to enum cases.

🔒 We take all we've learned about the Observation framework and apply it to a larger, more real world application: our rewrite of Apple's Scrumdinger demo. We'll see what changes are easy to make, what changes are a bit trickier, and encounter a bug that you'll want to know about.

🔒 We've explored the present state of observation in Swift, so what's the future have in store? Currently, observation is restricted to classes, while one of Swift's most celebrated features, value types, is left out in the cold. Let's explore a future in which observation is extended to value types.

🔒 While the `@Observable` macro improves upon nearly every aspect of the `@State` and `@ObservedObject` property wrappers, it is not without its pitfalls. We will explore several gotchas that you should be aware of when adopting observation in your applications.

🔒 The `@Observable` macro is here and we will see how it improves on nearly every aspect of the old tools in SwiftUI. We will also take a peek behind the curtain to not only get comfortable with the code the macro expands to, but also the actual open source code that powers the framework.

🔒 It's time to dive deep into Swift's new observation tools. But to start we will take a look at the tools SwiftUI historically provided, including the `@State` and `@ObservedObject` property wrappers, how they behave and where they fall short, so that we can compare them to the new `@Observable` macro.

🆓 Let's take our MacroTesting library for a spin with some more advanced macros, including those that Apple has gathered since the feature's introduction, as well as a well-tested library in the community: Ian Keen's MacroKit.