SwiftUI Tutorial for Beginners (2026)

Before you write a single line of SwiftUI code, there’s a mental shift you need to make. It’s not a big one, but skipping it causes a lot of confusion later. This lesson is about that shift — and it’s entirely conceptual. No code yet.

You’ve been writing Swift in a style called imperative programming. You tell the computer exactly what to do, step by step. “Create a variable. Loop through this array. Call this function.” The computer follows your instructions in sequence. That’s the approach you’ve been using and it works great for logic, data, and algorithms.

SwiftUI uses a completely different approach called declarative programming. Instead of telling the computer how to build your interface step by step, you describe what you want it to look like — and SwiftUI figures out how to make it happen. By the end of this lesson, you’ll have a clear mental model of what that actually means, and why it changes everything about the way you build screens.

The Restaurant Analogy

Here’s the clearest way I know to explain the difference. Imagine you’re hungry.

Imperative approach: You walk into the kitchen, find a pan, turn on the stove, add oil, crack two eggs, wait until the edges set, flip once, plate it, add salt. You are doing every step yourself, in order.

Declarative approach: You sit down at a restaurant and say “I’d like two eggs over easy, please.” You describe the result you want. The kitchen figures out how to make it happen.

SwiftUI is the restaurant. You describe your interface — “I want a blue button, centered on screen, with the text ‘Get Started'” — and SwiftUI handles everything needed to actually draw it. You don’t manage pixels, layout passes, or drawing calls. You just describe the outcome.

What “You Describe, SwiftUI Renders” Actually Means

In SwiftUI, your job is to write code that describes the current state of your interface. SwiftUI watches that description and keeps the screen in sync with it automatically.

Think about a light switch. Imperatively, you’d say: “When someone taps the switch, reach into the screen, find the light bulb image, change its color from gray to yellow, then update the label underneath.” Declaratively, you’d say: “When isOn is true, show a yellow bulb. When it’s false, show a gray bulb.” SwiftUI watches isOn and updates the screen whenever it changes. You describe the two possible states — SwiftUI handles the transitions.

This is one of the biggest reasons SwiftUI code tends to be shorter and easier to read than the older UIKit approach. You’re not writing instructions for every possible change. You’re writing a description of how things should look given any possible state.

Why This Matters for You Right Now

If you try to approach SwiftUI the same way you’d write imperative code, you’ll fight it constantly. You’ll want to “reach in and change” things manually, and you’ll be confused when that doesn’t work the way you expect. The moment you stop thinking about commands and start thinking about descriptions, SwiftUI clicks.

Don’t worry if this still feels a bit abstract. It will become concrete the moment you start writing actual views in Lesson 1.2. This lesson is just making sure the mental model is in place before the code arrives.

One More Thing: Views Are Structs

In SwiftUI, everything you see on screen is a view. A piece of text is a view. A button is a view. An image is a view. Even the invisible containers that arrange other views are views.

Here’s the Swift connection: every SwiftUI view is a struct that conforms to the View protocol. You already know what structs are. A SwiftUI view is just a struct with one required property — body — that returns a description of what should be on screen.

When you open a new SwiftUI project in Xcode, you’ll see a struct called ContentView with a body property already in place. That’s the pattern. Every view you ever build will follow it.

Using AI to Test Your Mental Model

AI tools are great for testing whether you actually understand a concept — not just whether you’ve read about it. Try these prompts to pressure-test what you just learned before moving on to Lesson 1.2.

This is the lesson where things get real. You’re going to place your first views on screen and see them appear in the canvas preview. That moment — when you type a line of code and a button or a piece of text appears instantly on the right side of your screen — is one of those small milestones worth appreciating. It never gets old.

In SwiftUI, every visual element is a view. Text is a view. Images are views. Buttons are views. They’re all structs that conform to the View protocol, and they all live inside the body property of your ContentView. You already know what structs and protocols are — here you’re seeing them used in a very practical, visual context.

By the end of this lesson, you’ll know how to place Text, Image, and Button views in your interface, and you’ll understand the basic structure that every SwiftUI view file shares.

The ContentView Template

When you create a new SwiftUI project in Xcode, it generates a file called ContentView.swift that looks like this:

// Import the SwiftUI framework — this gives you access to all SwiftUI views and tools
import SwiftUI

// Define a struct called ContentView that conforms to the View protocol
struct ContentView: View {

    // body is a computed property that returns what this view looks like
    var body: some View {

        // This is where you place your views — SwiftUI renders whatever you put here
        Text("Hello, world!")
    }
}

The Three Foundation Views

Text Display a string of text on screen

// Text displays any string you pass to it
Text("Welcome to SwiftUI")

Text is the most basic building block in SwiftUI. Pass any String and it renders it on screen in the system font. You’ll chain modifiers onto it to control font size, color, weight, and more — that comes in Lesson 1.3.

Image Display an icon from SF Symbols or an image from your assets

// Use systemName: to load an icon from SF Symbols (Apple's free icon library)
Image(systemName: "star.fill")

// Or load an image you've added to your Assets.xcassets folder
Image("profile-photo")

Image has two common forms. systemName: loads icons from SF Symbols — Apple’s built-in library of thousands of free icons that you can use in any app. The other form loads images you’ve added to your project’s asset catalog. You’ll use SF Symbols constantly throughout your SwiftUI career.

Button A tappable element that runs code when pressed

// Button takes two arguments: an action closure and a label closure
Button(action: {
    // This code runs when the user taps the button
    print("Button tapped!")
}) {
    // This is what the button looks like
    Text("Get Started")
}

Button takes two things: an action (what happens when it’s tapped) and a label (what it looks like). The action is a closure — a block of code that runs when the user taps. The label can be any view, not just text. You’ll see Image icons, combinations of text and icons, and more as you go further.

Quick Reference

Using AI to Go Further

Right now, your views exist — but they look pretty plain. The text is a default size, the button is unstyled, and the image is tiny. That’s where modifiers come in. Modifiers are how you style and configure views in SwiftUI, and they’re one of the most powerful ideas in the whole framework.

If you’ve used CSS for web development, modifiers will feel familiar. If you haven’t, here’s the analogy: think of a modifier like an adjective. A plain noun is “a button.” Add modifiers and it becomes “a large, bold, blue, rounded button with padding.” Each modifier adds one quality to the view, and you can chain as many as you need.

By the end of this lesson, you’ll know how to chain modifiers confidently, understand why the order of modifiers matters, and use the most common ones: .font(), .foregroundStyle(), .padding(), .background(), .cornerRadius(), and .frame().

How Modifiers Work

A modifier is a method you call on a view by typing a dot after it. It returns a new, modified view. Chain multiple modifiers by adding another dot. Here’s a simple example:

// Start with a Text view
Text("Hello, SwiftUI!")
    // Make the font large and bold
    .font(.largeTitle)
    .fontWeight(.bold)
    // Change the text color to blue
    .foregroundStyle(.blue)
    // Add breathing room around the text
    .padding()

The Essential Modifiers

.font() Set the text size and style using built-in semantic sizes

// Built-in font styles scale automatically with the user's accessibility settings
Text("Large Title").font(.largeTitle)
Text("Title").font(.title)
Text("Headline").font(.headline)
Text("Body").font(.body)
Text("Caption").font(.caption)

Use semantic sizes like .largeTitle, .title, .headline, .body, and .caption instead of hardcoded point sizes. These respect the user’s Dynamic Type settings so your app stays accessible.

// Set text color using built-in Color values
Text("Ocean").foregroundStyle(.blue)
Text("Fire").foregroundStyle(.orange)
Text("Muted").foregroundStyle(.secondary)

// Default padding on all sides
Text("All sides").padding()

// Specific amount on all sides
Text("Custom amount").padding(20)

// Padding on specific edges only
Text("Top only").padding(.top, 16)

// Yellow background fills only the text area
Text("Highlighted")
    .background(.yellow)

// Adding padding BEFORE background extends the colored area
Text("With padding")
    .padding()
    .background(.yellow)

.cornerRadius() Round the corners of a view

// A rounded button appearance using padding, background, and cornerRadius together
Text("Get Started")
    .padding()
    .background(.blue)
    .foregroundStyle(.white)
    .cornerRadius(12)

Combine .padding(), .background(), and .cornerRadius() and you have a professional-looking button without any custom drawing. A radius of 8 to 16 is common for buttons; higher values create more pill-like shapes.

// Fixed size
Color.blue
    .frame(width: 100, height: 100)

// Full width, fixed height
Color.green
    .frame(maxWidth: .infinity, height: 50)

Quick Reference

Using AI to Go Further

So far your views have been sitting alone on screen. That works for a single element, but real app interfaces combine dozens of views — some stacked vertically, some side by side, some layered on top of each other. This lesson is about the three containers that make all of that possible.

Think about how you’d describe a physical layout: “the label is above the button,” “the icon is to the left of the title,” “the badge is on top of the image.” SwiftUI has a container for each of those relationships. VStack for vertical, HStack for horizontal, and ZStack for layered. You nest views inside them like items in a box.

By the end of this lesson, you’ll know how each stack works, how to combine them, and how to control alignment and spacing. These three containers are the backbone of virtually every SwiftUI layout you’ll ever build.

How Stacks Work

// VStack arranges its children from top to bottom
VStack {
    Text("First")
    Text("Second")
    Text("Third")
}

// HStack arranges its children side by side, left to right
HStack {
    Image(systemName: "star.fill")
    Text("Favorites")
}

// ZStack layers its children on top of each other, back to front
ZStack {
    // Background layer — renders first, appears furthest back
    Color.blue
    // Foreground layer — renders last, appears on top
    Text("On top")
        .foregroundStyle(.white)
}

The Three Stack Containers

VStack Arrange views vertically with optional alignment and spacing

// VStack with leading alignment and custom spacing between items
VStack(alignment: .leading, spacing: 12) {
    Text("Chris Ching")
        .font(.title)
        .fontWeight(.bold)
    Text("iOS Developer")
        .font(.subheadline)
        .foregroundStyle(.secondary)
}

alignment: controls how children line up horizontally within the stack — .leading (left), .center (default), or .trailing (right). spacing: controls the gap between each child view in points.

HStack Arrange views side by side with optional alignment and spacing

// HStack with a Spacer to push views to opposite ends
HStack {
    Text("Username")
        .font(.headline)

    // Spacer expands to fill all available space between the two views
    Spacer()

    Image(systemName: "chevron.right")
        .foregroundStyle(.secondary)
}

Spacer() is one of the most useful tools in SwiftUI layouts. It expands to fill all available space in the direction of the stack — which pushes neighboring views apart. An HStack with a Spacer in the middle pushes the left view to the left edge and the right view to the right edge.

ZStack Layer views on top of each other

// ZStack for a card with an image and a text overlay
ZStack(alignment: .bottomLeading) {
    // The background image fills the frame
    Color.blue
        .frame(width: 300, height: 200)
        .cornerRadius(16)

    // Text sits on top, aligned to the bottom left
    Text("Mountain View")
        .font(.title2)
        .fontWeight(.bold)
        .foregroundStyle(.white)
        .padding()
}

