Apple Might Be Rethinking Navigation Again — What We’re Seeing So Far

Mar 31

Published March 31, 2026 · Jordan Kim

SwiftUI navigation has already gone through a few iterations, and while NavigationStack addressed a lot of early pain points, it hasn’t fully settled the story. Recently, a few subtle patterns have started to emerge that suggest Apple may still be iterating on how navigation should work at scale.

TL;DR

NavigationStack improved things, but complex flows still require a lot of manual coordination
State-driven navigation works well for simple cases but becomes harder to manage across large feature sets
Some patterns emerging in real-world apps look closer to coordinator-style architectures
Apple may be exploring ways to make navigation more composable and less tightly coupled to view structure

We’ve Been Here Before

SwiftUI navigation has evolved quickly. Early versions relied heavily on NavigationView, which had well-known limitations around deep linking, programmatic navigation, and state restoration.

NavigationStack was a big step forward, especially with its path-based API. But once apps move beyond simple flows, new challenges start to show up.

Where Things Still Feel Frictiony

For small features, something like this works great:


NavigationStack(path: $path) {
    List(items) { item in
        NavigationLink(value: item) {
            ItemRow(item: item)
        }
    }
}

But as soon as navigation spans multiple domains, flows, or entry points, things get more complicated:

multiple features trying to mutate the same path
deep links needing to reconstruct complex navigation state
presentation styles (push, sheet, full screen) living in different layers
navigation logic spreading across unrelated views

The Rise of “External Navigation State”

One pattern that keeps showing up in larger apps is moving navigation logic out of individual views and into some kind of shared coordinator or router.


final class NavigationCoordinator: ObservableObject {
    @Published var path: [Route] = []
    
    func push(_ route: Route) {
        path.append(route)
    }
}

This isn’t new, but it’s interesting that many teams end up here even when starting with purely SwiftUI-native approaches.

Why View-Coupled Navigation Breaks Down

SwiftUI encourages navigation to live close to the views that trigger it. That works well until navigation becomes cross-cutting — spanning multiple features or requiring coordination between unrelated parts of the UI.

At that point, the “navigation lives in the view” model starts to feel limiting, and teams begin building their own abstraction layers on top.

What Apple Might Be Exploring

If Apple continues evolving navigation, the next step likely isn’t a complete rewrite. It’s more likely a shift toward:

more explicit separation between navigation state and view hierarchy
better support for multi-entry navigation flows
clearer coordination between push, modal, and overlay presentations
APIs that scale more naturally across feature boundaries

Something like:


NavigationContainer(coordinator: coordinator) {
    RootView()
}

Why This Matters

Navigation is one of the hardest parts of scaling a SwiftUI app. It touches architecture, state management, deep linking, and user experience all at once.

Even small improvements here can have a huge impact on how maintainable an app feels over time.

Final Thoughts

SwiftUI navigation is already much better than it used to be. But it still doesn’t feel completely settled, especially for complex apps.

If Apple is continuing to refine this area, it wouldn’t be surprising. And based on how many teams are building similar abstractions today, it’s also probably overdue.

Bre Meyer