@DTS Engineer Thanks for the swift reply. I reviewed the resources you provided, and still have some remaining uncertainty around what is the recommended approach for an app like ours. Our app is much larger and complex than any of the sample apps Apple provides, and the sample apps are not complex enough to run into the same kind of challenges I have experienced. In terms of functionalities we support, we currently do not support state restoration, but we do support many deep links. Additionally, our navigation is very flexible meaning many pages can be navigated to from several different places. I am going to give an overview of the 2 approaches I have tried so far, and the pros and cons of each. Hopefully this will be enough information that you or others could help us make an informed decision or provide solutions to our issues. Migration Approaches 1. Navigation Destinations Defined at Root Overview Create a shared, reusable NavigationStack that manages… Applying toolbar buttons / styling Implements navigationDestination support for all destinations Keeps track of which navigation path is the current one Advantages Only need to define each navigation destination → view mapping once and then it can be reused Deeplink implementation is more straight forward Disadvantages Cannot pass non-hashable params to views we navigate to (view models, callbacks, etc.) Option 2 has a little more flexibility with this because the view for the navigation destination is often defined where it has access to the data we want to pass Less organized Not as clear mental mapping of our navigation tree of possibilities May need to have some complex logic that manages and keeps track of what is the current navigation stack for appending to Not easy to do one-off NavigationStacks with own private view destination if any of those destinations are shared with the rest of the app 2. NavigationDestinations Applied at Each Page Which Navigates Overview This approach entails for each page which navigates somewhere… Define a page specific destination enum with cases for all destinations Add a navigationDestination view modifier that maps all enum cases to a view Replace all NavigationLinks with navigation APIs that use the enum case Advantages More similar to how our navigation currently works Easier to feel confident that there will always be a supported navigation destination for a given push / append Disadvantages You cannot place navigationDestination view modifier inside of any lazy containers (LazyVStack, List, etc.) This means that for a lot of navigation, the actual navigation is controlled from a much higher up parent than would be ideal / intuitive You cannot reuse destinations. If multiple views can all navigate to the same view, they all need their own navigationDestination case. You cannot have nested navigation destination modifiers of the same type This really falls apart in cyclical views ProfileView → FollowersList → ProfileView Etc. This once again leads to moving the navigation destination up to a higher parent making this more cumbersome