Passing Data Between Views and Navigation Destinations in iOS

Course: iOS App Development

Topic: Passing Data Between Views and Navigation Destinations

Course Link: iOS App Development Training at JustAcademy

Demo Link: Register for a Course Demo

Official Website: JustAcademy

1. Introduction

Passing data between views and navigation destinations is an essential concept in iOS app development. Most applications contain multiple screens that need to share information. For example, a shopping application may display a list of products, open a product details screen when an item is selected, and pass the selected product's name, price, image, and description to the destination view.

In SwiftUI, data can be passed between views using properties, initializers, bindings, observable models, environment values, and navigation destinations. Choosing the appropriate technique helps developers build applications that are maintainable, responsive, and easy to test.

SwiftUI supports declarative navigation through components such as NavigationStack, NavigationLink, and .navigationDestination(for:destination:). These APIs allow applications to navigate between screens while providing the data required by each destination.

2. Learning Objectives

• Understand how data flows between SwiftUI views.
• Pass simple values and model objects through view initializers.
• Use @Binding to share editable state between parent and child views.
• Understand when to use @State, @Observable, and @Environment.
• Navigate between screens using NavigationStack and NavigationLink.
• Pass model data to navigation destinations.
• Implement type-based navigation using .navigationDestination(for:).
• Understand navigation paths, data ownership, and common errors.
• Apply data-passing techniques in a practical iOS application.

3. Understanding Views and Data Flow

A view represents a part of the user interface. A SwiftUI application commonly separates its interface into smaller views, each responsible for displaying or managing a specific part of the application.

Consider an application with three screens:

1. Product List View: Displays available products.
2. Product Details View: Displays information about the selected product.
3. Cart View: Displays products added to the shopping cart.

When the user selects a product, the application must transfer the relevant product information from the list screen to the details screen. When the user adds the product to the cart, the application may update shared application state.

3.1 Common Data-Passing Techniques

4. Passing Data Through View Initializers

4.1 What Is Initializer-Based Data Passing?

Initializer-based data passing means supplying values when creating a new view. A destination view declares properties that receive the required information. SwiftUI uses those properties to render the destination.

This technique is straightforward and works well when the destination needs information that should be provided by its parent.

4.2 Passing a String to Another View

import SwiftUI

struct WelcomeView: View {
    var userName: String

    var body: some View {
        VStack(spacing: 16) {
            Text("Welcome, \(userName)!")
                .font(.title)

            Text("You are viewing your profile.")
        }
        .padding()
    }
}

struct HomeView: View {
    var body: some View {
        WelcomeView(userName: "Aarav")
    }
}

4.3 Explanation

• WelcomeView declares a property named userName.
• HomeView creates the destination view and supplies the value "Aarav".
• The destination uses string interpolation to display the supplied name.
• The value is passed when the view is initialized.

Use initializer properties for values that a view needs to display but does not necessarily need to modify. Value types such as strings, integers, and structures are common choices.

4.4 Passing Multiple Values

import SwiftUI

struct StudentDetailsView: View {
    let studentName: String
    let courseName: String
    let score: Int

    var body: some View {
        VStack(alignment: .leading, spacing: 12) {
            Text("Student Details")
                .font(.title)

            Text("Name: \(studentName)")
            Text("Course: \(courseName)")
            Text("Score: \(score)")
        }
        .padding()
    }
}

struct StudentHomeView: View {
    var body: some View {
        StudentDetailsView(
            studentName: "Priya",
            courseName: "iOS Development",
            score: 92
        )
    }
}

Multiple properties allow the destination to receive all the information it requires. When many related values must be passed together, consider defining a model structure instead of adding numerous unrelated parameters.

5. Passing Model Objects Between Views

5.1 Why Use Model Objects?

A model object groups related information into a single type. Instead of passing a product's name, price, and description separately, a developer can create a Product model and pass the entire product.

This approach makes the code easier to understand, maintain, and extend when the application grows.

5.2 Creating a Product Model

import SwiftUI

struct Product: Identifiable {
    let id: Int
    let name: String
    let price: Double
    let description: String
}

struct ProductDetailsView: View {
    let product: Product

    var body: some View {
        VStack(alignment: .leading, spacing: 12) {
            Text(product.name)
                .font(.title)

            Text("Price: ₹\(product.price, specifier: "%.2f")")
                .font(.headline)

            Text(product.description)
        }
        .padding()
    }
}

5.3 Supplying a Model to a View