ZStack‘s alignment: parameter controls where layered views appear within the stack’s bounds. Use it to position overlaid text at the top, bottom, corners, or center of the background view beneath it.

Nested Stacks Combine stacks to build complex layouts

// An HStack containing an image and a VStack of text — classic list row pattern
HStack(spacing: 14) {
    // Icon on the left
    Image(systemName: "person.circle.fill")
        .font(.largeTitle)
        .foregroundStyle(.blue)

    // Text details stacked vertically on the right
    VStack(alignment: .leading, spacing: 4) {
        Text("Chris Ching")
            .font(.headline)
        Text("iOS Educator")
            .font(.caption)
            .foregroundStyle(.secondary)
    }
}

Nesting stacks is the fundamental technique for building complex layouts. An HStack around a VStack gives you the classic “icon on the left, text details on the right” pattern you see in almost every iOS app’s list rows, profile cards, and settings screens.

Quick Reference

Using AI to Go Further

You’ve been using the canvas preview to check your views as you build them. But there’s a lot more to it than just glancing at the right side of Xcode. This lesson covers how to use both the canvas preview and the simulator effectively — and how to deal with the moments when they decide to stop cooperating.

The canvas preview and the simulator solve the same basic problem — “what does this look like?” — but in different contexts. The preview is fast, lightweight, and perfect for iterating on layout and styling. The simulator is slower to launch but runs real app code and is better for testing actual behavior like taps, navigation, and animations.

By the end of this lesson, you’ll know how to preview your views across multiple device sizes and color schemes, how to run your app in the simulator, and what to do when the preview crashes — which it will, eventually.

Working with the Canvas Preview

// Your ContentView code
struct ContentView: View {
    var body: some View {
        Text("Hello, Preview!")
    }
}

// This macro enables the live canvas preview at the bottom of the file
// It's automatically generated by Xcode — you normally don't need to edit it
#Preview {
    ContentView()
}

// Preview in both light and dark mode simultaneously
#Preview("Light Mode") {
    ContentView()
        .preferredColorScheme(.light)
}

#Preview("Dark Mode") {
    ContentView()
        .preferredColorScheme(.dark)
}

// No code changes needed — just press the Run button (▶) in Xcode
// or use the keyboard shortcut: Command + R
// Xcode builds and launches your app in the selected simulator device

// You can preview any view — not just ContentView
struct ProfileCard: View {
    var body: some View {
        Text("Profile content here")
    }
}

// Preview this specific component directly
#Preview {
    ProfileCard()
}

Quick Reference

Using AI to Go Further

This is the mini-project that brings everything from Stage 1 together. You’re going to build a polished profile card — a circular avatar, a name, a title, a stats row, and a follow button — entirely from scratch using only what you’ve learned so far.

No new concepts in this lesson. Everything here is Text, Image, VStack, HStack, ZStack, and modifiers. What’s new is putting them together intentionally, thinking about the layout before writing the code, and ending up with something that looks like it belongs in a real app.

Work through each step in order. After each one, check your canvas preview before moving to the next. The goal isn’t to finish fast — it’s to understand what each piece is doing and why.

Step 1: The Avatar

Start with a fresh ContentView and build the avatar first. A circular SF Symbol icon styled to look like a profile picture.

// Step 1: Start with just the avatar
struct ContentView: View {
    var body: some View {

        // Use a person icon scaled up to act as an avatar placeholder
        Image(systemName: "person.circle.fill")
            // Scale the SF Symbol to a large display size
            .font(.system(size: 90))
            // Color it blue to give a profile-picture feel
            .foregroundStyle(.blue)
    }
}

Step 2: Add the Name and Title

Wrap the avatar in a VStack and add the name and tagline beneath it.

var body: some View {

    // VStack holds the avatar and text details vertically, centered
    VStack(spacing: 8) {

        // Avatar from Step 1
        Image(systemName: "person.circle.fill")
            .font(.system(size: 90))
            .foregroundStyle(.blue)

        // Full name in a prominent bold style
        Text("Chris Ching")
            .font(.title2)
            .fontWeight(.bold)

        // Tagline or job title in a smaller, muted style
        Text("iOS Educator & App Developer")
            .font(.subheadline)
            .foregroundStyle(.secondary)
    }
}

Step 3: Add the Stats Row

Add a horizontal stats row below the name. Three stats — Posts, Followers, Following — evenly distributed using Spacer.

// Add this below the tagline Text, still inside the outer VStack
HStack {
    // Each stat is a VStack with a number and a label
    VStack {
        Text("248").font(.title3).fontWeight(.bold)
        Text("Posts").font(.caption).foregroundStyle(.secondary)
    }

    // Spacer pushes the stats apart to fill the full width
    Spacer()

    VStack {
        Text("12.4K").font(.title3).fontWeight(.bold)
        Text("Followers").font(.caption).foregroundStyle(.secondary)
    }

    Spacer()

    VStack {
        Text("540").font(.title3).fontWeight(.bold)
        Text("Following").font(.caption).foregroundStyle(.secondary)
    }
}
.padding(.horizontal)

Step 4: Add the Follow Button and Final Padding

The last piece is a full-width Follow button and some overall padding to give the card breathing room.

// Add this below the HStack stats row, still inside the outer VStack
Button(action: {
    // Action will go here once we learn about state in Stage 2
}) {
    // Button label styled to look like a solid primary button
    Text("Follow")
        .font(.headline)
        .foregroundStyle(.white)
        .frame(maxWidth: .infinity)
        .padding()
        .background(.blue)
        .cornerRadius(12)
}

// Apply overall padding and top spacing to the outer VStack using modifiers
// The modifier goes on the closing brace of the outer VStack
.padding()
.padding(.top, 20)

The Complete Profile Card

import SwiftUI

struct ContentView: View {
    var body: some View {

        // Outer container — everything stacks vertically with 16pt gaps
        VStack(spacing: 16) {

            // Avatar
            Image(systemName: "person.circle.fill")
                .font(.system(size: 90))
                .foregroundStyle(.blue)

            // Name and tagline grouped with tighter spacing
            VStack(spacing: 4) {
                Text("Chris Ching")
                    .font(.title2)
                    .fontWeight(.bold)
                Text("iOS Educator & App Developer")
                    .font(.subheadline)
                    .foregroundStyle(.secondary)
            }

            // Stats row
            HStack {
                VStack {
                    Text("248").font(.title3).fontWeight(.bold)
                    Text("Posts").font(.caption).foregroundStyle(.secondary)
                }
                Spacer()
                VStack {
                    Text("12.4K").font(.title3).fontWeight(.bold)
                    Text("Followers").font(.caption).foregroundStyle(.secondary)
                }
                Spacer()
                VStack {
                    Text("540").font(.title3).fontWeight(.bold)
                    Text("Following").font(.caption).foregroundStyle(.secondary)
                }
            }
            .padding(.horizontal)

            // Follow button — full width, blue, rounded
            Button(action: {}) {
                Text("Follow")
                    .font(.headline)
                    .foregroundStyle(.white)
                    .frame(maxWidth: .infinity)
                    .padding()
                    .background(.blue)
                    .cornerRadius(12)
            }
        }
        .padding()
        .padding(.top, 20)
    }
}

#Preview {
    ContentView()
}

Using AI to Go Further

Imagine a scoreboard at a basketball game. Every time a team scores, someone updates the number on the board. But what if the scoreboard wasn’t connected to anything — what if changing the score behind the scenes had no way to tell the board to refresh? The number on the board would just sit there, frozen, no matter what was really happening. That’s exactly the problem SwiftUI’s state system solves.

In Stage 1 you built views using properties, modifiers, and layout containers. Those views worked great — but everything about them was fixed at the moment the view was created. If you wanted the UI to change in response to something the user did, you’d quickly hit a wall.

By the end of this lesson you’ll understand exactly why a plain variable inside a SwiftUI view doesn’t cause the UI to update when it changes, and you’ll have the mental model for what state actually is and why SwiftUI needs it. There’s no code in this lesson — just the concept that makes everything else in Stage 2 make sense.

What happens when you use a plain variable

Here’s the problem in concrete terms. Suppose you want to show a counter that goes up when the user taps a button. Your first instinct might be to write something like this:

struct CounterView: View {
    // A plain variable — NOT wrapped in @State
    var count = 0

    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Tap me") {
                // This line will cause a compile error — structs are immutable
                count += 1
            }
        }
    }
}

This won’t even compile. SwiftUI views are structs, and structs are value types — their properties are immutable by default inside methods. But even if you got around that, there’s a deeper problem: SwiftUI has no way of knowing that count changed. It can’t see you mutate a plain variable. So even if the mutation happened, SwiftUI would never re-render the view to show the new number.

What “source of truth” means

You’ll hear the phrase “source of truth” a lot in SwiftUI. It just means: one authoritative place where a piece of data lives. When that data changes, everything that depends on it updates automatically. The view is a reflection of the data — not the other way around.

Think of it like a thermostat and every room in your house. The thermostat holds the actual temperature reading (the source of truth). Every display in every room just shows what the thermostat says. You don’t update each room display individually — you update the thermostat and everything else follows.

In SwiftUI, state is your thermostat. Your views are the room displays. When state changes, SwiftUI figures out which views depend on it and re-renders only those parts. This is the system that makes reactive UIs possible.

The mental model to carry forward

Before diving into the code in the next lesson, here’s the model to keep in mind: a SwiftUI view is a function of its state. Given the same state, you always get the same view. Change the state, and SwiftUI calls that function again and produces a new view. You describe what the UI should look like for any given state, and SwiftUI handles the rest.

Quick Reference

Think of @State as a special storage locker that SwiftUI manages for your view. When you put a value in the locker, SwiftUI watches it. The moment something changes that value, SwiftUI automatically redraws every part of the view that uses it. You don’t have to do anything extra — the connection is automatic.

In lesson 2.1 you saw exactly why a plain variable doesn’t work: SwiftUI can’t see the change, and structs are immutable anyway. @State solves both problems at once. It stores the value outside the struct (so mutating it is valid), and it tells SwiftUI to watch for changes (so re-rendering happens automatically).

By the end of this lesson you’ll know how to declare and use @State properties, understand why they’re always marked private, and build interactive views with counters, toggles, and text fields that respond to user input in real time.

Your first @State property

Here’s the counter from lesson 2.1 — now fixed with @State:

import SwiftUI

struct CounterView: View {
    // @State tells SwiftUI to own and watch this value
    @State private var count = 0

    var body: some View {
        VStack(spacing: 20) {
            // SwiftUI reads count here — when count changes, this Text re-renders
            Text("Count: \(count)")
                .font(.largeTitle)

            // The button's action mutates count — this triggers a re-render
            Button("Tap to Increment") {
                count += 1
            }
            .buttonStyle(.borderedProminent)
        }
    }
}

@State with different value types

@State private var isOn = false

