Tutorial 10 mnt bacaIntermediate

NavigationStack SwiftUI iOS 26: Panduan Type-Safe Routing dan Deep Link (2026)

Panduan praktis NavigationStack di SwiftUI iOS 26: type-safe routing, NavigationPath, deep link parser, integrasi NavigationSplitView untuk iPad, plus catatan VoiceOver dari pengalaman production.

Ava ThompsonReviewed by Lukas Müller, Jun 2026
NavigationStack SwiftUI iOS 26: Panduan 2026

Diperbarui: 25 Juni 2026

NavigationStack di SwiftUI iOS 26 adalah API navigasi deklaratif yang memungkinkan kita membangun stack navigasi type-safe, programmatic, dan ramah deep link hanya dengan satu sumber kebenaran (NavigationPath). Saya sudah refactor lumayan banyak project legacy yang masih pakai NavigationView, dan jujur, kalau kamu masih nempel di pola lama itu, kamu kehilangan setengah kekuatan SwiftUI modern. Panduan ini akan membongkar pola NavigationStack yang biasa saya pakai di production app, lengkap dengan routing type-safe, deep link parsing, integrasi NavigationSplitView untuk iPad, plus catatan VoiceOver yang sering dilupakan.

  • NavigationStack menggantikan NavigationView sepenuhnya sejak iOS 16 dan jadi default di iOS 26, dengan API navigationDestination(for:) yang type-safe.
  • NavigationPath adalah single source of truth untuk stack. Kamu bisa push, pop, dan reset secara programmatic dengan binding biasa.
  • iOS 26 menambahkan scrollEdgeEffect, integrasi Liquid Glass pada toolbar, dan animasi transisi yang lebih halus lewat matchedTransitionSource.
  • Deep link bisa di-parse menjadi sekumpulan route enum dan langsung disuntikkan ke NavigationPath tanpa pakai delegate atau coordinator manual.
  • VoiceOver butuh navigationTitle yang konsisten dan accessibilityHeading(.h1) di setiap layar tujuan supaya fokus berpindah dengan benar.
  • Untuk iPad dan Mac Catalyst, kombinasikan NavigationSplitView dengan NavigationStack di kolom detail, bukan satu menggantikan yang lain.

NavigationStack adalah container yang merepresentasikan tumpukan layar dalam satu hierarki, di mana setiap layar baru di-push di atasnya dan bisa di-pop kembali. Berbeda dengan NavigationView lama yang menggabungkan dua kasus penggunaan berbeda (stack di iPhone, split view di iPad) dengan API yang membingungkan, NavigationStack berfokus hanya pada satu pekerjaan, yaitu mengelola stack push/pop.

Sejak iOS 16, Apple menandai NavigationView sebagai deprecated untuk navigasi stack-based. Di iOS 26, banyak API toolbar dan transisi baru (termasuk Liquid Glass blending) hanya bekerja saat layar dibungkus di dalam NavigationStack. Kalau kamu sedang baca artikel saya tentang TabView baru di SwiftUI iOS 26, ingat bahwa setiap tab seharusnya punya NavigationStack-nya sendiri, bukan satu NavigationStack yang membungkus seluruh aplikasi.

Bentuk paling sederhana terlihat seperti ini.

import SwiftUI

struct ArticleListView: View {
    let articles: [Article]

    var body: some View {
        NavigationStack {
            List(articles) { article in
                NavigationLink(article.title, value: article)
            }
            .navigationTitle("Artikel")
            .navigationDestination(for: Article.self) { article in
                ArticleDetailView(article: article)
            }
        }
    }
}

Perhatikan pola NavigationLink(_, value:) dan navigationDestination(for:). Inilah yang membuat NavigationStack type-safe: kamu mengaitkan tipe nilai (misalnya Article) ke layar tujuan, bukan menanam NavigationLink(destination:) berisi View hardcoded.

Membangun Type-Safe Routing dengan navigationDestination

Pola routing yang saya rekomendasikan untuk app berukuran sedang ke atas adalah membuat satu enum Route yang mendaftar semua tujuan yang valid. Dengan begitu, setiap layar tidak perlu tahu detail layar lain. Cukup teruskan nilai enum ke NavigationPath.