struct ProductHomeView: View {
    private let product = Product(
        id: 101,
        name: "Wireless Headphones",
        price: 2499.00,
        description: "Comfortable wireless headphones for daily use."
    )

    var body: some View {
        ProductDetailsView(product: product)
    }
}

Here, the ProductDetailsView receives one product value. It can access individual fields through expressions such as product.name and product.price.

5.4 Benefits of Model-Based Data Passing

• Groups related data into a meaningful type.
• Reduces the number of parameters passed between views.
• Makes destination views easier to reuse.
• Improves code readability and type safety.
• Allows model definitions to be shared across list, detail, and editing screens.

6. Passing Data Through NavigationLink

6.1 What Is NavigationLink?

NavigationLink creates a navigation action that takes the user to another view. Within a NavigationStack, a link can display a destination view when the user selects it.

The destination can receive a value directly through its initializer. This is useful when a list contains multiple items and each item must open its own details screen.

6.2 NavigationLink with a Model Object

import SwiftUI

struct NavigationProduct: Identifiable {
    let id: Int
    let name: String
    let price: Double
}

struct ProductListScreen: View {
    private let products = [
        NavigationProduct(id: 1, name: "Keyboard", price: 1499),
        NavigationProduct(id: 2, name: "Mouse", price: 799),
        NavigationProduct(id: 3, name: "Monitor", price: 12999)
    ]

    var body: some View {
        NavigationStack {
            List(products) { product in
                NavigationLink {
                    ProductInfoScreen(product: product)
                } label: {
                    HStack {
                        Text(product.name)
                        Spacer()
                        Text("₹\(product.price, specifier: "%.2f")")
                    }
                }
            }
            .navigationTitle("Products")
        }
    }
}

struct ProductInfoScreen: View {
    let product: NavigationProduct

    var body: some View {
        VStack(alignment: .leading, spacing: 12) {
            Text(product.name)
                .font(.largeTitle)

            Text("Price: ₹\(product.price, specifier: "%.2f")")
        }
        .padding()
        .navigationTitle("Product Details")
    }
}

6.3 How the Navigation Works

1. The application creates a list of products.
2. The List iterates over the product collection.
3. Each row creates a NavigationLink for its product.
4. When the user selects a row, the link opens ProductInfoScreen.
5. The selected product is passed to the destination's initializer.
6. The destination displays the selected product's information.

This technique is suitable for simple navigation flows because the destination and its data are declared together.

7. Using NavigationStack and navigationDestination

7.1 Understanding NavigationStack

NavigationStack manages a navigation hierarchy in SwiftUI. It allows users to move forward to destination views and return to previous screens. It also supports programmatic navigation using a navigation path or a bound collection of navigation values.

For data-driven navigation, developers can create a link that carries a value and register a destination for that value's type using .navigationDestination(for:).

7.2 Navigation with a Typed Value

import SwiftUI

struct ProductRoute: Hashable {
    let productID: Int
}

struct NavigationDestinationExample: View {
    private let products = [
        NavigationProduct(id: 1, name: "Keyboard", price: 1499),
        NavigationProduct(id: 2, name: "Mouse", price: 799)
    ]

    var body: some View {
        NavigationStack {
            List(products) { product in
                NavigationLink(
                    value: ProductRoute(productID: product.id)
                ) {
                    Text(product.name)
                }
            }
            .navigationTitle("Products")
            .navigationDestination(for: ProductRoute.self) { route in
                ProductRouteDetailsView(productID: route.productID)
            }
        }
    }
}

struct ProductRouteDetailsView: View {
    let productID: Int

    var body: some View {
        VStack(spacing: 12) {
            Text("Product Details")
                .font(.title)

            Text("Product ID: \(productID)")
        }
        .padding()
    }
}

In this example, the link carries a ProductRoute value. The navigation stack finds the registered destination for that type and passes the route to the destination closure. The destination then receives the product identifier.

7.3 Why Use a Route Type?

• Separates navigation decisions from destination presentation.
• Allows links to carry small, meaningful navigation values.
• Supports programmatic navigation through a path.
• Can make navigation logic easier to test.
• Works well for applications with several screens and navigation flows.

The route type must conform to Hashable when used with the value-based navigation APIs. The destination registration must match the type of value supplied by the link.

8. Passing Data Using NavigationPath

8.1 What Is NavigationPath?

NavigationPath represents a navigation stack containing values of different supported types. It is useful when an application needs to navigate programmatically or maintain a navigation flow with multiple kinds of destinations.

