Smaller views, and a stand-in for the network

After the first tap, the equatable row stopped running its body; the plain one ran every time:

The console, from launch through three taps

the parent's body
EquatableRow's body
Row's body
the parent's body
EquatableRow's body
Row's body
the parent's body
EquatableRow's == said true
Row's body
the parent's body
EquatableRow's == said true
Row's body

From the second tap on, SwiftUI asked the row's own == — which ignores the closure — got true, and skipped its body. The first update after launch ran the body without asking at all, in every run of this measurement; Apple does not document that, so expect .equatable() to save work on repeated updates, not on the first. Use it when a subview's inputs include something that cannot be compared — a closure, a reference — and its body is expensive; the == must still say different whenever the screen should change.

Where this comes from: equatable() · WWDC21: Demystify SwiftUI (2021 — still the reference on identity) — Measured in the iOS 27 simulator.

Neither. Each printed once, at launch, and not again after the tap:

The console

JustTheTitle's body
WholeStore's body

JustTheTitle was skipped because its input, a string, was unchanged. WholeStore's input — the same store — was unchanged too, and Observation re-runs a body only when something that body read has changed: it read only title, not trips. So with @Observable, handing a subview the whole model costs nothing extra; what matters is what each body reads. (With an old ObservableObject held in @ObservedObject, any @Published change redraws every view watching the object.)

Where this comes from: Observable() macro · Declaring a custom view — Measured in the iOS 27 simulator.

Only the property's. At launch both ran; over two taps, the console printed:

the property's body
the property's body

A computed property is part of the parent's body: it runs whenever the parent's does. A struct is a view of its own. SwiftUI compared the new Header() with the old one, found nothing different — it has no inputs at all — and skipped its body. That is why a real piece of interface belongs in a struct: it is a boundary where SwiftUI can stop. A computed property is fine for a few lines that change with the parent anyway.

Where this comes from: WWDC23: Demystify SwiftUI performance · Declaring a custom view — Measured in the iOS 27 simulator.

One each — two red boxes — and .onAppear ran once: the console printed "appeared".

A @ViewBuilder property with two views returns two views, not one container: there is no stack around them. A modifier applied to several views is applied to each of them — Apple says the same of Group, which exists for this: "any modifier you apply to the group affects all of that group's members." Not every modifier is repeated, though: here .onAppear ran once, not twice, so check before counting on it. When the piece is one thing — a card, a header — give it its own container inside the property (a VStack), and the border goes round the whole.

Where this comes from: Group · ViewBuilder — Measured in the iOS 27 simulator.

It does not compile. Xcode reports

function declares an opaque return type 'some View', but the return statements in its body do not have matching underlying types

No: function declares an opaque return type 'some View', but the return statements in its body do not have matching underlying types

some View promises one concrete type, chosen by the function's body — and these two returns have two, Image and Text. Mark the function @ViewBuilder and drop the returns: the builder turns the if/else into a single type that holds whichever branch is taken. Both badges then draw:

import SwiftUI

struct ContentView: View {
    var body: some View {
        HStack(spacing: 30) {
            badge(true)
            badge(false)
        }
        .font(.largeTitle)
    }

    @ViewBuilder
    func badge(_ isFavorite: Bool) -> some View {
        if isFavorite {
            Image(systemName: "star.fill")
        } else {
            Text("—")
        }
    }
}

A body needs no marking, because the View protocol declares its body requirement @ViewBuilder and every conforming type inherits it. A helper function or property you write yourself does not — it needs the attribute as soon as it has more than one possible result.

Where this comes from: ViewBuilder · Swift compiler documentation: Underlying type inference for opaque result types (OpaqueTypeInference) · The Swift Programming Language: Opaque and Boxed Protocol Types — Compiled with Xcode 27, with the strict settings Trips uses (Swift 6, no default actor isolation, Approachable Concurrency off), and run in the iOS 27 simulator.

Yes. All twelve appear, and the running app listed them in order, 1 to 12:

Older answers say no, and Apple's own Group page still shows ten texts gathered into a Group so that a stack has fewer children. The iOS 27 SDK's ViewBuilder declares a single buildBlock<each Content>(_ content: repeat each Content) — a parameter pack, the Swift 5.9 feature for functions that take any number of values of different types — so the count no longer matters. Splitting a long body into named views is still worth doing, for the reader.

Where this comes from: ViewBuilder · SE-0393: Value and Type Parameter Packs (Swift 5.9) · Group — Measured in the iOS 27 simulator; the declaration is in the iOS 27 SDK's SwiftUICore interface.

init, every time; body, not at all. Over two taps:

Header.init
Header.init