VStack {
    // Toggle reads and writes isOn automatically
    Toggle("Enable notifications", isOn: $isOn)
        .padding()

    // Ternary operator shows different text based on isOn's value
    Text(isOn ? "Notifications: On" : "Notifications: Off")
        .foregroundStyle(isOn ? .green : .red)
}

@State private var name = ""

VStack(spacing: 12) {
    // TextField needs a binding because it writes back to name as the user types
    TextField("Enter your name", text: $name)
        .textFieldStyle(.roundedBorder)
        .padding()

    // This Text re-renders every keystroke as name changes
    Text("Hello, \(name.isEmpty ? "stranger" : name)!")
        .font(.title2)
}

@State private var showDetails = false

VStack(spacing: 16) {
    Button(showDetails ? "Hide Details" : "Show Details") {
        // Toggle the Bool — SwiftUI re-renders the conditional block below
        showDetails.toggle()
    }

    // This entire block only renders when showDetails is true
    if showDetails {
        Text("Here are the details you asked for.")
            .padding()
            .background(.blue.opacity(0.1))
            .cornerRadius(8)
    }
}

@State private var isExpanded = false

VStack {
    Button("Toggle Size") {
        // withAnimation wraps the state change — SwiftUI animates the diff
        withAnimation(.spring()) {
            isExpanded.toggle()
        }
    }

    // The frame size is driven by state — the animation happens between the two sizes
    RoundedRectangle(cornerRadius: 12)
        .fill(.blue)
        .frame(width: isExpanded ? 200 : 80, height: isExpanded ? 200 : 80)
}

Quick Reference

Using AI to Go Further

Think of a TV remote. The remote doesn’t store what channel the TV is on — the TV stores that. But the remote can change the channel. When you press a button, the remote sends the instruction to the TV, and the TV updates. The remote is a binding: it can read and write a value that lives somewhere else.

In lesson 2.2 you learned that @State is always marked private because the owning view should be the only one to hold it. But what happens when you split your UI into multiple views — a common thing to do to keep code clean — and a child view needs to change a parent’s state? That’s exactly where @Binding comes in.

By the end of this lesson you’ll understand the difference between a state owner and a binding consumer, how the $ prefix passes a binding down to a child view, and why this pattern keeps data flowing in one direction rather than creating confusion about where data lives.

The problem: split views need shared state

import SwiftUI

// The PARENT owns the state — it's the single source of truth
struct ParentView: View {
    @State private var isOn = false

    var body: some View {
        VStack(spacing: 20) {
            // Parent reads the state directly
            Text(isOn ? "The switch is ON" : "The switch is OFF")
                .font(.title2)

            // Pass a BINDING to the child — use $ to create it from the @State
            ToggleRow(isOn: $isOn)
        }
    }
}

// The CHILD receives a binding — it can read and write, but doesn't own the value
struct ToggleRow: View {
    // @Binding, not @State — this view doesn't own the value
    @Binding var isOn: Bool

    var body: some View {
        HStack {
            Text("Enable feature")
            Spacer()
            // Toggle mutates isOn via the binding — the parent's @State is what actually changes
            Toggle("", isOn: $isOn)
                .labelsHidden()
        }
        .padding()
        .background(.gray.opacity(0.1))
        .cornerRadius(10)
    }
}

@Binding patterns

// In the parent — $ creates a Binding from a @State property
ChildView(value: $myStateProperty)

// In the child — declare with @Binding, no default value, no private
@Binding var value: String

// Use .constant() in Previews when you need to pass a binding but don't have a parent
struct ToggleRow_Previews: PreviewProvider {
    static var previews: some View {
        // .constant wraps a value in a non-mutating binding — read-only, for previewing
        ToggleRow(isOn: Binding.constant(true))
    }
}

// Grandparent owns the state
@State private var text = ""

// Grandparent passes a binding to Parent
ParentView(text: $text)

// Parent holds a binding and passes it down to Child
struct ParentView: View {
    @Binding var text: String
    var body: some View {
        // Use $ again to pass the binding to the next child
        ChildView(text: $text)
    }
}

@State private var volume: Double = 0.5
@State private var quantity = 1

VStack(spacing: 16) {
    // Slider reads and writes volume via binding
    Slider(value: $volume, in: 0...1)

    // Stepper reads and writes quantity via binding
    Stepper("Quantity: \(quantity)", value: $quantity, in: 1...10)
}

Quick Reference

Using AI to Go Further

So far, the state you’ve been managing has been small and simple — a counter, a toggle, a text field. But real apps have real data: a list of tasks, a user’s profile, a shopping cart with dozens of items. Cramming all of that into @State properties inside a view gets messy fast. The solution is to move your data into a separate class and have SwiftUI watch that instead.

In lessons 2.2 and 2.3 you owned state directly inside the view. That’s perfect for local UI state — whether a sheet is open, what the user has typed in a field. But anything that represents your app’s actual data model belongs outside the view, in its own class, with clear responsibilities. This is a big step toward building real apps.

By the end of this lesson you’ll know how to use the @Observable macro (iOS 17+) to create an observable data model, how to use @State to hold an instance of that model inside a view, and how to recognize the older @ObservableObject and @StateObject pattern when you find it in existing code.

Lifting state into a model class

import SwiftUI
import Observation

// @Observable is a macro (iOS 17+) that makes this class trackable by SwiftUI
@Observable
class CounterModel {
    // These stored properties are automatically tracked — no property wrappers needed
    var count = 0
    var label = "Counter"

    // A method on the model that mutates its own state
    func increment() {
        count += 1
    }

    func reset() {
        count = 0
    }
}

struct CounterView: View {
    // @State holds the model instance — SwiftUI will re-render when any tracked property changes
    @State private var model = CounterModel()

    var body: some View {
        VStack(spacing: 20) {
            // Reading model.count — SwiftUI re-renders this when count changes
            Text("\(model.label): \(model.count)")
                .font(.largeTitle)

            HStack(spacing: 16) {
                Button("+") { model.increment() }
                    .buttonStyle(.borderedProminent)

                Button("Reset") { model.reset() }
                    .buttonStyle(.bordered)
            }
        }
    }
}

@Observable patterns

@Observable
class UserProfile {
    var name = "Chris"
    var isPremium = false
}

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

    var body: some View {
        Text("Hello, \(profile.name)")
    }
}

// Older approach — class conforms to ObservableObject protocol
class UserProfile: ObservableObject {
    // @Published marks each property that should trigger re-renders when changed
    @Published var name = "Chris"
    @Published var isPremium = false
}

struct ProfileView: View {
    // @StateObject instead of @State — owns and creates the object
    @StateObject private var profile = UserProfile()

    var body: some View {
        Text("Hello, \(profile.name)")
    }
}

@Observable
class CartModel {
    var items: [String] = []

    func addItem(_ item: String) {
        items.append(item)
    }
}

struct ShopView: View {
    @State private var cart = CartModel()

    var body: some View {
        VStack {
            // Pass the same cart model to both children — they share the same instance
            ProductListView(cart: cart)
            CartSummaryView(cart: cart)
        }
    }
}

struct ProductListView: View {
    // No property wrapper needed in child for @Observable — just a regular property
    var cart: CartModel

    var body: some View {
        Button("Add Item") { cart.addItem("Widget") }
    }
}

Quick Reference

Using AI to Go Further

Some information in your app needs to be accessible everywhere, not just passed down through bindings. Think about the system’s current color scheme — light or dark mode. Every view in your entire app might want to know this, and it would be exhausting to pass it as a parameter through every view. The environment is the solution: a shared bag of values that any view in the hierarchy can reach into and read.

In lessons 2.3 and 2.4 you passed data explicitly — either through bindings or by passing a model instance as a property. The environment is different: it flows down the entire view hierarchy automatically, without you having to thread it through every intermediate view. Views can also inject values into the environment, making them available to all of their descendants.

By the end of this lesson you’ll know how to read common built-in environment values like colorScheme, dismiss, and locale, and you’ll understand the environment’s role in the broader SwiftUI data flow picture.

Reading built-in environment values

import SwiftUI

struct AppearanceAwareView: View {
    // @Environment reads a value from the SwiftUI environment — no parent needed
    @Environment(\.colorScheme) var colorScheme

    var body: some View {
        VStack(spacing: 16) {
            // colorScheme is either .light or .dark — the system sets this automatically
            Text(colorScheme == .dark ? "Dark mode is active" : "Light mode is active")
                .font(.title2)

            Image(systemName: colorScheme == .dark ? "moon.fill" : "sun.max.fill")
                .font(.largeTitle)
                .foregroundStyle(colorScheme == .dark ? .white : .orange)
        }
        .padding()
    }
}

Commonly used environment values

struct SettingsSheet: View {
    // dismiss is an action — calling it dismisses this view
    @Environment(\.dismiss) var dismiss

    var body: some View {
        Button("Done") {
            // Calling dismiss() closes this sheet — no binding needed
            dismiss()
        }
    }
}

struct LocaleView: View {
    @Environment(\.locale) var locale

    var body: some View {
        // locale.identifier shows something like "en_CA" or "fr_FR"
        Text("Your locale: \(locale.identifier)")
    }
}

struct AdaptiveView: View {
    @Environment(\.dynamicTypeSize) var typeSize

    var body: some View {
        // Switch layout based on type size — large type users may need a different layout
        if typeSize >= .accessibility1 {
            VStack { /* stacked layout for big text */ }
        } else {
            HStack { /* side-by-side layout for normal text */ }
        }
    }
}

struct LinkView: View {
    // openURL is an action — call it with a URL to open Safari
    @Environment(\.openURL) var openURL

    var body: some View {
        Button("Visit CodeWithChris") {
            openURL(URL(string: "https://codewithchris.com")!)
        }
    }
}

Quick Reference

Using AI to Go Further

Imagine two whiteboards in different rooms, both showing the same meeting schedule. If someone updates one but not the other, they get out of sync. Now nobody is sure which one is correct. This is what happens in code when the same piece of data lives in two different places — both are “true” but they disagree, and your app behaves unpredictably as a result.

Everything you’ve learned in this stage — @State, @Binding, @Observable, @Environment — is in service of one principle: each piece of data should have exactly one owner, one place where it lives and is authoritative. Every other view that needs it gets a binding or a reference to that single source, never its own copy.

By the end of this lesson you’ll be able to look at a SwiftUI view hierarchy and identify whether state is owned correctly, recognize the common patterns that break single source of truth, and refactor a broken example into one that works reliably.

What good data ownership looks like

import SwiftUI

// The model is the single source of truth — one place, one owner
@Observable
class ProfileModel {
    var name = "Alex"
    var isVerified = false
}

// Root view owns the model — it flows downward from here
struct RootView: View {
    @State private var profile = ProfileModel()

    var body: some View {
        VStack(spacing: 24) {
            // HeaderView reads from the model — same instance
            HeaderView(profile: profile)

            // EditView also uses the same instance — a change here shows up in HeaderView
            EditView(profile: profile)
        }
    }
}

struct HeaderView: View {
    var profile: ProfileModel

    var body: some View {
        Text("Hello, \(profile.name)")
            .font(.title)
    }
}

struct EditView: View {
    @Bindable var profile: ProfileModel