8.2 Programmatic Navigation Example

import SwiftUI

struct CategoryRoute: Hashable {
    let categoryName: String
}

struct ItemRoute: Hashable {
    let itemID: Int
}

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

    var body: some View {
        NavigationStack(path: $path) {
            VStack(spacing: 20) {
                Button("Open Electronics") {
                    path.append(
                        CategoryRoute(categoryName: "Electronics")
                    )
                }

                Button("Open Item 101") {
                    path.append(ItemRoute(itemID: 101))
                }
            }
            .navigationTitle("Home")
            .navigationDestination(for: CategoryRoute.self) { route in
                Text("Category: \(route.categoryName)")
                    .font(.title)
            }
            .navigationDestination(for: ItemRoute.self) { route in
                Text("Item ID: \(route.itemID)")
                    .font(.title)
            }
        }
    }
}

8.3 Explanation

• @State private var path = NavigationPath() stores the current navigation path.
• NavigationStack(path: $path) connects the stack to the path state.
• path.append(...) pushes a new route value onto the stack.
• Each .navigationDestination(for:) handles one registered route type.
• When the user navigates back, SwiftUI updates the navigation stack and its path.

Use NavigationPath when the stack needs heterogeneous route values. For a simple flow containing only one route type, a typed array may be easier to understand and maintain.

9. Passing Data with @Binding

9.1 What Is @Binding?

@Binding creates a connection to state stored elsewhere. It allows a child view to read and update a value owned by its parent. A binding does not create an independent copy of the state; it provides access to the existing source of truth.

Bindings are particularly useful for editable forms, toggles, text fields, and settings screens where child views must update values displayed by their parent.

9.2 Parent and Child View Example

import SwiftUI

struct ParentProfileView: View {
    @State private var userName = "Ananya"

    var body: some View {
        VStack(spacing: 20) {
            Text("Parent Name: \(userName)")

            ProfileNameEditor(userName: $userName)
        }
        .padding()
    }
}

struct ProfileNameEditor: View {
    @Binding var userName: String

    var body: some View {
        VStack(spacing: 12) {
            TextField("Enter your name", text: $userName)
                .textFieldStyle(.roundedBorder)

            Text("Child View: \(userName)")
        }
    }
}

9.3 How @Binding Works

1. The parent view owns the name using @State.
2. The parent passes a binding using $userName.
3. The child receives the binding through @Binding.
4. When the user edits the text field, the parent-owned value changes.
5. SwiftUI updates views that depend on the changed state.

9.4 When to Use @Binding

• When a child view needs to edit state owned by its parent.
• When several controls need to update the same value.
• When building reusable form components.
• When a destination should return edits to a parent-owned value.

Do not use a binding merely to pass read-only data. A normal property is simpler when the destination only needs to display a value.

10. Sharing Data with Observable Models

10.1 Understanding Observable State

As applications become more complex, multiple views may need to access the same changing data. Instead of passing many independent values through several layers, developers can place related state in an observable model.

In modern SwiftUI applications using supported OS versions, the Observation framework and the @Observable macro provide a convenient way to create observable reference models. The older ObservableObject and @Published approach remains common in existing projects and is useful when targeting compatible deployment requirements.

10.2 Example Using @Observable

import SwiftUI
import Observation

@Observable
final class UserProfile {
    var name = "Riya"
    var email = "[email protected]"
}

struct ObservableProfileView: View {
    @State private var profile = UserProfile()

    var body: some View {
        NavigationStack {
            VStack(spacing: 16) {
                Text("Name: \(profile.name)")
                Text("Email: \(profile.email)")

                NavigationLink("Edit Profile") {
                    ObservableProfileEditor(profile: profile)
                }
            }
            .padding()
            .navigationTitle("Profile")
        }
    }
}

struct ObservableProfileEditor: View {
    var profile: UserProfile

    var body: some View {
        Form {
            TextField("Name", text: $profile.name)
            TextField("Email", text: $profile.email)
        }
        .navigationTitle("Edit Profile")
    }
}

The parent owns the observable model through @State and passes the same reference to the editor. The editor can update observable properties, and views that read those properties can refresh when the values change.

Platform note: The @Observable approach requires an appropriate Swift and OS deployment target. For older supported targets, consider the ObservableObject pattern instead.

10.3 Older ObservableObject Approach

import SwiftUI

final class LegacyProfileModel: ObservableObject {
    @Published var name = "Riya"
    @Published var email = "[email protected]"
}