enum Route: Hashable {
    case articleDetail(id: UUID)
    case authorProfile(slug: String)
    case settings
    case bookmarks
}

struct RootView: View {
    @State private var path = NavigationPath()

    var body: some View {
        NavigationStack(path: $path) {
            HomeView()
                .navigationDestination(for: Route.self) { route in
                    destination(for: route)
                }
        }
    }

    @ViewBuilder
    private func destination(for route: Route) -> some View {
        switch route {
        case .articleDetail(let id):
            ArticleDetailView(articleId: id)
        case .authorProfile(let slug):
            AuthorProfileView(slug: slug)
        case .settings:
            SettingsView()
        case .bookmarks:
            BookmarksView()
        }
    }
}

Pola ini punya tiga keuntungan besar. Kompiler memaksa kita menangani setiap case (exhaustiveness), tujuan baru cukup ditambahkan di satu tempat, dan deep link parser hanya perlu mengembalikan [Route] alih-alih some View. NavigationPath sendiri menerima nilai apa pun yang Hashable, jadi kamu bisa mencampur beberapa enum atau bahkan model langsung. Meski begitu, saya selalu menyarankan satu enum tunggal untuk kebersihan arsitektur.

NavigationPath adalah type-erased array yang menyimpan urutan tujuan saat ini. Karena ia @State binding biasa, kita bisa memanipulasinya dari mana saja melalui environment, observable model, atau langsung lewat parameter binding.

@Observable
final class Router {
    var path = NavigationPath()

    func push(_ route: Route) {
        path.append(route)
    }

    func popToRoot() {
        path.removeLast(path.count)
    }

    func replace(with routes: [Route]) {
        path = NavigationPath()
        routes.forEach { path.append($0) }
    }
}

struct RootView: View {
    @State private var router = Router()

    var body: some View {
        NavigationStack(path: $router.path) {
            HomeView()
                .environment(router)
                .navigationDestination(for: Route.self) { route in
                    destination(for: route)
                }
        }
    }
}

Sekarang dari layar mana pun saya bisa memanggil router.push(.settings) tanpa harus mengakses NavigationLink. Pola ini juga membuka pintu untuk coordinator-like behaviour: tombol "Selesai" di alur multi-langkah cukup memanggil router.popToRoot(). Kalau kamu pernah menulis observable model dengan macro @Observable di Swift 6.2, ini bersinergi dengan pendekatan yang saya bahas di artikel approachable concurrency Swift 6.2, yaitu model yang ringan, observable, dan bisa diakses dari mana saja.

Cara paling rapi untuk menangani deep link dengan NavigationStack adalah mem-parse URL menjadi [Route] kemudian mengganti seluruh NavigationPath dengan array tersebut. Dengan pola ini, satu URL bisa membawa pengguna langsung ke layar yang dalam (deep) tanpa kita perlu menulis kode push manual berlapis. (Saya pernah ketemu bug aneh waktu pakai pola push-bertingkat dari onOpenURL: animasinya saling tumpang tindih sehingga state akhir tidak konsisten. Replace via NavigationPath menghilangkan masalah itu sepenuhnya.)

extension Router {
    func handle(url: URL) {
        guard let components = URLComponents(url: url, resolvingAgainstBaseURL: false) else {
            return
        }
        let routes = parse(components: components)
        replace(with: routes)
    }

    private func parse(components: URLComponents) -> [Route] {
        let parts = components.path.split(separator: "/").map(String.init)
        switch parts.first {
        case "article":
            if let idString = parts.dropFirst().first,
               let id = UUID(uuidString: idString) {
                return [.articleDetail(id: id)]
            }
        case "author":
            if let slug = parts.dropFirst().first {
                return [.authorProfile(slug: slug)]
            }
        case "settings":
            return [.settings]
        default:
            break
        }
        return []
    }
}

struct RootView: View {
    @State private var router = Router()

    var body: some View {
        NavigationStack(path: $router.path) {
            HomeView()
                .environment(router)
                .navigationDestination(for: Route.self) { route in
                    destination(for: route)
                }
        }
        .onOpenURL { url in
            router.handle(url: url)
        }
    }
}

