One of the more exciting things announced at WWDC this year was the new “observation” tools that gives some us some machinery to observe how specific parts of a system change. This was exciting for a few reasons:

First of all, this machinery greatly improves one of the biggest pain points of SwiftUI, and that is understanding how changes to your model cause views to re-compute their bodies. Previously it was on you to make sure you marked the fields that are used in the view with the @Published property wrapper. If you did not then it would be possible for state to change in your model without your view updating, which is a bad bug. Or if you mark too many things with @Published you run the risk of re-computing your views too often.

Second, this new Observation framework is built directly into the open source Swift language and not as a proprietary Apple framework. This means that theoretically one can leverage the power of observation for many things outside of SwiftUI, and even outside of the Apple ecosystem, such as on Linux, Windows and more.

And third, and what’s really exciting for us personally, is that the new Observation framework has allowed us, meaning me and Stephen, to re-evaluate nearly every assumption we made when we originally built the Composable Architecture. It provides us the perfect opportunity to massively simplify and slim down the core library. We are able to completely get rid of concepts such as the “view store”, and we can get rid of a zoo of custom view types and modifiers, such as the ForEachStore, IfLetStore, SwitchStore, sheet(store:) and more.

It’s really exciting stuff, but before we can dive into how this all affects the Composable Architecture, we need to take a step back and really understand the Observation framework. We want to take a few episodes to really dig deep into the topic:

We’re going to start by recalling what are the observation tools provided to us in pre-iOS 17, such as the @State and @ObservedObject property wrappers, and discuss what their drawbacks were.

Then we will show how the new Observation framework improves upon nearly every aspect of those old tools, and we will even dig into the actual code in the open source Swift repo to understand how the tools work.

Then we will show that although the new Observation framework is pretty fantastic, it does have some gotchas lurking in the shadows. If you are not intimately familiar with how the tools work you can easily find yourself observing far more state than you expect.

And then we will end the series by pushing the Observation framework to its limit. While the framework is mostly designed to be used with reference types, we will explore what it would mean to apply the machinery to value types. There are some complications to doing this, but it is worth doing this exploration because it will be incredibly important for when we integrate the Observation framework into our popular Composable Architecture library, because one of its most celebrated features is that it allows you to build you eschew reference types and build your features with simple value types.

We’ve got a lot to cover, so let’s dig in!