To compare the new subview with the old one, SwiftUI first needs the new one — so the parent's body makes it, and its init runs. Only the comparison saves the body. So keep initializers cheap: no formatting, sorting or loading, because whatever an init does is paid on every update of the parent. Do the work in body, which SwiftUI can skip, or in .task.

Where this comes from: WWDC23: Demystify SwiftUI performance · State — Measured in the iOS 27 simulator.

Yes — from the second update on:

The console, from launch through three taps

Row.body
Row.body
Row's == was asked
Row's == was asked

The first tap ran the row's body without asking, just as with .equatable() in this lesson's first question; after that SwiftUI asked ==, got true, and skipped the body. The conformance alone was enough. Apple documents .equatable() — it "prevents the view from updating its child view when its new value is the same as its old value" — and does not document this, so write .equatable() where you rely on it: the intent is then on the page, and does not hang on undocumented behavior.

Where this comes from: equatable() · WWDC23: Demystify SwiftUI performance — Measured in the iOS 27 simulator.

One @State copy, and four written-out ones — over three taps the console printed:

Notes.init for State(initialValue:)
Notes.init for State(initialValue:)
Notes.init for State(initialValue:)

Since Xcode 27, @State is a macro, and Apple's page for it says it "instantiates its default value the first time SwiftUI instantiates the view." Editor ▸ Expand Macro on the property shows how: the starting value is wrapped in a closure — SwiftUICore.State._makeStorage({ Notes() }) — which ran once. A plain State(initialValue: Notes()) builds its Notes every time the view is made, and every copy but the first is thrown away: that is how the old property wrapper behaved, which "always instantiates its default value when SwiftUI instantiates the view." A project built with Xcode 26 or earlier still gets the wrapper, and with it Apple's advice to create such objects in .task.

Where this comes from: State() (the macro, Xcode 27) · State — Measured in the iOS 27 simulator, built with Xcode 27.

The singleton went to the network; the injected one did not:

The console

the stand-in was asked about Bergen
the network was asked about Seattle

A view that reaches for shared takes the real thing into every preview and every test, wanted or not. One that is given its dependency — through the environment or its initializer — can be given anything. That is the whole case against singletons inside views.

Where this comes from: Environment · EnvironmentValues — Measured in the iOS 27 simulator.

The run

✓ saysWhenThereIsNoWeather(): passed (0.001 s)

Yes, and the test needed no network to find out. A fake that throws is the easiest way to test the path that is hardest to produce for real — the network failing at the right moment. Whether the seam is a protocol, a closure or a struct of closures matters less than that there is one.

Where this comes from: Swift Testing · Managing model data in your app — Run with Xcode 27 on the iOS 27 simulator.

It stops at launch — although an object of a subclass of Store was right there: "SwiftUICore/Environment+Objects.swift:34: Fatal error: No Observable object of type Store found. A View.environmentObject(_:) for Store may be missing as an ancestor of this view."

environment(_:) is generic — environment<T>(_ object: T?) — so the object is filed under T, the type of the expression it was handed: SampleStore. Apple: "The environment of a given view hierarchy holds only one observable object of a given type." The view asked for Store, another type, and found nothing. Say which type you mean, and the sample store is read:

Reader()
    .environment(SampleStore() as Store)

The same goes for any object whose static type is narrower than what the reader asks for. (For swapping implementations, a protocol is usually the better seam — but not as an environment object; the next question shows why.)

Where this comes from: environment(_:) — placing an observable object in the environment · Environment — Measured in the iOS 27 simulator.

It does not compile. Xcode reports

no exact matches in call to initializer

No: no exact matches in call to initializer

The object form of @Environment takes a class that is Observable — its initializers require T: AnyObject, T: Observable — and any WeatherSource is a box that can hold such a class, not a class itself, so none of them fits. For a dependency described by a protocol, use an environment value instead: an @Entry whose type is the protocol, with the real implementation as its default.

import SwiftUI

protocol WeatherSource: Sendable {
    func today(in city: String) -> String
}

struct LiveWeather: WeatherSource {
    func today(in city: String) -> String {
        "asks the network about \(city)"
    }
}

struct SampleWeather: WeatherSource {
    func today(in city: String) -> String {
        "12° in \(city), a sample"
    }
}

extension EnvironmentValues {
    @Entry var weather: any WeatherSource = LiveWeather()
}

struct Strip: View {
    @Environment(\.weather) private var weather

    var body: some View {
        Text(weather.today(in: "Bergen"))
    }
}

struct ContentView: View {
    var body: some View {
        VStack(spacing: 20) {
            Strip()
            Strip()
                .environment(\.weather, SampleWeather())
        }
    }
}

The first strip got the default; the second, the stand-in set just above it. The conformers here are structs on purpose: an @Entry default that makes a new class instance is made again on every read, as a lesson 19 card found.