struct LegacyProfileView: View {
    @StateObject private var profile = LegacyProfileModel()

    var body: some View {
        NavigationStack {
            VStack(spacing: 16) {
                Text(profile.name)
                Text(profile.email)

                NavigationLink("Edit Profile") {
                    LegacyProfileEditor(profile: profile)
                }
            }
            .padding()
        }
    }
}

struct LegacyProfileEditor: View {
    @ObservedObject var profile: LegacyProfileModel

    var body: some View {
        Form {
            TextField("Name", text: $profile.name)
            TextField("Email", text: $profile.email)
        }
    }
}

In this pattern, @StateObject creates and owns the observable object, while @ObservedObject observes an object supplied by another view. The @Published properties notify observing views when they change.

11. Using Environment to Share Data

Environment values allow information or dependencies to be made available to views lower in the view hierarchy without explicitly passing them through every intermediate view.

For example, an application may provide a shared observable settings model through the environment. Descendant views can then access it when needed.

import SwiftUI
import Observation

@Observable
final class AppSettings {
    var displayName = "Guest"
    var darkModeEnabled = false
}

struct SettingsRootView: View {
    @State private var settings = AppSettings()

    var body: some View {
        NavigationStack {
            SettingsDetailsView()
        }
        .environment(settings)
    }
}

struct SettingsDetailsView: View {
    @Environment(AppSettings.self) private var settings

    var body: some View {
        Form {
            TextField("Display Name", text: $settings.displayName)

            Toggle(
                "Enable Dark Mode",
                isOn: $settings.darkModeEnabled
            )
        }
        .navigationTitle("Settings")
    }
}

The root view provides the settings model through the environment. A descendant view retrieves the same model by type. This reduces repeated parameter passing, but environment dependencies should be used thoughtfully so that a view's requirements remain understandable.

12. Passing Data to a Destination and Returning Results

Sometimes a destination needs to edit information and return the result to its parent. One straightforward approach is to pass a binding. Another approach is to use a callback closure that reports the result to the presenting view.

12.1 Returning a Value Through a Callback

import SwiftUI

struct NameEditorView: View {
    @Environment(\.dismiss) private var dismiss

    @State private var editedName: String
    let onSave: (String) -> Void

    init(
        initialName: String,
        onSave: @escaping (String) -> Void
    ) {
        _editedName = State(initialValue: initialName)
        self.onSave = onSave
    }

    var body: some View {
        Form {
            TextField("Name", text: $editedName)

            Button("Save") {
                onSave(editedName)
                dismiss()
            }
        }
        .navigationTitle("Edit Name")
    }
}

struct NameHomeView: View {
    @State private var name = "Arjun"

    var body: some View {
        NavigationStack {
            VStack(spacing: 16) {
                Text("Current Name: \(name)")

                NavigationLink("Edit Name") {
                    NameEditorView(initialName: name) { newName in
                        name = newName
                    }
                }
            }
            .padding()
        }
    }
}

The destination maintains temporary editable state and invokes onSave when the user taps Save. The parent receives the new value and updates its state. This pattern is useful when the destination should return a result only after an explicit action.

13. Data Passing Best Practices

• Keep a clear source of truth: Decide which view or model owns each piece of state.
• Prefer initializer properties for read-only values: Pass only the information a destination needs.
• Use bindings for shared editable state: Avoid duplicating state when parent and child must edit the same value.
• Use model types for related data: A well-designed structure is easier to maintain than a long list of unrelated parameters.
• Use route types for complex navigation: Represent navigation intent with identifiable, hashable route values.
• Avoid oversized navigation payloads: Pass an identifier when the destination can safely retrieve the full record from a data store or repository.
• Handle missing data: A record may have been deleted or become unavailable before its destination opens.
• Validate external navigation: Deep links and restored navigation state should not be assumed to contain valid or authorized data.
• Separate navigation from business logic: Keep data fetching, validation, and persistence out of presentation-only code where practical.
• Test state changes: Confirm that updates appear in every view that depends on the same data.

14. Common Errors and Troubleshooting

15. Practical Project: Student Management App

Project Objective

Create a simple student management application that demonstrates passing data between a list screen, a details destination, and an editing screen.

Project Requirements

• Display a list of students.
• Show each student's name and course.
• Open a details screen when a student is selected.
• Pass the selected student's information to the destination.
• Provide an editing interface for updating a student's name.
• Use state or a shared model to reflect the updated value.
• Display an appropriate message if the selected student is unavailable.

Sample Student Model