    var body: some View {
        TextField("Name", text: $profile.name)
            .textFieldStyle(.roundedBorder)
            .padding(.horizontal)
    }
}

The data flow summary for Stage 2

// Use when: local UI state that only this view cares about
@State private var isExpanded = false

// Use when: a child view needs to mutate a parent's @State
@Binding var isSelected: Bool

// Use when: state is complex, shared between multiple views, or belongs outside the view
@Observable
class MyModel { var data = "" }

// Use when: system values (colorScheme, locale) or app-wide actions (dismiss)
@Environment(\.colorScheme) var colorScheme

Quick Reference

Using AI to Go Further

By default, SwiftUI stacks views as tightly as their content allows. That’s fine for simple layouts, but most real apps need breathing room — a title pushed to the top, a button pinned to the bottom, or a line separating two sections. That’s exactly what Spacer and Divider are for.

Spacer is an invisible view that expands to fill all available space in the direction it’s placed. Think of it like a spring: drop one between two views and it pushes them apart as far as the container allows. Divider is a thin horizontal (or vertical) line that visually separates content — the same kind of separator you see in Settings or menus.

Neither Spacer nor Divider display any visible content on their own. Spacer is pure layout; Divider is a single line. Together they give you two of the most commonly needed layout tools in any SwiftUI app.

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            // Title pinned to the top
            Text("My App")
                .font(.largeTitle)

            // Spacer pushes everything below it to the bottom
            Spacer()

            // Divider draws a horizontal line
            Divider()

            // Button sits at the bottom
            Button("Get Started") { }
                .buttonStyle(.borderedProminent)
        }
        .padding()
    }
}

Spacer and Divider Variations

VStack {
    // Each Spacer claims an equal share of the empty space
    Spacer()
    Text("Top third")
    Spacer()
    Text("Middle third")
    Spacer()
    Text("Bottom third")
    Spacer()
}

VStack {
    Text("Section Title").font(.headline)
    // This Spacer will always be at least 32 points tall
    Spacer(minLength: 32)
    Text("Body content below")
}

HStack {
    Text("Left")
    // Spacer inside HStack expands horizontally
    Spacer()
    Text("Right")
}

HStack {
    Text("Option A")
    // Divider inside HStack draws a vertical line
    Divider()
    Text("Option B")
}
.fixedSize(horizontal: false, vertical: true)

Using AI to Go Further

SwiftUI views size themselves to fit their content by default. A Text is exactly as wide as its text. A Button wraps its label. That’s often exactly what you want — but not always. When you need explicit control over how big a view is, where it sits, or how much space surrounds it, frame(), padding(), and offset() are the tools you reach for.

Think of frame() as setting the outer box that a view fits inside. Think of padding() as adding cushioning around a view. Think of offset() as sliding a view away from where it would normally sit — without disrupting the views around it.

These three modifiers cover the vast majority of explicit sizing and positioning work in SwiftUI. You’ll use them in almost every view you build.

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack(spacing: 20) {

            // Fixed frame: exactly 200 wide, 60 tall
            Text("Fixed Frame")
                .frame(width: 200, height: 60)
                .background(.blue.opacity(0.2))

            // Padding: adds 16pt space on all sides
            Text("With Padding")
                .padding(16)
                .background(.green.opacity(0.2))

            // Offset: slides 30pt right, 10pt down — doesn't affect layout
            Text("Offset Text")
                .offset(x: 30, y: 10)
                .background(.orange.opacity(0.2))
        }
    }
}

frame(), padding(), and offset() Variations

// Fills the full width of its container
Text("Full Width Button")
    .frame(maxWidth: .infinity)
    .padding()
    .background(.blue)
    .foregroundStyle(.white)
    .cornerRadius(12)

// At least 100 wide, at most 300 wide, grows to fill what's available
Text("Flexible width text")
    .frame(minWidth: 100, maxWidth: 300)
    .background(.yellow.opacity(0.4))

// Content aligns to the leading (left) edge of the frame
Text("Left aligned")
    .frame(maxWidth: .infinity, alignment: .leading)
    .padding()

VStack(alignment: .leading) {
    // Only adds padding above the heading
    Text("Section Header")
        .font(.headline)
        .padding(.top, 24)
    Text("Body text with no extra top space")
}

Using AI to Go Further

Most of the time, SwiftUI knows how to size and position your views without any help. But occasionally you need actual numbers — the real width of the screen, or the exact height of a container — so you can do math on them. That’s what GeometryReader is for.

GeometryReader is a container view that tells you the size of the space it occupies. You wrap your content inside it, and you get access to a GeometryProxy — an object with a .size property telling you the available width and height in points.

Here’s the important caveat: GeometryReader should be a last resort, not a first instinct. It has a side effect — it expands to fill all available space, which can throw off your layout unexpectedly. In most cases, .frame(maxWidth: .infinity) or a Spacer will do the job without any of the complications GeometryReader introduces.

import SwiftUI

struct ContentView: View {
    var body: some View {
        // GeometryReader gives us access to the available size
        GeometryReader { geometry in
            VStack {
                // Use geometry.size.width to make a proportional width
                Rectangle()
                    .fill(.blue)
                    // Always 80% of the available container width
                    .frame(width: geometry.size.width * 0.8, height: 100)

                // Display the actual dimensions so we can see what's happening
                Text("Container is \(Int(geometry.size.width))pt wide")
                    .font(.caption)
            }
        }
    }
}

GeometryReader Variations

GeometryReader { geometry in
    // Hero image that's always 40% of the screen height
    Rectangle()
        .fill(.indigo)
        .frame(height: geometry.size.height * 0.4)
}

VStack {
    Text("Header")

    // GeometryReader only measures this VStack's remaining space
    GeometryReader { geometry in
        HStack {
            // Sidebar takes up 30% of the remaining horizontal space
            Color.blue.frame(width: geometry.size.width * 0.3)
            Color.green
        }
    }
}

GeometryReader { geometry in
    // minY gives the view's distance from the top of the global screen
    let topOffset = geometry.frame(in: .global).minY

    Text("I am \(Int(topOffset))pt from the top")
}

Using AI to Go Further

A regular VStack creates every single child view the moment it loads — even if most of those views are offscreen. That’s fine for a small number of views, but if you have 500 rows in a list, creating all 500 at once wastes memory and slows things down. LazyVStack solves this by only creating views as they scroll into view.

The word “lazy” here means the same thing it does in everyday language: it waits until it has to do the work. A LazyVStack only creates a row when it’s about to become visible on screen. When rows scroll off screen, they can be released from memory. This is how apps with hundreds or thousands of rows stay fast.

The API is identical to VStack and HStack — you just change the name. The key rule: LazyVStack must be placed inside a ScrollView to be useful. Without a ScrollView, there’s no scrolling and no reason to be lazy.

import SwiftUI

struct ContentView: View {
    var body: some View {
        // ScrollView provides the scrollable container
        ScrollView {
            // LazyVStack only creates rows as they scroll into view
            LazyVStack(spacing: 12) {
                // ForEach creates a view for each number 1 through 200
                ForEach(1...200, id: \.self) { number in
                    Text("Row \(number)")
                        .frame(maxWidth: .infinity, alignment: .leading)
                        .padding()
                        .background(.white)
                        .cornerRadius(8)
                }
            }
            .padding()
        }
        .background(Color(.systemGroupedBackground))
    }
}

Lazy Stack Variations

// Horizontal scroll view with lazy loading
ScrollView(.horizontal, showsIndicators: false) {
    // Creates cards as they scroll into horizontal view
    LazyHStack(spacing: 16) {
        ForEach(1...50, id: \.self) { i in
            // Square card for each item
            RoundedRectangle(cornerRadius: 12)
                .fill(.blue.opacity(0.2))
                .frame(width: 120, height: 120)
                .overlay { Text("\(i)") }
        }
    }
    .padding()
}

ScrollView {
    LazyVStack(pinnedViews: [.sectionHeaders]) {
        Section {
            ForEach(1...20, id: \.self) { i in
                Text("Item \(i)").padding()
            }
        } header: {
            // This header sticks to the top while its section scrolls
            Text("Section A")
                .font(.headline)
                .frame(maxWidth: .infinity, alignment: .leading)
                .padding()
                .background(.white)
        }
    }
}

Using AI to Go Further

VStack and HStack are great for one-dimensional layouts. But when you need rows and columns at the same time — a photo grid, a product catalog, an icon launcher — you need a grid. SwiftUI has two options: Grid for small, fixed layouts where you need precise alignment across rows and columns, and LazyVGrid for large, scrollable grids with dynamic content.

The key to both is GridItem — a value type that defines one column (for LazyVGrid) or acts as a sizing description. You create an array of GridItems, and that array defines how many columns your grid has and how they’re sized.

There are three column types: fixed (always exactly N points wide), flexible (takes a share of available space), and adaptive (fits as many columns as possible given a minimum size). Adaptive is the most powerful — it automatically adjusts the number of columns based on available width.

import SwiftUI

struct ContentView: View {
    // Three flexible columns — each takes one-third of the width
    let columns = [
        GridItem(.flexible()),
        GridItem(.flexible()),
        GridItem(.flexible())
    ]

    var body: some View {
        ScrollView {
            // LazyVGrid lays out items in the defined columns
            LazyVGrid(columns: columns, spacing: 12) {
                ForEach(1...30, id: \.self) { item in
                    // Square cell for each grid item
                    RoundedRectangle(cornerRadius: 10)
                        .fill(.blue.opacity(0.3))
                        .aspectRatio(1, contentMode: .fit)
                        .overlay { Text("\(item)") }
                }
            }
            .padding()
        }
    }
}

Grid Column Type Variations

// Two fixed columns: one narrow sidebar, one wide main area
let columns = [
    GridItem(.fixed(80)),
    GridItem(.fixed(240))
]

// One adaptive column — SwiftUI decides how many fit
let columns = [
    GridItem(.adaptive(minimum: 100))
]

// On a 390pt wide screen, this creates 3 columns (390 / 100 ≈ 3-4)
// On a wider iPad, it automatically creates more columns

// Grid is for fixed, known content — not dynamic lists
Grid(alignment: .leading, horizontalSpacing: 20, verticalSpacing: 12) {
    GridRow {
        Text("Name").fontWeight(.bold)
        Text("Chris Ching")
    }
    GridRow {
        Text("Role").fontWeight(.bold)
        Text("iOS Developer")
    }
}

Using AI to Go Further

Modern iPhones have areas of the screen that are either physically cut into (the Dynamic Island, the notch) or reserved by the system (the home indicator bar at the bottom, the status bar at the top). SwiftUI calls these regions the safe area — and by default, your content stays inside it.

That default is a good one. It prevents your buttons from hiding behind the home indicator and your text from overlapping the status bar clock. But sometimes you want to break out intentionally — to extend a background color or image all the way to the screen edges, for example. The .ignoresSafeArea() modifier lets you do that.

The important mental model here is that .ignoresSafeArea() expands a view’s frame to include safe area regions — but you don’t have to move your content into those regions. You can extend a background behind the status bar while keeping your text inside the safe area.