Where this comes from: Environment · Entry() macro — Compiled with Xcode 27, with the strict settings Trips uses (Swift 6, no default actor isolation, Approachable Concurrency off), and run in the iOS 27 simulator.

The view sees the phone's locale, en_US; only its child sees de_DE.

A modifier inside body wraps what body returns — the view's children — and the environment flows down from there. The view's own @Environment properties were filled in from above it, before its body ran. To change what a view itself reads, set the value where the view is used: Greeting().environment(\.locale, …).

Where this comes from: Environment · EnvironmentValues — Measured in the iOS 27 simulator, whose region is the United States.

Yes: it showed "(nb_NO)", the locale set around it.

A ViewModifier is part of the view tree — SwiftUI renders its body(content:) the way it renders a view's body — so its @Environment properties are filled in like a view's. A model is not part of the tree, which is why it has to be handed what it needs, through its initializer or its methods.

Where this comes from: ViewModifier · Environment — Measured in the iOS 27 simulator.

Yes: replace the action it uses. Tapped, the link printed "asked to open https://www.yr.no/en" — and the app stayed where it was:

Opening a URL is a dependency like any other, and SwiftUI hands it down the environment as openURL, a value of type OpenURLAction. Apple: "Any views that read the action from the environment, including the built-in Link view and Text views with markdown links … use your action." Here the modifier sits in the screen to keep the example short; in a preview it goes round the screen instead.

Where this comes from: OpenURLAction · Environment — Measured in the iOS 27 simulator.

Run it. The console shows

metric

In a new Xcode project, yes — it printed "metric". In a Swift 6 package, no: static property 'shared' is not concurrency-safe because it is nonisolated global shared mutable state

An Xcode 27 app puts code on the main actor unless it says otherwise, so shared belongs to the main actor and only main-actor code may touch it: safe, and silent. In a package, where nothing is on the main actor by default, Swift 6 sees mutable state that any thread could reach, and refuses. A constant of a Sendable type is accepted everywhere:

final class Settings: Sendable {
    static let shared = Settings()
    let units = "metric"
}

print(Settings.shared.units)

Trips is set up like the package — Swift 6, and nothing on an actor unless it says so — so there the singleton fails as it does in the package, until it says whose it is: @MainActor on the class, or the Sendable constant above.

Either way, a singleton is still a hidden dependency: a test cannot hand the code a different Settings without changing it for every other test as well. Pass it in, as this lesson's tutorial does with the weather cache.

Where this comes from: Swift compiler documentation: Unsafe mutable global and static variables (MutableGlobalVariable) · SE-0412: Strict concurrency for global variables — Compiled with Xcode 27's Swift 6.4 compiler: with a new iOS App project's settings, and in the Swift 6 language mode without them.

It makes the request. A preview is not a drawing of your view: it is your view, really running. Apple describes the canvas's live mode as "similar to running your app on a simulated or physical device". So .task runs, the request goes out to the real server, and it does so again whenever the canvas starts the preview afresh. The preview is slow, it shows nothing without a network, and it shows different things on different days.

The cure is the habit from this lesson's tutorial: a view is given what it shows. Split the screen in two — a view that displays trips it is handed, and a thin one above it that loads them — and pass the loading in, so that a preview can supply its own:

import SwiftUI

struct Trip: Identifiable, Decodable {
    let id: Int
    var city: String
}

struct TripsList: View {              // shows trips it is given: nothing to load
    let trips: [Trip]

    var body: some View {
        List(trips) { trip in
            Text(trip.city)
        }
    }
}

struct TripsScreen: View {            // loads, then hands the result to the view above
    @State private var trips: [Trip] = []
    var load: () async -> [Trip]

    var body: some View {
        TripsList(trips: trips)
            .task { trips = await load() }
    }
}

struct ContentView: View {
    var body: some View {
        TripsScreen { [] }
    }
}

#Preview("List") {
    TripsList(trips: [Trip(id: 1, city: "Seattle"), Trip(id: 2, city: "Vancouver")])
}

#Preview("Screen") {
    TripsScreen { [Trip(id: 1, city: "Seattle")] }
}

Apple's guidance says the same: "When creating views, pass in only the data the view needs to display. Avoid passing in objects that fetch data."

You will also meet a shortcut in older code: ProcessInfo.processInfo.environment["XCODE_RUNNING_FOR_PREVIEWS"] == "1", to skip work when running in the canvas. It works, but Apple does not document it, and it means your app's code knows about your tools. Mention it; do not reach for it first.

Where this comes from: Adding previews to your interface files · Interacting with previews in the canvas · Sarunw: Detecting if a SwiftUI app is in Xcode Previews (an undocumented environment variable) — Apple, “Adding previews to your interface files”, section “Pass views only the data they need”.