# How to Configure TabView with NavigationStack for Multi-Screen SwiftUI Apps > Learn to configure TabView with NavigationStack for multi screen SwiftUI apps. Implement a router per tab architecture for independent navigation state management. Maximize your app's flow. - Repository: [Thomas Ricouard/Skills](https://github.com/Dimillian/Skills) - Tags: how-to-guide - Published: 2026-04-01 --- **Combine a `TabView` with independent `NavigationStack` instances by implementing a router-per-tab architecture using an `AppTab` enum for identity, a `TabRouter` to manage per-tab navigation state, and a root `AppView` that injects each stack with its own `path` binding.** Modern SwiftUI applications require independent navigation histories for each tab while maintaining a unified shell. To configure TabView with NavigationStack for multi-screen apps, you need an architecture that separates tab identity from navigation state. The Dimillian/Skills repository demonstrates this pattern through a scalable router system defined in [`swiftui-ui-patterns/references/app-wiring.md`](https://github.com/Dimillian/Skills/blob/main/swiftui-ui-patterns/references/app-wiring.md) and [`swiftui-ui-patterns/references/navigationstack.md`](https://github.com/Dimillian/Skills/blob/main/swiftui-ui-patterns/references/navigationstack.md). ## The Router-Per-Tab Architecture The recommended pattern relies on three core concepts: a **single source of truth for tabs** via an `AppTab` enum, **per-tab navigation state** through a `RouterPath` class, and **root-level composition** in an `AppView`. This design ensures that switching between tabs preserves each stack's history while allowing programmatic navigation and deep-linking support. When you configure TabView with NavigationStack using this approach, each tab receives its own `NavigationStack` with a dedicated `path` binding. This prevents the history loss that occurs when using a single `NavigationStack` wrapper around the entire `TabView`. ### Core Components The architecture consists of five primary components working together: - **`AppTab`** – An `Identifiable` enum that defines each tab's identity, provides a `makeContentView()` builder, and supplies label views. - **`TabRouter`** – An `@Observable` class that maintains a dictionary `[AppTab: RouterPath]` and provides `router(for:)` and `binding(for:)` methods. - **`RouterPath`** – Stores the navigation `path: [Route]` and optional sheet state, implementing helpers like `navigate(to:)` and `reset()`. - **`AppView`** – The root view that owns `@State var selectedTab` and the `TabRouter`, composing the `TabView` and embedding each tab's content in a `NavigationStack`. - **`Route`** – A `Hashable` enum describing navigation destinations (e.g., `.detail(id:)`). ## Step-by-Step Implementation ### 1. Define the AppTab Enum Create an enum that conforms to `Identifiable`, `Hashable`, and `CaseIterable` to describe your tabs. According to the Dimillian/Skills source code in [`swiftui-ui-patterns/references/app-wiring.md`](https://github.com/Dimillian/Skills/blob/main/swiftui-ui-patterns/references/app-wiring.md), this enum should provide a stable `id`, a `makeContentView()` method for content generation, and a `label` view for tab items. ```swift @MainActor enum AppTab: Identifiable, Hashable, CaseIterable { case home, notifications, settings var id: String { String(describing: self) } @ViewBuilder func makeContentView() -> some View { switch self { case .home: HomeView() case .notifications: NotificationsView() case .settings: SettingsView() } } @ViewBuilder var label: some View { switch self { case .home: Label("Home", systemImage: "house") case .notifications: Label("Notifications", systemImage: "bell") case .settings: Label("Settings", systemImage: "gear") } } } ``` ### 2. Create the Navigation Router Implement a `RouterPath` class to hold the navigation stack and sheet state. As documented in [`swiftui-ui-patterns/references/navigationstack.md`](https://github.com/Dimillian/Skills/blob/main/swiftui-ui-patterns/references/navigationstack.md), this class uses `@Observable` (or `@StateObject` in older versions) to track the `path` array. ```swift @MainActor @Observable final class RouterPath { var path: [Route] = [] var presentedSheet: SheetDestination? } enum Route: Hashable { case detail(id: String) } ``` ### 3. Build the TabRouter Factory Create a `TabRouter` that manages router instances for each tab. The `router(for:)` method lazy-loads instances, while `binding(for:)` creates a two-way binding to the path array suitable for `NavigationStack`. ```swift @MainActor @Observable final class TabRouter { private var routers: [AppTab: RouterPath] = [:] func router(for tab: AppTab) -> RouterPath { if let router = routers[tab] { return router } let router = RouterPath() routers[tab] = router return router } func binding(for tab: AppTab) -> Binding<[Route]> { let router = router(for: tab) return Binding(get: { router.path }, set: { router.path = $0 }) } } ``` ### 4. Wire Up the Root AppView In your root view, initialize a `TabRouter` and iterate over your tabs. For each tab, retrieve its router and create a `NavigationStack` using the binding from `tabRouter.binding(for:)`. This implementation from [`swiftui-ui-patterns/references/app-wiring.md`](https://github.com/Dimillian/Skills/blob/main/swiftui-ui-patterns/references/app-wiring.md) also injects the router into the environment for child access. ```swift @MainActor struct AppView: View { @State private var selectedTab: AppTab = .home @State private var tabRouter = TabRouter() var body: some View { TabView(selection: $selectedTab) { ForEach(AppTab.allCases) { tab in let router = tabRouter.router(for: tab) NavigationStack(path: tabRouter.binding(for: tab)) { tab.makeContentView() } .withSheetDestinations(sheet: Binding( get: { router.presentedSheet }, set: { router.presentedSheet = $0 } )) .environment(router) // inject router for child views .tabItem { tab.label } .tag(tab) // associate selection } } .withAppDependencyGraph() // installs global services (auth, streaming, etc.) } } ``` ### 5. Handle Special Tab Interactions For tabs that trigger actions rather than switching views (such as a compose button), use a custom binding. The [`swiftui-ui-patterns/references/tabview.md`](https://github.com/Dimillian/Skills/blob/main/swiftui-ui-patterns/references/tabview.md) file demonstrates intercepting the selection change via `.init(get:set:)` to present modals without changing the selected tab. ```swift @MainActor struct AppView: View { @Binding var selectedTab: AppTab var body: some View { TabView(selection: .init( get: { selectedTab }, set: { updateTab(with: $0) } )) { // … regular tabs … } } private func updateTab(with newTab: AppTab) { if newTab == .post { // `.post` is the compose shortcut presentComposer() return } selectedTab = newTab } } ``` ## Why This Pattern Works This architecture solves three critical problems in multi-screen SwiftUI apps. **Independent histories** ensure that each tab maintains its own navigation stack, so users don't lose their place when switching contexts. **Type-safe routing** uses the `Route` enum with `navigationDestination(for:)` modifiers inside each stack, enabling compile-time checked navigation. **Global dependency injection** via `.withAppDependencyGraph()` and `.environment(router)` allows child views to access navigation state and services without singletons. ## Summary - Use an `AppTab` enum to centralize tab identity, labels, and content view factories. - Implement a `TabRouter` to create and manage separate `RouterPath` instances for each tab. - Wrap each tab's content in its own `NavigationStack(path:)` using bindings from the `TabRouter`. - Inject the specific `RouterPath` into each tab's environment for programmatic navigation access. - Use custom bindings on `TabView(selection:)` to intercept special tabs like compose buttons. ## Frequently Asked Questions ### Why should I use separate NavigationStack instances for each tab instead of one around the TabView? Individual `NavigationStack` instances preserve each tab's navigation history when users switch between tabs. A single `NavigationStack` wrapping `TabView` causes all tabs to share one navigation path, meaning switching tabs resets or shares history, which breaks user expectations for independent tab contexts. ### How does this architecture handle deep linking? The `RouterPath` class can expose a method like `navigate(to:)` that appends routes to the `path` array. Since `NavigationStack` binds directly to this array, programmatically appending a `Route` case triggers immediate navigation. Deep links can target specific tabs by updating the `selectedTab` and then calling the router's navigation method. ### Can I use this pattern with SwiftData or Core Data? Yes. The `AppView` can install a global dependency graph using `.withAppDependencyGraph()` or pass model contexts via the environment. Because each `NavigationStack` is independent, you can pass different model queries or configurations to each tab's root view while maintaining type-safe navigation. ### What if I need to present a modal sheet from within a specific tab? The `RouterPath` includes a `presentedSheet` property. Bind this to a sheet modifier using `.withSheetDestinations(sheet:)` as shown in the `AppView` implementation. Since each tab has its own `RouterPath` instance, sheets are automatically scoped to the correct tab without interfering with other stacks.