import SwiftUI

struct ContentView: View {
    var body: some View {
        ZStack {
            // Background extends behind status bar and home indicator
            Color.indigo
                .ignoresSafeArea()

            // Content stays within the safe area by default
            VStack {
                Text("Full bleed background")
                    .foregroundStyle(.white)
                    .font(.title)
                Spacer()
                Text("Content stays safe")
                    .foregroundStyle(.white.opacity(0.7))
            }
            .padding()
        }
    }
}

Safe Area Variations

TextField("Search", text: $searchText)
    .textFieldStyle(.roundedBorder)
    .padding()
    // Prevents the keyboard from shifting this text field's container
    .ignoresSafeArea(.keyboard)

Color.blue
    // Only extend behind the top (status bar / Dynamic Island)
    .ignoresSafeArea(edges: .top)

ScrollView {
    LazyVStack {
        /* list content */
    }
}
// Adds a floating button that sits above the bottom safe area
.safeAreaInset(edge: .bottom) {
    Button("Compose") { }
        .buttonStyle(.borderedProminent)
        .padding()
}

Using AI to Go Further

Sometimes you want to show a large, full layout on a big screen and a compact version on a small one — without writing complicated conditional logic. ViewThatFits lets SwiftUI make that decision for you.

You give it several alternative views in order of preference. SwiftUI tries to fit the first one in the available space. If it doesn’t fit, it tries the next one. It uses whichever fits first. If none fit, it falls back to the last option regardless. Think of it like giving someone a list of dress code options from most formal to most casual — wear the first one that works.

ViewThatFits is especially useful for button rows that should be horizontal on wide screens and vertical on narrow ones, or for headlines that should show their full text on large devices but a shorter version on small ones.

import SwiftUI

struct ContentView: View {
    var body: some View {
        // ViewThatFits tries each option in order and uses the first that fits
        ViewThatFits {

            // Preferred: horizontal layout for wide containers
            HStack(spacing: 12) {
                Button("Save Draft") { }.buttonStyle(.bordered)
                Button("Preview") { }.buttonStyle(.bordered)
                Button("Publish Post") { }.buttonStyle(.borderedProminent)
            }

            // Fallback: vertical layout for narrow containers
            VStack(spacing: 10) {
                Button("Publish Post") { }
                    .buttonStyle(.borderedProminent)
                    .frame(maxWidth: .infinity)
                Button("Save Draft") { }
                    .buttonStyle(.bordered)
                    .frame(maxWidth: .infinity)
                Button("Preview") { }
                    .buttonStyle(.bordered)
                    .frame(maxWidth: .infinity)
            }
        }
        .padding()
    }
}

ViewThatFits Variations

// Only checks whether views fit horizontally — ignores height
ViewThatFits(in: .horizontal) {
    Text("Get Started with CodeWithChris").font(.title)
    Text("Get Started").font(.title)
    Text("Start").font(.title)
}

// Only checks height fit — useful for tall content in a fixed container
ViewThatFits(in: .vertical) {
    // Full detail layout
    DetailedInfoView()
    // Compact layout used if there isn't enough vertical space
    CompactInfoView()
}

Using AI to Go Further

Think about the Settings app on your iPhone. You tap “General,” a new screen slides in from the right. You tap “About,” another screen slides in. Hit the back button and you go back the way you came. That sliding-in, sliding-back behavior is called push/pop navigation, and in SwiftUI it’s powered by NavigationStack.

NavigationStack is a container view — you wrap it around your content, and it manages a stack of screens. “Stack” is a good mental model here: screens pile up as you navigate deeper, and they come back off the pile as you go back. The screen you’re currently looking at is always on top of the stack.

Before we add any navigation links, let’s start with the simplest possible NavigationStack — a container with a title. This alone gives you the navigation bar at the top, which is where back buttons and titles appear.

import SwiftUI

struct ContentView: View {
    var body: some View {
        // NavigationStack is the container — wrap your content inside it
        NavigationStack {
            // This Text is the content of the root (first) screen
            Text("Welcome to my app")
                // .navigationTitle sets the large title in the nav bar
                .navigationTitle("Home")
        }
    }
}

Customizing the Navigation Bar

NavigationStack {
    Text("Content here")
        // String literal becomes the nav bar title
        .navigationTitle("My App")
}

Text("Content")
    .navigationTitle("Settings")
    // .large = big collapsible title (default), .inline = smaller centered title
    .navigationBarTitleDisplayMode(.inline)

Text("Content")
    .navigationTitle("Home")
    .toolbar {
        // ToolbarItem places a button in the nav bar
        ToolbarItem(placement: .navigationBarTrailing) {
            Button("Add") {
                // action goes here
            }
        }
    }

Text("Content")
    .navigationTitle("Home")
    // Set the nav bar background to a custom color
    .toolbarBackground(Color.blue, for: .navigationBar)
    .toolbarBackground(.visible, for: .navigationBar)

Using AI to Go Further

You have a NavigationStack. Now you need something the user can tap to move to the next screen. That’s NavigationLink. Think of it like a hyperlink on a webpage — you tap it and you go somewhere. The difference is that instead of loading a URL, you’re pushing a new SwiftUI view onto the navigation stack.

NavigationLink works in two parts: the label (what the user sees and taps) and the destination (the view that appears when they tap it). The label can be anything — text, an image, a whole custom row. The destination is any SwiftUI view you want to show next.

Here’s the most common pattern you’ll use as a beginner — a list of items where each row is a NavigationLink that pushes to a detail screen:

import SwiftUI

struct ContentView: View {
    var body: some View {
        NavigationStack {
            // List gives us rows — each row can be a NavigationLink
            List {
                // NavigationLink: label is what you see, destination is where you go
                NavigationLink("Go to Detail") {
                    // This view appears when the user taps the link
                    DetailView()
                }
                NavigationLink("Go to Settings") {
                    SettingsView()
                }
            }
            .navigationTitle("Home")
        }
    }
}

struct DetailView: View {
    var body: some View {
        // The back button appears automatically — no code needed
        Text("You're on the detail screen")
            .navigationTitle("Detail")
            .navigationBarTitleDisplayMode(.inline)
    }
}

struct SettingsView: View {
    var body: some View {
        Text("Settings screen")
            .navigationTitle("Settings")
            .navigationBarTitleDisplayMode(.inline)
    }
}

Passing Data to the Destination

Most of the time you’re not just navigating to a blank screen — you’re passing data along with you. Here’s how to send data forward to a detail view:

struct ContentView: View {
    // Simple array of fruit names to display in a list
    let fruits = ["Apple", "Banana", "Cherry"]

    var body: some View {
        NavigationStack {
            List(fruits, id: \.self) { fruit in
                // Pass `fruit` into the destination so it knows which item to show
                NavigationLink(fruit) {
                    FruitDetailView(fruit: fruit)
                }
            }
            .navigationTitle("Fruits")
        }
    }
}

struct FruitDetailView: View {
    // The destination receives the value as a stored property
    let fruit: String

    var body: some View {
        Text("You selected: \(fruit)")
            .navigationTitle(fruit)
            .navigationBarTitleDisplayMode(.inline)
    }
}

// Instead of a plain string, use a trailing closure for a custom label
NavigationLink {
    DetailView()
} label: {
    // Anything here becomes the tappable area
    HStack {
        Image(systemName: "star.fill")
            .foregroundColor(.yellow)
        Text("Featured Item")
            .font(.headline)
    }
}

NavigationStack {
    List(fruits, id: \.self) { fruit in
        // Just pass the value — no destination closure needed here
        NavigationLink(fruit, value: fruit)
    }
    .navigationTitle("Fruits")
    // Declare what view to show for a given type of value
    .navigationDestination(for: String.self) { fruit in
        FruitDetailView(fruit: fruit)
    }
}

Using AI to Go Further

So far, navigation happens because the user taps something. But what if you need your code to navigate — without a user tap? Imagine an onboarding flow that automatically moves to the next step after something completes, or a deep link that opens the app directly on a specific screen. That’s programmatic navigation.

NavigationPath is a value that represents the current stack of screens. When you hand that path to your NavigationStack, you’re in control: append a value to the path and a new screen gets pushed. Remove the last value and you go back. Empty the whole path and you’re back at the root.

This is an intermediate concept — you don’t need it for most beginner apps. But once you start building real multi-screen flows, you’ll reach for it regularly.

import SwiftUI

struct ContentView: View {
    // @State holds the navigation path — changes to it drive navigation
    @State private var path = NavigationPath()

    var body: some View {
        // Pass a binding to the path so NavigationStack can read and write it
        NavigationStack(path: $path) {
            VStack(spacing: 20) {
                // Tapping this button pushes "Detail" onto the path programmatically
                Button("Go to Detail from code") {
                    path.append("Detail")
                }
                // This navigates two levels deep at once
                Button("Skip to Settings") {
                    path.append("Detail")
                    path.append("Settings")
                }
                // This jumps back to root no matter how deep we are
                Button("Go back to root") {
                    path.removeLast(path.count)
                }
            }
            .navigationTitle("Home")
            // Declare what view to show when a String value is pushed
            .navigationDestination(for: String.self) { screen in
                Text("Screen: \(screen)")
                    .navigationTitle(screen)
            }
        }
    }
}

NavigationPath Patterns

// Append any Hashable value — the type must match a .navigationDestination
path.append("SettingsScreen")

// You can also append custom types if they conform to Hashable
path.append(selectedUser)

// Go back one screen (same as user tapping the back button)
path.removeLast()

// Go back two screens at once
path.removeLast(2)

// Go all the way back to root
path.removeLast(path.count)

NavigationStack(path: $path) {
    ContentView()
    // One destination for String values
    .navigationDestination(for: String.self) { name in
        UserDetailView(name: name)
    }
    // A separate destination for Int values
    .navigationDestination(for: Int.self) { id in
        ItemDetailView(id: id)
    }
}

Using AI to Go Further

Push navigation isn’t the only way to show a new screen. Sometimes a screen should slide up from the bottom rather than push in from the side — like when you tap “New Message” in Mail or “New Event” in Calendar. That bottom-up presentation is called a modal, and SwiftUI has two modifiers for it: .sheet and .fullScreenCover.

The key difference is how much screen they cover. A sheet slides up and shows a bit of the underlying screen peeking out at the top — the user can see they’re temporarily leaving the main view. A fullScreenCover takes over the entire screen, just like push navigation but coming from the bottom. Use sheets for temporary forms, filter panels, and details that don’t need their own nav bar. Use fullScreenCover for things like login screens or camera views.

Both work the same way under the hood: you bind them to a Bool. When the Bool is true, the sheet appears. When it’s false, the sheet is dismissed.

import SwiftUI

struct ContentView: View {
    // @State bool controls whether the sheet is showing
    @State private var showSheet = false

    var body: some View {
        Button("Open Sheet") {
            // Setting to true triggers the sheet to appear
            showSheet = true
        }
        // .sheet watches the bool — appears when true, dismisses when false
        .sheet(isPresented: $showSheet) {
            SheetContentView()
        }
    }
}

