So, what we’ve seen is that the Composable Architecture comes with some tools out of the box that allow you to “derive behavior”, which means that you can take a big blob of behavior, such as the store that controls your entire application, and derive new stores that focus in on just a subset of that behavior. This is crucially important if you want to build large, complex applications that can be split apart into isolated modules.

Unfortunately SwiftUI does not give us these tools out of the box. Currently it is on us to manually implement the integration points between child view models and parent view models. We have to make sure that anytime the child changes we notify the parent so that it can do any work necessary, and we need to listen for changes to particular pieces of state in each child so that we can replay them to the other siblings. We also have to do extra work in order to make sure we don’t accidentally create infinite loops between children, such as when child A updates child B which causes child B to update child A, and so on.

So now that we’ve seen the benefits of scoping our domains to smaller and smaller units, let’s flex those muscles a bit more. Turns out there are lots of use cases for transforming stores beyond just simple scoping, and this starts to unlock even more ways you can break out small subdomains into their own little isolated worlds. We’re going to build a new demo app from scratch in order to explore this.

We’ll start with a project that already has a little bit of functionality implemented using the Composable Architecture, and it’s…yet another counter app. I’m sure our viewers are all sick of counter apps by this point, but we promise we will make it a lot more exciting.