Karena NavigationPath bersifat Codable ketika semua nilainya conform ke Codable, kamu juga bisa menyimpan state navigasi ke UserDefaults atau SceneStorage dan memulihkannya saat aplikasi dibuka kembali. Fitur ini sering disebut state restoration. Untuk detail format encoding, periksa dokumentasi NavigationPath di Apple Developer.

Kombinasi NavigationStack dan NavigationSplitView di iPad

Pertanyaan yang sering saya dapat: "kalau di iPad pakai NavigationSplitView, NavigationStack-nya buat apa?" Jawabannya, NavigationSplitView mengatur kolom (sidebar, content, detail), sedangkan NavigationStack mengatur tumpukan di dalam tiap kolom, terutama kolom detail.

struct RootView: View {
    @State private var selectedCategory: Category?
    @State private var detailPath = NavigationPath()

    var body: some View {
        NavigationSplitView {
            CategorySidebar(selection: $selectedCategory)
        } detail: {
            NavigationStack(path: $detailPath) {
                if let category = selectedCategory {
                    ArticleListView(category: category)
                        .navigationDestination(for: Article.self) { article in
                            ArticleDetailView(article: article)
                        }
                } else {
                    ContentUnavailableView("Pilih kategori", systemImage: "tray")
                }
            }
        }
    }
}

Pola ini bekerja mulus di iPhone (collapse jadi stack tunggal otomatis), iPad (dua atau tiga kolom), dan Mac Catalyst. Saya juga sering memasangkan ini dengan ContentUnavailableView untuk placeholder kosong, sebuah view bawaan iOS 17+ yang sekarang jadi standar de facto untuk "empty state" di SwiftUI.

Fitur Baru NavigationStack di iOS 26

iOS 26 membawa beberapa peningkatan yang berdampak langsung ke pengalaman navigasi. Pertama, scrollEdgeEffect kini menjadi default pada toolbar di dalam NavigationStack. Efek fade halus saat konten menggulir di bawah navigation bar tidak perlu lagi ditangani manual dengan UIScrollEdgeAppearance.

Kedua, matchedTransitionSource memungkinkan transisi "hero" antar layar (mirip animasi shared element di Android) yang berpadu mulus dengan estetika Liquid Glass. Kamu bisa membaca eksplorasi mendalam saya soal material baru ini di panduan lengkap Liquid Glass di SwiftUI.

struct ArticleListView: View {
    @Namespace private var transition

    var body: some View {
        NavigationStack {
            List(articles) { article in
                NavigationLink(value: article) {
                    ArticleRow(article: article)
                        .matchedTransitionSource(id: article.id, in: transition)
                }
            }
            .navigationDestination(for: Article.self) { article in
                ArticleDetailView(article: article)
                    .navigationTransition(.zoom(sourceID: article.id, in: transition))
            }
        }
    }
}

Ketiga, NavigationStack di iOS 26 menerima modifier .toolbarTitleDisplayMode(.inlineLarge) baru. Perilaku large title yang menyusut tetap inline saat pengguna menggulir. Ini sangat membantu di app dengan banyak layar untuk menjaga ruang vertikal. Untuk daftar lengkap perubahan API, periksa catatan rilis SwiftUI di developer.apple.com.

Aksesibilitas dan VoiceOver yang Sering Dilupakan

Setiap kali ada layar baru di-push, VoiceOver seharusnya memindahkan fokusnya ke elemen heading utama layar tersebut. Tanpa navigationTitle yang jelas, fokus VoiceOver bisa berakhir di tombol "Kembali". Pengalaman yang membingungkan, dan jujur, melelahkan untuk pengguna yang mengandalkan screen reader.

struct ArticleDetailView: View {
    let article: Article

    var body: some View {
        ScrollView {
            VStack(alignment: .leading, spacing: 16) {
                Text(article.title)
                    .font(.largeTitle.bold())
                    .accessibilityAddTraits(.isHeader)
                    .accessibilityHeading(.h1)

                Text(article.body)
            }
            .padding()
        }
        .navigationTitle(article.title)
        .navigationBarTitleDisplayMode(.inline)
        .accessibilityElement(children: .contain)
    }
}

