Skip to content
tezvyn:

Implement SwiftUI navigation between list and detail with product ID

Source: developer.apple.comEasyHow cards are made

Implement SwiftUI navigation between list and detail with product ID

Tests modern SwiftUI navigation and clean data flow. Great answer: NavigationStack with NavigationLink(value:) and navigationDestination(for:), plus a bound path for programmatic control.

What's really being asked

Even though this is framed as a beginner task, at the senior level the interviewer is checking whether you default to the modern NavigationStack API introduced in iOS 16 or fall back to legacy patterns. They want to see that you separate routing state from view state, pass identifiers rather than heavy objects, and think about programmatic control and deep linking from the start.

The full answer

First, wrap the root view in a NavigationStack. Second, use the value-based NavigationLink init where the list cell receives a product ID and the link carries that value. Third, attach a navigationDestination modifier to the stack for the ID type so SwiftUI knows which view to render. Fourth, hold the navigation state in a bound array or NavigationPath, typically stored in an observable router or the list view model, so pushes and pops can be driven programmatically. Fifth, inject only the ID into the detail view and let it resolve the full product through its own dependency, keeping the list decoupled.

The mistakes people make

Using NavigationView instead of NavigationStack, which triggers the old split-view behavior on iPad and lacks programmatic path control. Relying on NavigationLink(destination:isActive:) or the isPresented pattern, which breaks state restoration and deep linking. Passing the entire product model into the detail view instead of the ID, which couples the list to the detail data requirements and complicates previews and testing. Hardcoding the destination view inside the list row rather than declaring it at the stack level.

What usually comes next

How would you support deep linking directly to a product detail? How would you clear the stack and reset to the root? What changes if the product catalog lives in a shared model actor or Core Data context? How do you handle conditional destinations when the same ID type might map to different detail views?

A concrete example

Imagine a ProductListView with a view model that owns a NavigationPath named path. In the body, the list iterates over product IDs and each row contains a NavigationLink(value: id) label. The NavigationStack has a modifier navigationDestination(for: Product.ID.self) that instantiates ProductDetailView(id:). When a row is tapped, SwiftUI pushes the detail view. The view model can later call path.removeLast() or path.append(anotherId) to navigate backward or forward without any view-layer intervention.

Interview question

Which approach best implements modern SwiftUI navigation from a product list to a detail view using only an identifier?

  • a.Use NavigationStack but place NavigationLink(destination: ProductDetailView(id:)) directly inside each list row.
  • b.Use NavigationStack with NavigationLink(destination:isActive:) while passing the complete Product object to the detail view.
  • c.Wrap the list in NavigationView and pass the full Product model through NavigationLink(destination:).
  • d.Use NavigationStack with NavigationLink(value: id), a stack-level navigationDestination(for: Product.ID.self), and a bound NavigationPath.Correct
Why?

This uses the iOS 16 value-based API that separates routing state from views, passes only identifiers for loose coupling, and enables programmatic control via NavigationPath. Option C is tempting but wrong because NavigationView triggers legacy split-view behavior on iPad and lacks bound path control.

Just read this? Test yourself on what you have been reading.

Read the original → developer.apple.com

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on swiftui — each one lists the topics its interview covers.

See open roles