struct SheetContentView: View {
    // @Environment(\.dismiss) gives access to the dismiss action
    @Environment(\.dismiss) var dismiss

    var body: some View {
        VStack {
            Text("This is a sheet")
            // Calling dismiss() closes the sheet from inside it
            Button("Close") {
                dismiss()
            }
        }
    }
}

Sheet Variations

// Same API as .sheet — just swap the modifier name
.fullScreenCover(isPresented: $showCover) {
    LoginView()
}

// When selectedFruit is non-nil, the sheet appears with that fruit's data
@State private var selectedFruit: String? = nil

Button("Show Apple") {
    selectedFruit = "Apple"
}
// sheet(item:) takes an optional Identifiable value — show when non-nil
.sheet(item: $selectedFruit) { fruit in
    // fruit is the unwrapped value, available directly
    FruitDetailView(fruit: fruit)
}

.sheet(isPresented: $showSheet) {
    FilterView()
        // Sheet stops at medium height — user can drag to expand
        .presentationDetents([.medium, .large])
}

Using AI to Go Further

Alerts and confirmation dialogs are the two ways iOS asks the user to confirm an action or choose between options. Think about what happens when you try to delete a photo — the system shows a small popup asking if you’re sure. That’s an alert. When you tap the share button in Safari and see a menu sliding up from the bottom with several choices, that’s a confirmation dialog (sometimes called an action sheet).

The rule of thumb: use an alert for urgent, important messages where you want the user’s full attention — two options maximum, usually “OK” and “Cancel.” Use a confirmationDialog when you have three or more choices or a destructive action that needs a clear presentation.

Both follow the same pattern you saw with sheets: bind them to a Bool, and when the Bool is true, they appear.

import SwiftUI

struct ContentView: View {
    // Bool that controls alert visibility
    @State private var showDeleteAlert = false

    var body: some View {
        Button("Delete Item") {
            // Show the alert when the button is tapped
            showDeleteAlert = true
        }
        // .alert watches the bool and presents when true
        .alert("Delete this item?", isPresented: $showDeleteAlert) {
            // Buttons go in the first trailing closure
            Button("Delete", role: .destructive) {
                // Perform the delete action here
            }
            // .cancel buttons are styled automatically by iOS
            Button("Cancel", role: .cancel) { }
        } message: {
            // Optional supporting text shown below the title
            Text("This cannot be undone.")
        }
    }
}

Alert and Dialog Variations

@State private var showOptions = false

Button("Share") {
    showOptions = true
}
// confirmationDialog slides up from the bottom like an action sheet
.confirmationDialog("Share this item", isPresented: $showOptions) {
    Button("Save to Photos") { }
    Button("Copy Link") { }
    Button("Delete", role: .destructive) { }
    Button("Cancel", role: .cancel) { }
}

// Alert appears when errorMessage is non-nil, dismisses when set to nil
@State private var errorMessage: String? = nil

.alert("Error", isPresented: Binding(
    get: { errorMessage != nil },
    set: { if !$0 { errorMessage = nil } }
)) {
    Button("OK", role: .cancel) { }
} message: {
    Text(errorMessage ?? "")
}

Using AI to Go Further

Tab bar navigation is one of the most recognizable patterns in iOS. If you’ve used Instagram, the App Store, or the Clock app, you’ve used a tab bar. Those icons at the bottom of the screen that let you jump between completely separate sections of an app — that’s TabView.

The key mental model for TabView is that each tab is an independent section. Unlike push navigation where screens are stacked on top of each other, tabs sit side by side. Each tab has its own navigation state — you can be deep in a push stack on one tab and it won’t affect what’s happening in another.

Setting up a basic tab bar takes just a few lines: wrap your views in TabView and give each one a .tabItem modifier that describes its icon and label.

import SwiftUI

struct ContentView: View {
    var body: some View {
        // TabView is the container — every direct child becomes a tab
        TabView {
            // Each view gets a .tabItem that defines its icon and label
            HomeView()
                .tabItem {
                    Label("Home", systemImage: "house.fill")
                }

            SearchView()
                .tabItem {
                    Label("Search", systemImage: "magnifyingglass")
                }

            ProfileView()
                .tabItem {
                    Label("Profile", systemImage: "person.fill")
                }
        }
    }
}

struct HomeView: View {
    var body: some View {
        // Each tab gets its own NavigationStack for independent navigation
        NavigationStack {
            Text("Home Screen")
                .navigationTitle("Home")
        }
    }
}

struct SearchView: View {
    var body: some View {
        NavigationStack {
            Text("Search Screen")
                .navigationTitle("Search")
        }
    }
}

struct ProfileView: View {
    var body: some View {
        NavigationStack {
            Text("Profile Screen")
                .navigationTitle("Profile")
        }
    }
}

TabView Customization

// @State variable tracks the currently active tab
@State private var selectedTab = 0

// Pass a binding so the TabView can read and write the selected tab
TabView(selection: $selectedTab) {
    HomeView()
        .tabItem { Label("Home", systemImage: "house") }
        // .tag() assigns an identifier — must match the type of selectedTab
        .tag(0)
    ProfileView()
        .tabItem { Label("Profile", systemImage: "person") }
        .tag(1)
}

// Jump to Profile tab from anywhere in your code
Button("Go to Profile") {
    selectedTab = 1
}

MessagesView()
    .tabItem {
        Label("Messages", systemImage: "envelope")
    }
    // Shows a red badge with the number — drive it from your data model
    .badge(3)

TabView {
    // tabs here
}
// Apply .tint to the TabView itself to change the selected tab color
.tint(.orange)

Using AI to Go Further

Navigation is about moving between screens. Data flow is about what travels with you. These two topics come together here — because understanding how to push to a new screen is only half the picture. The other half is making sure the right data arrives there, and knowing how to send changes back.

There are two directions data travels between screens. Forward is straightforward: you’re going somewhere and you bring what you need with you — just like passing a parameter to a function. Backward is trickier: the detail screen needs to tell the parent screen something changed. That’s where @Binding and @Environment(\.dismiss) come in.

This lesson pulls together what you’ve learned in Stage 4 with the data flow concepts from Stage 2. Let’s look at both directions with a realistic example.

import SwiftUI

struct ContentView: View {
    // @State owns the username — this is the source of truth
    @State private var username = "Alex"

    var body: some View {
        NavigationStack {
            VStack(spacing: 20) {
                Text("Hello, \(username)")
                    .font(.title)
                // Pass a binding so EditView can write back to this @State
                NavigationLink("Edit Profile") {
                    EditView(username: $username)
                }
            }
            .navigationTitle("Home")
        }
    }
}

struct EditView: View {
    // @Binding connects to the parent's @State — changes here update the parent
    @Binding var username: String

    var body: some View {
        VStack {
            // TextField with a binding — the user types and it updates instantly
            TextField("Username", text: $username)
                .textFieldStyle(.roundedBorder)
                .padding()
            Text("Preview: \(username)")
        }
        .navigationTitle("Edit Profile")
        .navigationBarTitleDisplayMode(.inline)
    }
}

Data Direction Patterns

// Parent passes a value — the child gets a read-only copy
NavigationLink("View Details") {
    DetailView(item: selectedItem)
}

struct DetailView: View {
    // let = constant, can't be changed — this is display-only data
    let item: Item

    var body: some View {
        Text(item.name)
    }
}

// Parent owns the data with @State
@State private var isEnabled = true

// Pass a binding — the sheet can toggle this value
.sheet(isPresented: $showSettings) {
    SettingsSheet(isEnabled: $isEnabled)
}

struct SettingsSheet: View {
    @Binding var isEnabled: Bool

    var body: some View {
        // Toggle writes back to the parent's @State via the binding
        Toggle("Enable Feature", isOn: $isEnabled)
            .padding()
    }
}

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

    var body: some View {
        VStack {
            Text("Add a new item")
            Button("Done") {
                // Save your data, then dismiss
                dismiss()
            }
        }
    }
}

Using AI to Go Further

Every app that shows more than one item of the same kind — a contact list, a task list, a feed — needs a way to display repeating data. In SwiftUI, the primary tool for that job is List. It wraps your content in a scrollable, system-styled table that looks right on every device and handles a lot of the work for you automatically.

You can think of a List like a vending machine shelf. Each slot holds one item of the same shape, arranged from top to bottom, and the user scrolls down to see more. You define what each slot looks like once, and SwiftUI fills in the rest.

In this lesson you’ll start with the simplest possible list — a static one with hardcoded rows — then move on to dynamic lists that read from an array. You’ll also meet the Identifiable protocol, which is how SwiftUI tells your rows apart.

import SwiftUI

struct ContentView: View {
    var body: some View {
        // List wraps its children in a scrollable, system-styled container
        List {
            // Each view inside becomes one row
            Text("Milk")
            Text("Eggs")
            Text("Bread")
            Text("Butter")
        }
    }
}

Dynamic Lists from an Array

Hardcoded rows only work when you know every item at build time. For anything data-driven, you pass an array to List and tell it how to display each element. Here’s a grocery list built from a Swift array:

struct ContentView: View {
    // An array of strings to display
    let items = ["Milk", "Eggs", "Bread", "Butter"]

    var body: some View {
        // id: \.self tells SwiftUI to use the string value itself as the unique identifier
        List(items, id: \.self) { item in
            Text(item)
        }
    }
}

// Conform your model to Identifiable so List can tell rows apart
struct GroceryItem: Identifiable {
    // id is required by Identifiable — must be unique for each item
    let id = UUID()
    let name: String
    let quantity: Int
}

struct ContentView: View {
    let items: [GroceryItem] = [
        GroceryItem(name: "Milk", quantity: 2),
        GroceryItem(name: "Eggs", quantity: 12),
        GroceryItem(name: "Bread", quantity: 1)
    ]

    var body: some View {
        // No need for id: parameter — List finds it automatically via Identifiable
        List(items) { item in
            Text("\(item.name) × \(item.quantity)")
        }
    }
}

struct ContentView: View {
    let items = ["Milk", "Eggs", "Bread"]

    var body: some View {
        // Wrap in NavigationStack to get the title bar at the top
        NavigationStack {
            List(items, id: \.self) { item in
                Text(item)
            }
            // .navigationTitle appears in the navigation bar above the list
            .navigationTitle("Groceries")
        }
    }
}

Understanding Identifiable

When SwiftUI displays a dynamic list, it needs a way to tell each row apart — especially when rows are added, removed, or reordered. That’s what Identifiable is for. It’s a protocol (a contract) that says: “my type has an id property, and that id is unique.”

The id can be any type that’s unique — a UUID, an Int, a String. The only rule is that no two items in the list share the same id. UUID() is the safest default because it generates a globally unique value every time.

Challenge 5.1

Using AI to Go Further

In the last lesson you passed an array directly to List and it looped through your data automatically. Under the hood, that’s ForEach doing the work. In this lesson you’ll use it directly, which gives you a lot more flexibility.