Saya juga selalu menambahkan accessibilityHeading(.h1) di judul layar dan .h2 di section heading utama. Dengan begitu, pengguna VoiceOver bisa menavigasi cepat lewat rotor "Headings". Untuk transisi yang melibatkan matchedTransitionSource, pertimbangkan menambahkan .accessibilityReduceMotion guard supaya kamu menyajikan transisi yang lebih datar saat pengguna mengaktifkan "Reduce Motion" di Settings. Guideline ini ditegaskan ulang oleh Apple di Human Interface Guidelines bagian Motion.

Kesalahan Umum yang Sering Saya Temukan

Setelah me-review puluhan PR yang berhubungan dengan navigasi, ini lima jebakan yang paling sering muncul:

  • Membungkus seluruh aplikasi dengan satu NavigationStack di luar TabView. Akibatnya, push dari tab A menyebabkan tab B ikut terdorong. Selalu beri masing-masing tab NavigationStack tersendiri.
  • Memasang navigationDestination di dalam loop atau view bersyarat. SwiftUI hanya mendaftarkan satu handler per tipe. Gunakan sekali saja di level root stack.
  • Memakai NavigationLink lama (destination:) ber-campur dengan value:. Ini bikin NavigationPath tidak sinkron dengan stack visual.
  • Lupa membuat Route conform ke Hashable + Codable. Tanpa Codable, kamu tidak bisa state-restore NavigationPath. Saya pernah ketemu bug ini persis waktu shipping app ke TestFlight, dan menemukannya cuma setelah crash report yang aneh masuk dari beta tester.
  • Animasi push tanpa matchedTransitionSource. Di iOS 26, kamu kehilangan tampilan modern Liquid Glass. Gampang banget memperbaikinya, sayang kalau dilewatkan. Pendekatan animasi kustom juga bisa dirangkai dengan macro @Animatable di SwiftUI iOS 26 untuk efek transisi shape yang halus.

Pertanyaan yang Sering Diajukan

Apa perbedaan NavigationStack dan NavigationView di SwiftUI?

NavigationView adalah API lama yang menggabungkan stack dan split layout dengan perilaku platform-dependent yang membingungkan. NavigationStack berfokus hanya pada tumpukan push/pop, mendukung routing type-safe lewat navigationDestination(for:), dan jadi prasyarat untuk fitur baru iOS 26 seperti matchedTransitionSource dan scrollEdgeEffect.

Bagaimana cara mereset NavigationStack ke layar root?

Gunakan binding NavigationPath dan panggil path.removeLast(path.count) atau langsung set ulang path = NavigationPath(). Karena path adalah single source of truth, satu baris kode itu sudah cukup untuk menutup seluruh tumpukan dan kembali ke root.

Bisakah NavigationStack di-state-restore setelah aplikasi ditutup?

Bisa, asalkan semua nilai yang ada di NavigationPath conform ke Codable. Simpan path ke SceneStorage atau UserDefaults, lalu rekonstruksi saat onAppear. iOS 26 menambahkan helper untuk encoding yang lebih efisien lewat NavigationPath.CodableRepresentation.

Apakah NavigationStack bekerja di watchOS dan tvOS?

Ya. NavigationStack tersedia di iOS 16+, iPadOS 16+, macOS 13+, watchOS 9+, dan tvOS 16+. Pola yang dibahas di artikel ini berlaku universal, meskipun transisi visual tertentu (seperti matchedTransitionSource) hanya diaktifkan pada iOS/iPadOS 26 dan macOS Tahoe.

Kapan harus pakai NavigationSplitView dibanding NavigationStack?

Pakai NavigationSplitView ketika app punya konsep sidebar plus detail (apps tipe Mail, Notes, atau dashboard). Pakai NavigationStack untuk alur linear push/pop. Keduanya bisa dikombinasi: NavigationSplitView sebagai layout kolom, dan NavigationStack di dalam kolom detail untuk drill-down lebih dalam.

Ava Thompson
Tentang Penulis Ava Thompson

SwiftUI engineer focused on declarative animations and accessibility. Will fight you about navigation stacks.

Artikel Terkait