Lists, Navigation and Forms

Pocket Budget has a store, a row view and state that drives the screen. Now it needs to become an app people can use: a list of this month’s expenses, a tap that opens the details, and a plus button that opens a form. Those three patterns (list, push navigation and modal form) make up the skeleton of most iPhone apps you’ve used.

A list of identifiable rows

ExpensesScreen.swift

import SwiftUI

struct ExpensesScreen: View {
    let store: BudgetStore
    @State private var isAdding = false

    var body: some View {
        NavigationStack {
            List {
                ForEach(store.expenses) { expense in
                    NavigationLink(value: expense) {
                        ExpenseRow(expense: expense)
                    }
                }
                .onDelete { offsets in
                    store.delete(at: offsets)
                }
            }
            .overlay {
                if store.expenses.isEmpty {
                    ContentUnavailableView("No expenses yet", systemImage: "tray",
                                           description: Text("Tap + to add your first one."))
                }
            }
            .navigationTitle("Expenses")
            .navigationDestination(for: Expense.self) { expense in
                ExpenseDetail(expense: expense)
            }
            .toolbar {
                Button("Add expense", systemImage: "plus") {
                    isAdding = true
                }
            }
            .sheet(isPresented: $isAdding) {
                AddExpenseView(store: store)
            }
        }
    }
}

That’s the whole main screen; take it one piece at a time. ForEach(store.expenses) produces a row per expense. It needs a stable identity for each element so that, when an expense is inserted or deleted, SwiftUI animates the right row instead of redrawing everything, and that identity is the id that Identifiable requires. .onDelete adds swipe-to-delete and hands you the positions to remove; the store’s delete(at:) is one line, expenses.remove(atOffsets: offsets). That method is defined in SwiftUI, so BudgetStore.swift needs import SwiftUI alongside Observation.

ContentUnavailableView is the system’s standard empty state. An empty list with no explanation looks broken; a short message and a hint at the next action looks finished.

Navigation with values

NavigationStack manages a stack of screens: the list at the bottom, details pushed on top, and the system back button and swipe gesture for free.

Navigation is split into two halves. NavigationLink(value: expense) says what was tapped. .navigationDestination(for: Expense.self) says which screen shows an Expense. The value must be Hashable, which Expense already is. Keeping the two halves apart means the destination is declared once, however many places link to an expense, and it makes programmatic navigation possible:

Swift

@State private var path: [Expense] = []

// In body:
NavigationStack(path: $path) {
    // …the same List and modifiers as above
}

// Anywhere in this view, for example after saving:
path.append(newExpense)    // pushes ExpenseDetail
path.removeAll()           // pops back to the list

The path is plain state, so navigation becomes data you can inspect, test and change from code. That’s how you’d open a specific expense from a notification, or jump back to the root after a multi-step flow. For screens with mixed destination types, NavigationPath plays the same role with type-erased values.

Push navigation and a modal sheet

The detail screen can be a Form used for display, with LabeledContent rows that format values for you:

Swift

struct ExpenseDetail: View {
    let expense: Expense

    var body: some View {
        Form {
            LabeledContent("Amount", value: expense.amount, format: .currency(code: "USD"))
            LabeledContent("Category", value: expense.category.title)
            LabeledContent("Date", value: expense.date, format: .dateTime.day().month().year())
        }
        .navigationTitle(expense.title)
    }
}

A form in a sheet

Pushing is for drilling into content. A sheet is for a self-contained task the user finishes or abandons, like adding an expense. .sheet(isPresented: $isAdding) shows the form whenever isAdding becomes true. Here’s the form:

AddExpenseView.swift

struct AddExpenseView: View {
    let store: BudgetStore
    @Environment(\.dismiss) private var dismiss

    @State private var title = ""
    @State private var amount: Decimal?
    @State private var category: Category = .food
    @State private var date = Date.now

    private var canSave: Bool {
        !title.trimmingCharacters(in: .whitespaces).isEmpty && (amount ?? 0) > 0
    }

    var body: some View {
        NavigationStack {
            Form {
                Section("Details") {
                    TextField("Title", text: $title)
                    TextField("Amount", value: $amount, format: .currency(code: "USD"))
                        .keyboardType(.decimalPad)
                }
                Section {
                    Picker("Category", selection: $category) {
                        ForEach(Category.allCases, id: \.self) { category in
                            Label(category.title, systemImage: category.symbolName)
                                .tag(category)
                        }
                    }
                    DatePicker("Date", selection: $date, in: ...Date.now, displayedComponents: .date)
                }
            }
            .navigationTitle("New Expense")
            .navigationBarTitleDisplayMode(.inline)
            .toolbar {
                ToolbarItem(placement: .cancellationAction) {
                    Button("Cancel") { dismiss() }
                }
                ToolbarItem(placement: .confirmationAction) {
                    Button("Save") {
                        guard let amount else { return }
                        store.add(Expense(title: title, amount: amount, category: category, date: date))
                        dismiss()
                    }
                    .disabled(!canSave)
                }
            }
        }
    }
}

The sheet wraps its form in its own NavigationStack. A sheet is a separate presentation that doesn’t inherit the list’s stack, and without one there’s no bar to hold the title or the Cancel and Save buttons. Placing them with .cancellationAction and .confirmationAction puts them where iOS users expect.

Each field binds to its own @State, so the form is a draft: nothing touches the store until Save. Cancel throws the draft away. That’s value semantics paying off again.

The amount field is the important one. TextField(value:format:) parses what the user types using their locale, so “12,50” in Germany becomes 12.5, and amount only ever holds a successfully parsed number, or nil while there isn’t one. This replaces the lenient Decimal(string:) parsing from the optionals lesson. guard let amount in the Save action unwraps it, and canSave disables the button until both title and amount make sense, so invalid input can’t be saved at all. The in: ...Date.now range stops future dates. dismiss comes from the environment and closes whatever presented this view.

Pocket Budget is now a working app with a real flow from list to detail to form. It forgets everything when you quit, though, and it knows nothing beyond the phone. The final section fixes both, starting with how Swift runs work that takes time.

Lesson at a glance

A list of identifiable rows

Navigation with values

A form in a sheet

Key takeaways

Further reading

Check your understanding

Practice

Wire up the main screen