Think of ForEach like a cookie cutter. You give it a tray of dough (your array) and a cutter shape (your row view), and it stamps out one view per item. It doesn’t know or care whether the results end up in a list, a stack, or anywhere else.

This matters because ForEach is not a scrollable container — it’s just a view builder that loops. You can drop it inside a List, a VStack, a ScrollView, or anywhere else that accepts multiple views.

struct ContentView: View {
    let fruits = ["Apple", "Banana", "Cherry", "Date"]

    var body: some View {
        List {
            // ForEach loops through the array and produces one view per item
            ForEach(fruits, id: \.self) { fruit in
                // This closure runs once for every element in the array
                Text(fruit)
            }
        }
    }
}

ForEach Inside Different Containers

var body: some View {
    VStack(alignment: .leading) {
        // Views are stacked vertically, no scrolling, no separators
        ForEach(fruits, id: \.self) { fruit in
            Text(fruit)
                .padding(.vertical, 4)
        }
    }
}

List {
    // A static row above the dynamic content
    Text("Today's picks")
        .font(.headline)

    // ForEach generates one row per fruit
    ForEach(fruits, id: \.self) { fruit in
        Text(fruit)
    }

    // Another static row below
    Text("End of list")
        .foregroundStyle(.secondary)
}

struct Book: Identifiable {
    let id = UUID()
    let title: String
    let author: String
}

List {
    // No id: parameter needed — ForEach finds it via Identifiable
    ForEach(books) { book in
        Text(book.title)
    }
}

List {
    // indices gives you 0, 1, 2... — useful when you need the position
    ForEach(fruits.indices, id: \.self) { index in
        // Access the element using the index
        Text("\(index + 1). \(fruits[index])")
    }
}

Challenge 5.2

Using AI to Go Further

A plain Text row works fine for a simple list, but most real apps need rows with more structure — a title, a subtitle, maybe an icon or image. In this lesson you’ll learn to build your own row views and organise your code in a way that scales.

Think of a custom row like a business card template. You design the layout once, and then the same card prints out for every contact in your address book, filled with different data each time. The template stays the same; only the content changes.

You’ll also learn why extracting your row into a separate struct is a good habit — even when the row is simple. It keeps your ContentView clean, makes the row reusable, and makes Xcode’s preview faster.

struct Book: Identifiable {
    let id = UUID()
    let title: String
    let author: String
    let genre: String
}

// A standalone struct that renders one book as a row
struct BookRow: View {
    // The row receives its data via a property
    let book: Book

    var body: some View {
        // HStack lays out the icon and text side by side
        HStack {
            // SF Symbol icon — no image file needed
            Image(systemName: "book.fill")
                .foregroundStyle(.blue)
                .frame(width: 32)

            // VStack stacks the title and author vertically
            VStack(alignment: .leading) {
                Text(book.title)
                    .font(.headline)
                Text(book.author)
                    .font(.subheadline)
                    .foregroundStyle(.secondary)
            }
        }
    }
}

struct ContentView: View {
    let books: [Book] = [
        Book(title: "Dune", author: "Frank Herbert", genre: "Sci-Fi"),
        Book(title: "1984", author: "George Orwell", genre: "Dystopia"),
        Book(title: "The Hobbit", author: "J.R.R. Tolkien", genre: "Fantasy")
    ]

    var body: some View {
        NavigationStack {
            List(books) { book in
                // Pass each book into the custom row view
                BookRow(book: book)
            }
            .navigationTitle("Reading List")
        }
    }
}

Row Layout Patterns

struct SettingsRow: View {
    let icon: String
    let title: String
    let color: Color

    var body: some View {
        Label(title, systemImage: icon)
            .foregroundStyle(color)
    }
}

HStack {
    VStack(alignment: .leading) {
        Text(book.title).font(.headline)
        Text(book.author).font(.caption)
    }
    // Spacer() pushes everything after it to the trailing edge
    Spacer()
    Text(book.genre)
        .font(.caption)
        .foregroundStyle(.secondary)
}

HStack(spacing: 12) {
    // Rounded square thumbnail using a system image as a placeholder
    Image(systemName: "photo")
        .resizable()
        .scaledToFill()
        .frame(width: 56, height: 56)
        .clipShape(RoundedRectangle(cornerRadius: 8))
        .background(Color.gray.opacity(0.2))

    VStack(alignment: .leading, spacing: 2) {
        Text(book.title).font(.headline)
        Text(book.author).font(.subheadline).foregroundStyle(.secondary)
        Text(book.genre).font(.caption).foregroundStyle(.tertiary)
    }
}

Challenge 5.3

Using AI to Go Further

As your lists grow, a flat collection of rows can feel overwhelming. Section is SwiftUI’s way of grouping related rows together under a shared header, just like Contacts groups names alphabetically or Settings groups controls by category.

Think of sections like chapters in a book. Each chapter has a title that tells you what’s coming, and all the related content sits under it. The table of contents gives you the big picture; you drill into whatever chapter you need.

Sections work inside any List. You can have as many as you need, and each one can have its own header, footer, or both.

struct ContentView: View {
    let reading = ["Dune", "1984"]
    let finished = ["The Hobbit", "Ender's Game", "Foundation"]

    var body: some View {
        NavigationStack {
            List {
                // Section groups related rows and adds a header label above them
                Section("Currently Reading") {
                    ForEach(reading, id: \.self) { title in
                        Text(title)
                    }
                }
                // A second Section creates a separate group below
                Section("Finished") {
                    ForEach(finished, id: \.self) { title in
                        Text(title)
                    }
                }
            }
            .navigationTitle("My Books")
        }
    }
}

Section Variations

Section {
    Toggle("Notifications", isOn: $notificationsOn)
    Toggle("Sounds", isOn: $soundsOn)
} header: {
    // Custom header view — can be any view, not just Text
    Text("Alerts")
} footer: {
    // Footer appears below the section in smaller muted text
    Text("Notifications will appear on your lock screen.")
}

List {
    Section("Account") { /* rows */ }
    Section("Privacy") { /* rows */ }
}
// .insetGrouped is the default on iOS 16+ — explicitly set for clarity
.listStyle(.insetGrouped)

Section {
    ForEach(books) { book in BookRow(book: book) }
} header: {
    // Any view works as a header — not just a plain string
    HStack {
        Image(systemName: "star.fill")
            .foregroundStyle(.yellow)
        Text("Top Picks")
    }
}

Challenge 5.4

Using AI to Go Further

Swipe-to-delete is one of the most recognisable iOS interactions. Users swipe left on a row and a red delete button appears. Swipe far enough and the row vanishes. SwiftUI makes this surprisingly easy — and gives you the hooks to add your own custom swipe actions too.

Think of swipe actions like the back of a drawer. The front face (the row) is what users always see. Swiping reveals what’s hidden behind it — delete, archive, flag, whatever you put there. The row itself doesn’t change; you’re just exposing tools attached to it.

In this lesson you’ll add delete with .onDelete, then build custom swipe actions using .swipeActions. You’ll also see how EditButton enables a system-style edit mode with selection circles.

struct ContentView: View {
    // @State makes the array mutable so we can remove items
    @State private var books = ["Dune", "1984", "The Hobbit"]

    var body: some View {
        NavigationStack {
            List {
                ForEach(books, id: \.self) { book in
                    Text(book)
                }
                // .onDelete tells ForEach what to do when a row is swiped-to-delete
                .onDelete(perform: deleteBook)
            }
            .navigationTitle("Books")
            // EditButton toggles edit mode — shows selection circles on rows
            .toolbar { EditButton() }
        }
    }

    // This function receives the IndexSet of rows to remove
    func deleteBook(at offsets: IndexSet) {
        // .remove(atOffsets:) removes the elements at the given positions
        books.remove(atOffsets: offsets)
    }
}

Custom Swipe Actions

ForEach(books) { book in
    BookRow(book: book)
        // .swipeActions adds buttons revealed by swiping left (trailing)
        .swipeActions(edge: .trailing) {
            // Each Button inside becomes one swipe action
            Button(role: .destructive) {
                deleteBook(book)
            } label: {
                Label("Delete", systemImage: "trash")
            }
        }
        // .swipeActions on leading edge reveals on swipe right
        .swipeActions(edge: .leading) {
            Button {
                toggleFavourite(book)
            } label: {
                Label("Favourite", systemImage: "star.fill")
            }
            .tint(.yellow)
        }
}

ForEach(books, id: \.self) { book in
    Text(book)
}
.onDelete(perform: deleteBook)
// .onMove enables drag handles in edit mode for reordering
.onMove(perform: moveBook)

func moveBook(from source: IndexSet, to destination: Int) {
    // .move(fromOffsets:toOffset:) updates the array in place
    books.move(fromOffsets: source, toOffset: destination)
}

Challenge 5.5

Using AI to Go Further

Pull-to-refresh is the gesture where a user drags down from the top of a list, sees a loading spinner, and the content updates. You’ve done it a thousand times in Twitter, Mail, and News. In SwiftUI, you add it with a single modifier: .refreshable.

The reason this lesson is short is because .refreshable does almost everything for you: it handles the gesture, shows the spinner, and waits for your work to finish before hiding it again. Your job is just to describe what “refreshing” means for your app.

The one thing to know upfront: .refreshable uses Swift’s async/await syntax. You’ll get a proper deep dive on async/await in Stage 8 (Networking). For now, you just need to know how the pattern looks and what the keywords mean at a surface level.

struct ContentView: View {
    @State private var books = ["Dune", "1984", "The Hobbit"]

    var body: some View {
        NavigationStack {
            List(books, id: \.self) { book in
                Text(book)
            }
            .navigationTitle("Books")
            // .refreshable runs when the user pulls down from the top of the list
            .refreshable {
                // await pauses here and waits for fetchLatestBooks() to finish
                await fetchLatestBooks()
            }
        }
    }

    // async marks a function that can be paused mid-execution
    func fetchLatestBooks() async {
        // Simulate a network delay — in a real app this calls an API
        try? await Task.sleep(for: .seconds(1))
        // Update the array after the fake "network call" completes
        books = ["Dune", "1984", "The Hobbit", "Foundation"]
    }
}

.refreshable {
    // Always update @State properties from the main thread
    await loadData()
}

// @MainActor ensures this function always runs on the main thread
@MainActor
func loadData() async {
    let newBooks = await fetchFromAPI()
    books = newBooks
}

Challenge 5.6

Using AI to Go Further

By now you’ve used List, ForEach, and you’ve probably seen ScrollView mentioned. They all involve displaying collections of views, so it’s easy to reach for the wrong one and wonder why something isn’t working. This lesson is entirely about making that decision confidently.

There are no new APIs in this lesson — just clarity. You’ll see what each approach does and doesn’t do, the kinds of bugs that happen when you pick the wrong one, and a simple set of questions to ask yourself when you’re starting a new screen.

Getting this right early saves a lot of debugging time later. Choosing ScrollView + ForEach when you needed List, or vice versa, produces layout headaches that can feel mysterious until you understand the difference.

The Three Tools at a Glance

When to Use Each One

