OK, we have now introduced a property wrapper into our navigation tools, first to deal with some potential performance and stack overflow problems, but it also turned out to be the perfect spot for us to squirrel away some extra information so that we could make the tools even better.

So, this is all looking great, but we still have yet to discuss what is probably the hottest topic when it comes to navigation on Apple’s platforms, and that’s navigation stacks. In particular, the initializer of NavigationStack that takes a binding to a collection of data which drives the pushing and popping of screens to the stack. This was introduced in iOS 16 and kinda turned everything upside down relative to how navigation had been done in SwiftUI for the 3 years prior.

Stack-based navigation is where you model all the different screens you can drill-down to as a single, flat array of values. When a value is added to the array, a drill-down animation occurs to that screen, and when a value is removed from the array a pop-back animation occurs.

This stack-based style of navigation is in stark contrast with what we like to call “tree-based” navigation, which is what we have been doing so far in this entire series of episodes. In that model, each feature in the application acts as a branching point for all the different places you can navigate to, and then each of those destinations has branches, and on and on and on.

Each style has lots of positives and some negatives, so let’s dig a little deeper into a comparison of the two styles, and see what the Composable Architecture has to say about stack-based navigation.