struct Student: Identifiable, Hashable {
    let id: Int
    var name: String
    var course: String
    var score: Int
}

Suggested Screen Structure

Project Workflow

1. Create a Student model.
2. Build a list using List and NavigationLink.
3. Pass the selected student or its identifier to the details destination.
4. Add an editing screen that uses a binding, observable model, or callback.
5. Update the correct source of truth after saving.
6. Test navigation, editing, back navigation, and missing-record scenarios.

16. Practice Exercises

Exercise 1: User Profile Navigation

Create a home screen containing a user's name, email, and location. Open a profile details screen and pass all three values through the destination initializer.

Exercise 2: Product Details

Create a product model with an identifier, name, price, and description. Display the products in a list and navigate to a details screen for the selected product.

Exercise 3: Editable Settings

Build a parent view with a username and a child editor that changes the username using @Binding.

Exercise 4: Typed Navigation

Create a custom Hashable route type and register its destination using .navigationDestination(for:).

Exercise 5: Programmatic Navigation

Use NavigationPath to open two different destination types from buttons on the same screen.

Exercise 6: Return an Edited Value

Build an editor that uses a callback to return a new value to its parent only when the Save button is tapped.

17. Interview Questions and Answers

Q1. What does passing data between views mean?

It means transferring values or providing shared state so that one view can display or modify information required by another view.

Q2. How can you pass data to a SwiftUI view?

You can pass data through initializer properties, bindings, observable models, environment values, or navigation values, depending on the ownership and sharing requirements.

Q3. What is the purpose of NavigationStack?

NavigationStack manages a hierarchical navigation flow and supports both link-based and programmatic navigation.

Q4. What is the difference between NavigationLink and navigationDestination?

NavigationLink initiates navigation. .navigationDestination(for:) registers the destination view for a particular navigation value type.

Q5. Why should a route type conform to Hashable?

Value-based navigation uses hashable values to identify and manage navigation destinations. A custom route type must meet the protocol requirements of the navigation API.

Q6. What is the difference between @State and @Binding?

@State stores state owned by a view. @Binding provides a connection to state owned elsewhere so that a child can read or modify it.

Q7. When should you pass a model object?

Pass a model object when the destination requires several related values represented by a single meaningful type.

Q8. What is NavigationPath?

NavigationPath represents a navigation stack containing values of different supported types and is useful for programmatic navigation.

Q9. How can a child view return data to its parent?

A child can modify a binding, update a shared observable model, or invoke a callback closure that passes the result to the parent.

Q10. What is the advantage of using an observable model?

An observable model can centralize shared changing data and allow dependent views to refresh when the properties they read change.

Q11. When should you pass an identifier instead of a full model?

Passing an identifier is useful when a destination can retrieve the current record from a repository or data store, particularly when the model is large or may change.

Q12. What is a common cause of incorrect destination data?

A common cause is passing the wrong selected item, using an outdated model, or incorrectly connecting the navigation value to its destination.

18. Quick Revision Checklist

• Use initializer properties to pass values into a view.
• Group related values into model structures.
• Use NavigationStack to manage hierarchical navigation.
• Use NavigationLink to navigate to another view.
• Use .navigationDestination(for:) for typed, value-based navigation.
• Use NavigationPath for programmatic navigation involving multiple route types.
• Use @Binding when a child needs to edit parent-owned state.
• Use observable models for shared state that changes over time.
• Use environment values when appropriate for shared dependencies.
• Keep one clear source of truth for each piece of data.
• Handle missing records and invalid navigation input safely.
• Test data flow, navigation, editing, and back-navigation behavior.

19. Conclusion

Passing data between views and navigation destinations is a fundamental skill in SwiftUI development. Initializer properties provide a simple way to transfer values, bindings allow child views to edit parent-owned state, and observable models support shared data across multiple screens.

For navigation, NavigationStack, NavigationLink, .navigationDestination(for:), and NavigationPath provide flexible ways to connect screens and transfer route information. Selecting the right approach depends on whether the destination needs read-only data, editable state, a shared model, or a navigation identifier.

By maintaining clear data ownership, using type-safe navigation, and handling updates consistently, developers can build reliable and maintainable iOS applications.

20. Additional Learning Resources

• Explore the iOS App Development Course
• Register for a Course Demo
• Visit the JustAcademy Website
• Apple Developer Documentation: NavigationStack
• Apple Developer Documentation: NavigationLink
• Apple Developer Documentation: navigationDestination
• Apple Developer Documentation: Observation