// List is the right choice when you need any of these:
// - Swipe to delete or custom swipe actions
// - Edit mode with selection or reordering
// - Pull to refresh
// - Section headers with the platform-standard appearance
// - NavigationLink rows that push a detail view
List(contacts) { contact in
    NavigationLink(contact.name, value: contact)
}
.swipeActions { /* ... */ }
.refreshable { await reload() }

// ScrollView is right when you need:
// - Custom card layouts (no row separators or inset styling)
// - Horizontal scrolling
// - Mixed content types (banners, cards, text, images together)
// - Full control over spacing and visual styling
ScrollView {
    VStack(spacing: 16) {
        ForEach(recipes) { recipe in
            RecipeCard(recipe: recipe)
        }
    }
    .padding()
}

// ForEach alone (no ScrollView or List wrapper) is right when:
// - You're generating views inside a Form, Group, or HStack
// - The parent container already handles layout and scrolling
// - You need to mix generated and static views in one block
Form {
    Section("Tags") {
        // ForEach generates Toggle rows inside an existing Form container
        ForEach(tags) { tag in
            Toggle(tag.name, isOn: $tag.isSelected)
        }
    }
}

Common Mistakes and What Goes Wrong

Challenge 5.7

Using AI to Go Further

Every app that asks for a name, an email address, or a password uses a text field. In SwiftUI, TextField is the view that lets users type free-form text. It looks simple on the surface — a box you can type into — but there’s a lot going on underneath: it’s connected to a piece of state, it responds to the keyboard, and you can configure it in ways that make a real difference to the user experience.

The key thing to understand about TextField is that it’s always bound to a String variable. That binding is a two-way connection: when the user types, the variable updates. When the variable changes in code, the text field updates. That’s the same @State and Binding pattern you’ve already used with buttons and toggles — text input is just another form of the same idea.

SecureField is a close cousin of TextField. It works exactly the same way — same binding, same modifiers — but it hides the characters the user types. You use it for passwords. Once you understand TextField, using SecureField is almost no extra work at all.

import SwiftUI

struct LoginView: View {

    // Store the text the user types into the email field
    @State private var email = ""

    // Store the text the user types into the password field
    @State private var password = ""

    var body: some View {
        VStack(spacing: 16) {

            // TextField takes a placeholder string and a binding to a String variable
            TextField("Email address", text: $email)
                // Style it as a rounded rectangle input box
                .textFieldStyle(.roundedBorder)
                // Tell iOS this is an email address so it shows the right keyboard
                .keyboardType(.emailAddress)
                // Disable autocorrect — no one wants autocorrect on an email
                .autocorrectionDisabled()

            // SecureField hides the typed characters — perfect for passwords
            SecureField("Password", text: $password)
                .textFieldStyle(.roundedBorder)

            // A disabled button that only activates when both fields have content
            Button("Log In") {
                print("Logging in as \(email)")
            }
            .disabled(email.isEmpty || password.isEmpty)
        }
        .padding()
    }
}

TextField Modifiers Worth Knowing

// Email address keyboard — includes @ and .com
TextField("Email", text: $email)
    .keyboardType(.emailAddress)

// Numeric pad — digits only, no letters
TextField("Phone number", text: $phone)
    .keyboardType(.phonePad)

// Number pad with decimal point — good for prices
TextField("Amount", text: $amount)
    .keyboardType(.decimalPad)

// Tells iOS this is an email field — enables AutoFill from Contacts
TextField("Email", text: $email)
    .textContentType(.emailAddress)

// Tells iOS this is a new password — triggers strong password suggestion
SecureField("Create password", text: $password)
    .textContentType(.newPassword)

// Tells iOS this is an existing password — enables Keychain AutoFill
SecureField("Password", text: $password)
    .textContentType(.password)

// "Next" on the return key — great for multi-field forms
TextField("First name", text: $firstName)
    .submitLabel(.next)

// "Search" on the return key
TextField("Search", text: $query)
    .submitLabel(.search)

// "Done" on the return key — signals end of input
TextField("Notes", text: $notes)
    .submitLabel(.done)

// No autocapitalisation — good for usernames and emails
TextField("Username", text: $username)
    .textInputAutocapitalization(.never)

// Capitalise the first letter of each word — good for names
TextField("Full name", text: $name)
    .textInputAutocapitalization(.words)

// Capitalise every sentence (the default)
TextField("Bio", text: $bio)
    .textInputAutocapitalization(.sentences)

Using AI to Go Further

Not every piece of user input is text. Sometimes you just want to know if something is on or off. Sometimes you need a number between two limits. SwiftUI has a control for each of these situations: Toggle for booleans, Slider for a value within a range, and Stepper for stepping up and down through a number by a fixed amount.

All three controls follow the same binding pattern you used in Lesson 6.1. Toggle binds to a Bool. Slider and Stepper bind to a numeric type — most commonly a Double. The control reads the current value to know what to display, and it writes back to the variable when the user interacts with it.

Think of these controls as physical dials and switches on a settings panel, but digital. The binding is the wire connecting the dial to the part of your app that actually cares about the value. The control is just a way for the user to change what’s on the other end of that wire.

import SwiftUI

struct SettingsView: View {

    // A boolean — Toggle will flip this between true and false
    @State private var notificationsEnabled = true

    // A Double between 0 and 100 — Slider will set this
    @State private var brightness: Double = 50

    // An Int that Stepper will increment and decrement
    @State private var fontSize = 16

    var body: some View {
        VStack(alignment: .leading, spacing: 24) {

            // Toggle takes a label string and a Bool binding
            Toggle("Enable Notifications", isOn: $notificationsEnabled)

            VStack(alignment: .leading) {
                // Display the current slider value so the user can see it
                Text("Brightness: \(Int(brightness))%")

                // Slider takes a value binding and an in: range
                Slider(value: $brightness, in: 0...100)
            }

            VStack(alignment: .leading) {
                Text("Font Size: \(fontSize)pt")

                // Stepper takes a label, a value binding, and an in: range
                Stepper("Font Size", value: $fontSize, in: 10...32)
            }
        }
        .padding()
    }
}

Useful Variations

// step: 5 means the value jumps 0, 5, 10, 15... when dragged
Slider(value: $volume, in: 0...100, step: 5)

// step: 5 means each tap adds or subtracts 5
Stepper("Quantity", value: $quantity, in: 0...100, step: 5)

// Button style — looks like a button that activates/deactivates
Toggle("Bold", isOn: $isBold)
    .toggleStyle(.button)

// minimumValueLabel and maximumValueLabel show on the slider ends
Slider(value: $rating, in: 1...5, step: 1) {
    Text("Rating")
} minimumValueLabel: {
    Text("1")
} maximumValueLabel: {
    Text("5")
}

Using AI to Go Further

Picker lets users choose one option from a list. Think of a “Country” dropdown, a “Sort by” control, or the tab at the top of a screen that switches between “Day”, “Week”, and “Month” views. Picker handles all of these with a single, flexible component that changes its appearance based on the style you choose.

The binding for a Picker is slightly different from what you’ve seen. You bind it to a variable that holds the currently selected value, and you tag each option inside the Picker with the value it represents. When the user picks an option, the binding updates to that tag’s value. It sounds like more pieces to juggle, but the pattern is very consistent once you’ve seen it a couple of times.

Picker works naturally with enums, and that’s usually the best approach. An enum gives you a clearly defined set of options, meaningful names, and you get compiler errors if you add a case and forget to handle it somewhere. You’ll use this pattern constantly in real iOS apps.

import SwiftUI

// Define the options as an enum — String gives us free raw values
enum SortOption: String, CaseIterable, Identifiable {
    case newest = "Newest"
    case oldest = "Oldest"
    case popular = "Most Popular"

    // Identifiable requires an id — using self works for String enums
    var id: String { rawValue }
}

struct SortPickerView: View {

    // Hold the currently selected sort option
    @State private var selectedSort: SortOption = .newest

    var body: some View {
        VStack(spacing: 20) {

            // Picker takes a label, a selection binding, and a content block
            Picker("Sort by", selection: $selectedSort) {
                // Each option is a view tagged with the value it represents
                ForEach(SortOption.allCases) { option in
                    Text(option.rawValue).tag(option)
                }
            }
            // Segmented style shows all options as a horizontal control
            .pickerStyle(.segmented)

            // Display the selected value below so we can see the binding working
            Text("Sorted by: \(selectedSort.rawValue)")
                .foregroundStyle(.secondary)
        }
        .padding()
    }
}

Picker Styles

Picker("Country", selection: $selectedCountry) {
    ForEach(countries, id: \.self) { country in
        Text(country).tag(country)
    }
}
.pickerStyle(.menu)

Picker("View", selection: $selectedView) {
    Text("List").tag("list")
    Text("Grid").tag("grid")
}
.pickerStyle(.segmented)

Picker("Hour", selection: $selectedHour) {
    ForEach(0..<24, id: \.self) { hour in
        Text("\(hour):00").tag(hour)
    }
}
.pickerStyle(.wheel)

Using AI to Go Further

DatePicker is exactly what it sounds like — a control that lets users pick a date, a time, or both. Booking apps, reminder apps, calendar apps, countdown timers — if your app involves time in any way, you’ll use DatePicker. It handles all the complexity of date and time selection for you, including locale formatting and time zones.

Like all the other input controls you’ve seen, DatePicker uses a binding. This time the binding is to a Date value. Date is a type built into Swift’s Foundation framework that represents a specific point in time. You initialize it with Date() to get the current date and time as a starting value.

You can restrict the range of selectable dates with the in: parameter. This is useful for things like “departure date must be in the future” or “date of birth must be in the past”. You can also control whether the picker shows a date, a time, or both using displayedComponents.

import SwiftUI

struct EventSchedulerView: View {

    // Date() gives us the current date and time as the starting value
    @State private var eventDate = Date()

    // Date.now gives a reference point — used to restrict selectable range
    let dateRange: ClosedRange<Date> = Date.now...Date.now.addingTimeInterval(60 * 60 * 24 * 365)

    var body: some View {
        VStack(alignment: .leading, spacing: 20) {

            // Full date AND time picker — graphical calendar style
            DatePicker(
                "Event Date",
                selection: $eventDate,
                // Only allow dates from now up to one year from today
                in: dateRange,
                // Show both date and time components
                displayedComponents: [.date, .hourAndMinute]
            )
            // Graphical style shows a full calendar and clock
            .datePickerStyle(.graphical)

            // Display the selected date using a formatter
            Text("Selected: \(eventDate.formatted(date: .abbreviated, time: .shortened))")
                .foregroundStyle(.secondary)
        }
        .padding()
    }
}

DatePicker Styles and Configurations

// Compact style shows tappable date/time labels that expand on tap
DatePicker("Reminder", selection: $reminderDate)
    .datePickerStyle(.compact)

// Only show the date — no time picker
DatePicker(
    "Birthday",
    selection: $birthday,
    in: ...Date.now,
    displayedComponents: .date
)

// Only show the time picker — no date
DatePicker(
    "Wake up time",
    selection: $wakeTime,
    displayedComponents: .hourAndMinute
)