In simple setups — a view behind an if condition, a sheet, a fullscreen cover — onAppear works exactly how you’d expect. Show the view, onAppear fires. Remove it, onDisappear fires. State is gone. Clean and predictable.

Then you use TabView.

You put a data fetch in onAppear on your second tab. On iOS 17, that fetch ran at app launch — even though the user was looking at the first tab. On iOS 18, same code, the fetch didn’t run until someone actually tapped the tab. Apple made TabView lazy. Same code. Different OS. Different behavior.

onAppear has had genuinely unpredictable moments across SwiftUI’s lifetime — firing twice, firing in unexpected order, not firing when you’d swear it should. For an API that every app relies on, that’s a problem.

So I spent time testing it properly, and I want to share what I found — because once you redefine one word, it all makes sense.

The word is “appears.”

This post builds on concepts from The SwiftUI AttributeGraph. If terms like “node,” “identity,” or “graph” are unfamiliar, start there.

struct ParentView: View {
    @State var showChild = true

    var body: some View {
        VStack {
            Toggle("Show Child", isOn: $showChild)
            if showChild {
                ChildView()
            }
        }
    }
}

struct ChildView: View {
    @State var userInput = ""

    var body: some View {
        TextField("Type something", text: $userInput)
            .onAppear { print("onAppear") }
            .onDisappear { print("onDisappear") }
            .task { print("task started") }
    }
}

struct ParentView: View {
    @State var showChild = true

    var body: some View {
        VStack {
            Toggle("Show Child", isOn: $showChild)
            if showChild {
                ChildView()
            }
        }
    }
}

struct ChildView: View {
    @State var userInput = ""

    var body: some View {
        TextField("Type something", text: $userInput)
            .onAppear { print("onAppear") }
            .onDisappear { print("onDisappear") }
            .task { print("task started") }
    }
}

TabView: onAppear fires on every tab switch

struct ContentView: View {
    var body: some View {
        TabView {
            Tab("First", systemImage: "1.circle") {
                FirstTab()
            }
            Tab("Second", systemImage: "2.circle") {
                SecondTab()
            }
        }
    }
}

struct FirstTab: View {
    @State var userInput = ""
    var body: some View {
        Self._printChanges()
        return TextField("Type something", text: $userInput)
            .onAppear { print("FirstTab onAppear") }
            .onDisappear { print("FirstTab onDisappear") }
    }
}

struct SecondTab: View {
    var body: some View {
        Self._printChanges()
        return Text("Second tab")
            .onAppear { print("SecondTab onAppear") }
            .onDisappear { print("SecondTab onDisappear") }
    }
}

struct ContentView: View {
    var body: some View {
        TabView {
            Tab("First", systemImage: "1.circle") {
                FirstTab()
            }
            Tab("Second", systemImage: "2.circle") {
                SecondTab()
            }
        }
    }
}

struct FirstTab: View {
    @State var userInput = ""
    var body: some View {
        Self._printChanges()
        return TextField("Type something", text: $userInput)
            .onAppear { print("FirstTab onAppear") }
            .onDisappear { print("FirstTab onDisappear") }
    }
}

struct SecondTab: View {
    var body: some View {
        Self._printChanges()
        return Text("Second tab")
            .onAppear { print("SecondTab onAppear") }
            .onDisappear { print("SecondTab onDisappear") }
    }
}

Run this. Before you tap anything, look at the console:

FirstTab: @self, @identity, _userInput changed.
FirstTab onAppear

That’s it. Only the first tab. SecondTab didn’t print anything — no onAppear, no body call, no node created, nothing. It doesn’t exist yet. TabView only builds a tab when you navigate to it for the first time.

Now tap the second tab:

SecondTab: @self changed.
SecondTab onAppear
FirstTab onDisappear

SecondTab‘s node is created now, its body is called. FirstTab disappears — but its node stays alive. I illustrated the visible view nodes in black and the “hidden” views in gray. I am not sure how this is exactly done in the AttributeGraph. I am guessing SwiftUI sets a flag on the nodes during TabView tab switching, which then triggers the onAppear/onDisappear calls that depend on this flag:

Tap back to the first tab:

FirstTab onAppear
SecondTab onDisappear

FirstTab onAppear fires again. But here’s the thing — if you typed something in that text field earlier, it’s still there. The node was never destroyed. onAppear fired because the view became visible again, not because it was recreated.

After you’ve visited both tabs, their nodes persist indefinitely. Switching tabs only triggers visibility events. Your @State in both tabs survives.

This is the split in action. onDisappear fired, but the state survived. The node was never destroyed — the view just went off screen. onAppear and onDisappear responded to visibility. @State is tied to lifetime. In TabView, those are completely different timelines.

iOS 17 note: In earlier versions, TabView built all tabs eagerly at launch. Your second tab’s onAppear would fire immediately — even though the user was looking at the first tab. If you had a data fetch in onAppear on a background tab, it ran at app launch. The lazy behavior described above is iOS 18+. Same code, different OS, different behavior. If you’re supporting iOS 17, account for both.

NavigationStack: onAppear fires during push/pop

struct ContentView: View {
    var body: some View {
        NavigationStack {
            RootView()
            .navigationDestination
        }
    }
}

struct RootView: View {
    var body: some View {
        NavigationLink("Go to Detail") {
            DetailView()
        }
        .onAppear { print("RootView onAppear") }
        .onDisappear { print("RootView onDisappear") }
    }
}

struct DetailView: View {
    @State var notes = ""

    var body: some View {
        TextField("Notes", text: $notes)
            .onAppear { print("DetailView onAppear") }
            .onDisappear { print("DetailView onDisappear") }
    }
}

struct ContentView: View {
    var body: some View {
        NavigationStack {
            RootView()
            .navigationDestination
        }
    }
}

struct RootView: View {
    var body: some View {
        NavigationLink("Go to Detail") {
            DetailView()
        }
        .onAppear { print("RootView onAppear") }
        .onDisappear { print("RootView onDisappear") }
    }
}

struct DetailView: View {
    @State var notes = ""

    var body: some View {
        TextField("Notes", text: $notes)
            .onAppear { print("DetailView onAppear") }
            .onDisappear { print("DetailView onDisappear") }
    }
}

Initially, you will see the root view. The AttributeGraph builds the view hierarchy for the NavigationStack:

Push to DetailView:

• RootView: onDisappear fires, node stays alive but becomes invisible (tagged grayed out in the AttributeGraph)
• DetailView: node created, onAppear fires

Pop back:

• DetailView: onDisappear fires, node is destroyed, @State notes is gone
• RootView: onAppear fires, node was alive the whole time, state intact

NavigationStack destroys the node when you pop. TabView keeps it. Same onDisappear call, completely different lifetime behavior underneath.

Push to DetailView again? Fresh node. notes starts again with the inital empty String.

struct ContentView: View {
    var body: some View {
        List(0..<1000) { index in
            RowView(index: index)
        }
    }
}

struct RowView: View {
    let index: Int
    @State var isExpanded = false

    var body: some View {
        Text("Row (index)")
            .padding(40)
            .onAppear { print("Row (index) onAppear") }
            .onDisappear { print("Row (index) onDisappear") }
    }
}

struct ContentView: View {
    var body: some View {
        List(0..<1000) { index in
            RowView(index: index)
        }
    }
}

struct RowView: View {
    let index: Int
    @State var isExpanded = false

    var body: some View {
        Text("Row (index)")
            .padding(40)
            .onAppear { print("Row (index) onAppear") }
            .onDisappear { print("Row (index) onDisappear") }
    }
}

1. Parent body evaluates
2. Child init runs (struct created)         ← @State is populated with initial values
3. Child body evaluates                     ← @State is read HERE
4. Layout is computed
5. onAppear fires                           
6. task starts                             
7. Rendering happens      
8. NOW on screen

1. Parent body evaluates
2. Child init runs (struct created)         
3. Child body evaluates                     
4. Layout is computed                      
5. Rendering happens      
6. NOW on screen

struct ItemListView: View {
    @State var items: [String] = []

    var body: some View {
        Text(items[0]) // <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/1f4a5.png" alt="💥" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Index out of range
            .onAppear {
                items = ["Apple", "Banana", "Cherry"]
            }
    }
}

struct ItemListView: View {
    @State var items: [String] = []

    var body: some View {
        Text(items[0]) // 💥 Index out of range
            .onAppear {
                items = ["Apple", "Banana", "Cherry"]
            }
    }
}

var body: some View {
    if let first = items.first {
        Text(first)
    } else {
        ProgressView()
    }
}

var body: some View {
    if let first = items.first {
        Text(first)
    } else {
        ProgressView()
    }
}

// <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/274c.png" alt="❌" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Fires on every tab switch
.task {
    await loadData()
}

// <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/2705.png" alt="✅" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Only fetch if you don't already have data
.task {
    guard items.isEmpty else { return }
    await loadData()
}

// ❌ Fires on every tab switch
.task {
    await loadData()
}

// ✅ Only fetch if you don't already have data
.task {
    guard items.isEmpty else { return }
    await loadData()
}

enum LoadingState {
    case idle, loading, loaded, failed(Error)
}

@State private var state: LoadingState = .idle

.task {
    guard state == .idle else { return }
    state = .loading
    do {
        items = try await api.fetchItems()
        state = .loaded
    } catch {
        state = .failed(error)
    }
}

enum LoadingState {
    case idle, loading, loaded, failed(Error)
}

@State private var state: LoadingState = .idle

.task {
    guard state == .idle else { return }
    state = .loading
    do {
        items = try await api.fetchItems()
        state = .loaded
    } catch {
        state = .failed(error)
    }
}

@State private var hasLoaded = false

.task {
    if !hasLoaded {
        await loadData()
        hasLoaded = true
    }

    // Runs every appearance
    await refreshTimestamp()
}

@State private var hasLoaded = false

.task {
    if !hasLoaded {
        await loadData()
        hasLoaded = true
    }

    // Runs every appearance
    await refreshTimestamp()
}

.task {
    print("[(Self.self)] task fired")
    await loadData()
}
.onAppear { print("[(Self.self)] onAppear") }
.onDisappear { print("[(Self.self)] onDisappear") }

.task {
    print("[(Self.self)] task fired")
    await loadData()
}
.onAppear { print("[(Self.self)] onAppear") }
.onDisappear { print("[(Self.self)] onDisappear") }

Node Lifetime: ─── created ───────────────────── destroyed 
                                       │                                                                                       │
                              @State initialized                                                            @State torn down                       


Visibility:           ───  visible ─── hidden ─── visible ───────── hidden                       
                                       │                   │                     │                                         │                       
                                   onAppear      onDisappear     onAppear                           onDisappear

The post SwiftUI View Lifecycle: When onAppear Actually fires appeared first on swiftyplace.

SwiftUI has been around since 2019. Apple has given us dozens of WWDC talks about it. And yet most developers — even experienced ones — still get tripped up by the same things:

• Why does my @State initializer get ignored?
• Why does my view’s state reset when I didn’t expect it to?
• Where is deinit? When does my data actually get cleaned up?
• Why did my entire list re-render when I changed one item?

These aren’t edge cases. They’re fundamental behaviors. And they all trace back to one thing that Apple barely talks about: the AttributeGraph.

The AttributeGraph is SwiftUI’s runtime engine. It’s the thing that decides when your views update, what data persists, and what gets thrown away. Every SwiftUI behavior that confuses you is the graph doing exactly what it was designed to do.

You don’t need to know its internal implementation. But you need to understand the model — how it thinks — because once you do, SwiftUI stops feeling like magic and starts feeling predictable.

Your View Struct Is Not the UI

This is the most important mental shift coming from UIKit.

In UIKit, your UIViewController is the thing. It holds the data. It holds the views. It has a lifecycle. You create it, you configure it, it lives, it dies.

In SwiftUI, your view struct is a description. A blueprint. SwiftUI reads it, extracts the information, feeds it into the AttributeGraph, and throws the struct away.

struct CounterView: View {
    @State var count = 0

    var body: some View {
        VStack {
            Text("(count)")
            Button("+1") { count += 1 }
        }
    }
}

struct CounterView: View {
    @State var count = 0

    var body: some View {
        VStack {
            Text("(count)")
            Button("+1") { count += 1 }
        }
    }
}

When SwiftUI processes this, the graph ends up looking roughly like this:

Each box is an attribute. Each arrow is a dependency. When count changes:

1. The count attribute is marked dirty
2. All nodes that depend on count are marked as dirty (an edge/dependency from the state to): ContentView is marked dirty
3. CounterView.body is called and compared (diff) against the old value
4. Text depends on body‘s output → the system notes the change
5. Button — did its inputs change? No → skipped
6. During the commit phase the acutual changes are passed to the underlying UIKit components: here a UILabel get a new text.

The view is used to create and update the underlying UI.

@State private var name = ""

@State private var name = ""

1. Parent's body runs and mentions YourView(...)

2. SwiftUI calls YourView.init()
   → A temporary struct is created on the stack
   → @State property contains State<String>(initialValue: "")
   → This is just a DESCRIPTION — no storage yet

3. SwiftUI checks the view's position in the tree (Structural Identity)
   → "Have I seen a view at this position before?"

4. First time → NO
   → Allocate a new attribute in the graph
   → Store the initial value ""
   → Connect the @State handle to this attribute

5. SwiftUI calls body on the struct
   → body READS name
   → Graph records a dependency: "body depends on name"

6. SwiftUI throws away the struct
   → The struct is gone
   → The attribute in the graph remains

Single Source of Truth: A Graph Topology

You’ve heard this phrase a hundred times. Here’s what it means in terms of the graph.

The Problem: Two @State = Two Attributes

struct ParentView: View {
    @State var count = 0

    var body: some View {
        VStack {
            Button("+1") { count += 1 }
            ChildView(name: "Updated: (count)")
        }
    }
}

struct ChildView: View {
    @State var name: String

    var body: some View {
        Text(name) // Always shows "Updated: 0"
    }
}

struct ParentView: View {
    @State var count = 0

    var body: some View {
        VStack {
            Button("+1") { count += 1 }
            ChildView(name: "Updated: (count)")
        }
    }
}

struct ChildView: View {
    @State var name: String

    var body: some View {
        Text(name) // Always shows "Updated: 0"
    }
}

This creates two attributes in the graph, which i colored in blue:

The user taps the button. Only ParentView.count updates. ChildView.name is still "Update 0". They have drifted apart. There is no edge connecting them for ongoing sync — the value was copied once at init and that’s it.

The Fix: One @State + @Binding = One Attribute

struct ParentView: View {
    @State var count = 0

    var body: some View {
        VStack {
            Button("+1") { count += 1 }
            ChildView(name: "Updated: (count)")
        }
    }
}

struct ChildView: View {
    let name: String

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

struct ParentView: View {
    @State var count = 0

    var body: some View {
        VStack {
            Button("+1") { count += 1 }
            ChildView(name: "Updated: (count)")
        }
    }
}

struct ChildView: View {
    let name: String

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

There is only one @State declaration which SwiftUI interprets and creates one attribute for in the AttriibuteGraph. This one single source of truth that both ParentView and ChildView will reflect.

Dependencies: How the Graph Knows What to Update

When your view is first time added to the view hierarchy, the system needs to add the edges/dependencies. The are differnt ways/styles that determine the rules.

First lets look at value types with @State and @Binding:

struct MyView: View {
    @State var name = ""       // @state create a node and the edge/dependency
    @Binding var name: String  // no edge, the updates are discovered during view tree walking 
    let age: Int               // no edge, the updates are discovered during view tree walking    

    var body: some View {
        Text(name) // body reads `name` but NOT `age`
    }
}

struct MyView: View {
    @State var name = ""       // @state create a node and the edge/dependency
    @Binding var name: String  // no edge, the updates are discovered during view tree walking 
    let age: Int               // no edge, the updates are discovered during view tree walking    

    var body: some View {
        Text(name) // body reads `name` but NOT `age`
    }
}

Similarly for ObservableObject:

struct ParentView: View {
    @StateObject var myObject = MyObject()           // @StateObject create a node and the edge/dependency
    @StateObject var otherObject = OtherObject()     // @StateObject create a node and the edge/dependency
    var body: some View {
        MyView(myObject: myObject, otherObject: otherObject)
    }
}

struct MyView: View {
    @ObservedObject var myObject: MyObject          // edge to existing node 
    var otherObject: OtherObject                    // no edge, changes to this object will not be tracked

    var body: some View {
        Text(myObject.name) 
        Text(otherObject.count)
    }
}

struct ParentView: View {
    @StateObject var myObject = MyObject()           // @StateObject create a node and the edge/dependency
    @StateObject var otherObject = OtherObject()     // @StateObject create a node and the edge/dependency
    var body: some View {
        MyView(myObject: myObject, otherObject: otherObject)
    }
}

struct MyView: View {
    @ObservedObject var myObject: MyObject          // edge to existing node 
    var otherObject: OtherObject                    // no edge, changes to this object will not be tracked

    var body: some View {
        Text(myObject.name) 
        Text(otherObject.count)
    }
}

@StateObject tells the graph: “Allocate a persistent attribute for this object and keep it alive as long as this view’s identity exists.” Same rules as @State — created once, survives struct recreation, destroyed when identity is removed.

SwiftUI sees the property wrappers and creates the edges in the AttributeGraph, which basically says “when any property in the ObservableObject changes, check these views for updates”. Note that without these property wrappers the graph has no pointer/edge and does not know to update this view.

For Observable feature the rules are different. The edges are created towards the single properties in the Obervable and are set if they are accessed in the view:

struct ParentView: View {
    @State var myObject = MyObject()    // @StateObject create a node 
    var body: some View {
        MyView(myObject: myObject)     // no edge for dependency tracking,
                                       // because the body does not access any property
    }
}

struct MyView: View {
    var myObject: MyObject

    var body: some View {
        Text(myObject.name)    // read access -> edge to node "myObject.name" 
    }
}

struct ParentView: View {
    @State var myObject = MyObject()    // @StateObject create a node 
    var body: some View {
        MyView(myObject: myObject)     // no edge for dependency tracking,
                                       // because the body does not access any property
    }
}

struct MyView: View {
    var myObject: MyObject

    var body: some View {
        Text(myObject.name)    // read access -> edge to node "myObject.name" 
    }
}

When using the new SwiftUI instrument feature, you will see the dependencies from the AttributeGraph. I gives you the `transactions` a list of state changes that is processed in batch per update frame. Then in blue the @State attributes and the edge/dependencies that are used from the AttributedGraph. It gives a lot of details like what views are further evaluatd and what SwiftUI views are updated e.g. Text views content. It basically shows you a part of the AttributeGraph and what state caused the upate and what views depend on it:

In this example, I am not only updating the view that directly depends on the state which is SubView, but also other views that recieve data from there parent views. SwiftUI is bacially “walking the tree” from top to botttom, which is also why the data flow is top to bottom from parent to child. But that is a different blog post on its own (when body is called, diff, and inits).

When Does State Die?

In UIKit, you know exactly when data dies — deinit. You see it. You control it.

In SwiftUI there’s no deinit on your view struct (it’s a value type — it just pops off the stack). So when does the graph clean up?

When the view’s identity is removed from the tree.

struct ParentView: View {
    @State var showChild = true

    var body: some View {
        VStack {
            Toggle("Show", isOn: $showChild)
            if showChild {
                ChildView()
            }
        }
    }
}

struct ChildView: View {
    @State var count = 0

    var body: some View {
        Button("Count: (count)") { count += 1 }
    }
}

struct ParentView: View {
    @State var showChild = true

    var body: some View {
        VStack {
            Toggle("Show", isOn: $showChild)
            if showChild {
                ChildView()
            }
        }
    }
}

struct ChildView: View {
    @State var count = 0

    var body: some View {
        Button("Count: (count)") { count += 1 }
    }
}

1. showChild is true. ChildView appears. The graph creates an attribute for count with value 0.
2. You tap the button a few times. count is now 5.
3. Toggle showChild to false. The if branch removes ChildView from the tree.
4. SwiftUI sees that ChildView‘s identity is gone → destroys all its attributes. count is gone.
5. Toggle showChild back to true. ChildView appears again. The graph creates a new attribute for count with value 0.

The old count = 5 is gone forever. This is your deinit — not on the struct, but on the identity in the graph.

var body: some View {
    VStack {
        Text("Hello")   // ← identity: VStack/child-0
        Text("World")   // ← identity: VStack/child-1
    }
}

var body: some View {
    VStack {
        Text("Hello")   // ← identity: VStack/child-0
        Text("World")   // ← identity: VStack/child-1
    }
}

var body: some View {
    if isLoggedIn {
        HomeView()      // ← identity: if-true-branch
    } else {
        LoginView()     // ← identity: if-false-branch
    }
}

var body: some View {
    if isLoggedIn {
        HomeView()      // ← identity: if-true-branch
    } else {
        LoginView()     // ← identity: if-false-branch
    }
}

ForEach(items, id: \.id) { item in
    RowView(item: item)
}

ForEach(items, id: \.id) { item in
    RowView(item: item)
}

ChildView()
    .id(someValue)

ChildView()
    .id(someValue)

The Update Cycle: Putting It All Together

Here’s the full picture of what happens when you change a @State value:

1. You set count = 5
   → The @State handle writes to its attribute in the graph

2. The attribute marks itself as DIRTY

3. The graph walks DOWN through dependency edges
   → Every attribute that depends on `count` is marked dirty

4. SwiftUI schedules a re-evaluation (batched — not immediate)

5. On the next render pass, SwiftUI visits each dirty attribute
   → Calls body on views whose body attribute is dirty (starts in the highest node in the attribute graph, closest to @main)
   → body returns new view descriptions
   → diffing: compares old and new values to decide whats changed
   → markes custom views as invalide if there input changed
   → continuesly calls  body for invalidated subviews

6. Commit phase: changes are passed to the underlying rendering engine

7. Next frame: UI shows new display for updated state

This is why SwiftUI is fast. It doesn’t re-evaluate your entire view tree. It follows the dependency edges from the changed node downward and only touches what’s necessary. When it calls a body, it means it checks if it needs updating and only when it finds changes these are actually implemented. The whole system is very complex and Apple engineers have been working constantly on improving the reliability and performance of the system.

The UIKit SwiftUI Translation Table

Practical Implications

Everything above leads to a set of rules that aren’t suggestions — they’re consequences of how the graph works:

1. Don’t use @State for data passed from a parent. The graph allocates the attribute once and ignores future init values. Use @Binding or just a let constant.

2. Don’t sync two @State properties manually. Two @State = two attributes. Use one @State and pass @Binding references down.

3. Put your source of truth as low as possible, but high enough so that all views can access it. When an attribute changes, every dependent below it might be re-evaluated. If your @State is at the root, a change can cause many updated down the entire tree.

4. @StateObject for objects you create. @ObservedObject for objects you receive. This maps directly to whether the graph allocates storage or just watches.

5. init() is not your setup point. It runs every time the parent re-evaluates. The graph decides whether to use your initial values or ignore them.

Your view struct is the top layer. The graph is the middle layer. The screen is the output. You write the top layer. The graph does the rest.

When something doesn’t behave the way you expect, the answer is almost always in the middle layer: which attribute exists, what it’s connected to, and whether its identity is still in the graph.

Further Reading

• Managing User Interface State — Apple Documentation
• Demystify SwiftUI — WWDC21
• Data Essentials in SwiftUI — WWDC20

The post The AttributeGraph – The Engine Behind Every SwiftUI View appeared first on swiftyplace.

“Is this code running on the main thread?”

You might try the old line:

print(Thread.isMainThread ? "is on Main Thread" : "not on Main Thread")

…and get hit with this Swift 6 compiler error:

 ‘Thread.isMainThread’ is unavailable from asynchronous contexts
“Work intended for the main actor should be marked with @MainActor; this is an error in the Swift 6 language mode.”

So what now?

Stop thinking in threads. Start thinking in actors.

In Swift Concurrency, the real question isn’t “which thread?”, it’s:

“Which actor am I on?”

• UI work must happen on the MainActor
• Heavy work should run off the MainActor
• Actor isolation is what protects your code — not threads.

Actors manage serial execution and data safety. Threads are implementation details.

Use MainActor.assertIsolated() to debug actor isolation

During development, you can assert that you’re on the MainActor like this:

func updateUI() {
    MainActor.assertIsolated("UI updates must happen on MainActor!")
    self.title = "Loaded"
}

If you ever call this function from the wrong actor, it stops you immediately during development.

What it does:

• In Debug builds (Xcode default): Crashes immediately if you’re not on the MainActor
• In Release builds: Does nothing (zero cost)

Want a hard crash in all builds? Use preconditionIsolated

MainActor.preconditionIsolated("UI must be touched on MainActor")

This crashes in Debug and Release. Use this when calling from the wrong actor would be a logic error in production.

What does the crash actually look like?

When the assertion fails, your app will just trap:

In the Xcode debugger navigator, you’ll see:

Task 1 Queue : com.apple.root.user-initiated-qos.cooperative (concurrent)

9 ContentView.fetchAndDecode(query:)
10 ContentView.load()

This tells you:

• Queue ... (concurrent) You are not on the MainActor
• You are running on a background actor with .userInitiated QoS
• This task is off the main thread and outside the UI actor

If you’re on the MainActor:

Queue: com.apple.main-thread (serial)

That queue name is your runtime hint about actor context.

What about custom global actors?

You can create your own actor — and use the same assertion methods:

@globalActor
actor ImageCacheActor {
    static let shared = ImageCacheActor()
}

@ImageCacheActor
func mutateCache() {
    ImageCacheActor.assertIsolated("must be on ImageCacheActor")
    // safe to touch cache here
}

It works just like MainActor.assertIsolated.

There’s no assertNotMainActor, so if you want to make sure you’re not on main, you can drop in a MainActor.assertIsolated("should NOT be main") as a temp check and see if it crashes — if it doesn’t, then you’re on main and now you know. You can also add a breakpoint and read the Task value from the debug navigator area.

Summary

Swift 6 enforces proper actor usage. Take it seriously — it saves you from race conditions and UI bugs. Forget Thread.isMainThread. Ask instead:“Am I on the actor I expect to be on?”

During development:

• Use assertIsolated to catch mistakes early
• Use Xcode’s Queue info to understand runtime actor context
• Use custom logs to visualize where hops are happening

Stay actor-aware, and let the compiler + runtime do the heavy lifting.
You’re not just managing threads anymore — you’re designing concurrency.

The post Debugging Swift Concurrency: “Am I on the Main Actor?” (Not the Main Thread) appeared first on swiftyplace.

Because I really want to know how capable the local llm is, I build a more complex app. This isn’t just another demo project. We’re building a real-world AI chatbot that can handle complex conversations, remember context, and even enhance its knowledge with custom data when needed.

Download project files

Building a Real-World AI Chat App

Our demo app is a “Dog Helper” that showcases practical AI implementation. Users can:

1. Ask preset questions like “Tell me about Border Collies”
2. Have natural conversations – ask follow-ups like “Are they good with kids?”
3. Get enhanced answers – when the local model lacks knowledge, we use tool calling to fetch additional data
4. Handle unknown breeds – for rare breeds like “Caucasian Shepherd,” the AI gracefully uses our custom data

The magic happens when you ask about allergy-friendly dogs. Instead of generic answers, our tool calling system searches through curated breed data and returns specific recommendations.

What is Apple’s Foundation Models Framework?

The Foundation Models framework gives you direct access to Apple’s local large language model (LLM) – the same AI brain behind Siri’s new capabilities and Apple Intelligence features. Think of it as having ChatGPT built right into your iPhone, but completely private and offline.

This is huge because:

• Zero API costs – no more paying per request to OpenAI or Claude
• Complete privacy – all AI processing happens on-device
• Lightning fast – no network latency, instant responses
• Always available – works in airplane mode or poor connectivity

Understanding Foundation Models vs Apple’s Foundation Framework – Common Naming Confusion

Don’t get confused by the name! Apple’s Foundation Models framework is completely different from their older Foundation framework.

In AI terminology, a “foundation model” means a general-purpose base model that you can customize for specific tasks. It’s called “foundation” because it’s the foundation you build specialized AI features on top of.

Foundation Models Performance and Limitations

Technical Specifications That Matter:

• 3 billion parameters (vs ChatGPT’s 100+ billion)
• 3GB RAM usage (why newer devices are required)
• 4,096 token context window (conversations have memory limits)
• Text-only input/output (no image processing)
• Knowledge cutoff: End of 2023
• 16 language support (check model.supportedLanguages)
• Adapter compatibility for fine-tuning specific use cases

What This Model Excels At:

• Text summarization – Great for condensing content
• Information extraction – Pull structured data from text
• Content classification – Categorize text by type/topic
• Simple content generation – Basic writing tasks

What To Avoid Using It For:

• Philosophy or complex reasoning – Too small for deep thinking
• Current events – Knowledge cutoff limitations
• Advanced math – Prone to calculation errors
• Creative writing – Limited compared to larger models

Device Compatibility Requirements – The Hard Truth About Apple Intelligence Availability

Here’s what you need before diving in – and it’s more limited than you might think:

iPhone Compatibility for Foundation Models Framework

• iPhone 15 Pro and 15 Pro Max (A17 Pro chip)
• All iPhone 16 models (A18 chip)
• Older iPhones won’t work – sorry iPhone 13/14 users

iPad Support for On-Device AI

• iPad Mini 7th gen (A17 Pro)
• iPad Air M1/M2 models
• iPad Pro M1/M2/M4 models
• Older iPads are incompatible – even recent non-Pro models

Mac Requirements for Foundation Models

• Any Mac with M1, M2, M3, or M4 chips
• Intel Macs are completely unsupported
• macOS Sequoia 15.2+ required

Plus, Apple Intelligence must be downloaded and enabled (3GB download, 30-minute setup).

Market Reality – How Many Users Can Actually Use Your AI App?

Let’s talk numbers. Based on a current device adoption roughly:

• Only 15% of iPhones can run Foundation Models apps
• 30% of iPads are compatible (thanks to M1 adoption)
• 50% of Macs support it (M-series popularity growing)

This means your app needs robust fallbacks. Don’t build AI-only features – always have non-AI alternatives ready.

How to Check Device Compatibility

Smart developers always check compatibility first. Here’s the complete implementation:

import SwiftUI
import FoundationModels

struct ContentView: View {
    private var model = SystemModel.default

    var body: some View {
        switch model.availability {
        case .available:
            // Device supports AI - show full features
            ChatbotView()

        case .unavailable(.modelNotReady):
            // Compatible device, but AI model still downloading
            ModelDownloadingView()

        case .unavailable(.deviceNotEligible):
            // Old device - offer alternative features
            NonAIFallbackView()

        case .unavailable(.appleIntelligenceNotEnabled):
            // User needs to enable Apple Intelligence
            EnableIntelligenceView()
        }
    }
}

Testing Device Compatibility States in Xcode Simulator

Apple made testing easy with built-in simulator options. In your Xcode scheme settings:

1. Go to Run → Arguments → Environment Variables
2. Find “Simulating foundation model availability”
3. Set values like:
   • deviceNotEligible – Test old device flow
   • appleIntelligenceNotEnabled – Test setup flow
   • modelNotReady – Test download state

This lets you test all compatibility scenarios without owning multiple devices

Running Foundation Models in Playgrounds

Let’s start simple with a playground to understand the basics:

import FoundationModels
import Playgrounds

#Playground {
    
    // Create a language model session
    let session = LanguageModelSession()

    // Define your prompt
    let prompt = "What is the meaning of life?"

    // Get AI response (async operation)
    do {
        let response = try await session.respond(to: prompt)
        
        print(response.content) // This is your AI-generated text
    } catch {
        print("AI generation failed: (error)")
    }
}

Performance reality check: This took 23 seconds on an M1 Mac for a philosophical question. The model runs at your device’s speed – no cloud acceleration here.

Handling AI Generation Errors and Guardrails

The Foundation Models framework has strict safety measures:

do {
    let response = try await session.response(to: prompt)
    return response.content
} catch let error as FoundationModels.GenerationError {
    switch error.type {
    case .exceedsContextWindowSize:
        // Conversation too long - start new session
        return "Let's start a fresh conversation"

    case .guardrailViolation:
        // Content flagged as unsafe
        return "I can't help with that request"

    case .unsupportedLanguage:
        // User used non-supported language
        return "Please ask in English or another supported language"

    case .rateLimited:
        // App backgrounded - system prioritizing foreground apps
        return "Please try again in a moment"

    case .concurrentRequests:
        // Multiple requests on same session
        return "Please wait for current response to complete"

    default:
        return "Something went wrong with AI generation"
    }
}

Real-World Example – Building a Dog Breed Knowledge Assistant

Let’s test the model’s knowledge boundaries with a practical example:

// Test with well-known breed
let borderColliePrompt = "Tell me about Border Collies for apartment living"
// Result: Good general knowledge, reasonable advice

// Test with rare breed
let caucasianPrompt = "Can I keep a Caucasian Shepherd in an apartment?"
// Result: Hallucination! Says they're "wonderful apartment companions"

The problem: The model confidently gives wrong advice about a 150-pound protective breed being apartment-friendly. This is why tool calling becomes essential.

Why Tool Calling Is Essential for Production AI Apps

The local model has knowledge gaps. When it doesn’t know something, it often guesses wrong instead of admitting ignorance. Tool calling lets you:

1. Detect knowledge gaps – Recognize when the model lacks specific info
2. Fetch accurate data – Pull from your curated database
3. Enhance responses – Combine AI reasoning with factual data
4. Maintain accuracy – Prevent harmful misinformation

Think of tool calling as giving your AI access to Google, but with your own trusted data sources.

Working Around Text-Only Limitations with Vision Framework Integration

The Foundation Models framework only handles text, but you can build powerful workflows:

// 1. User takes photo of a recipe
// 2. Use Vision framework to extract text from image
// 3. Pass extracted text to Foundation Models
// 4. AI formats and structures the recipe data

This pattern works great for:

• Document scanning – Extract and process text from images
• Recipe digitization – Photo to structured recipe data
• Text translation – OCR + AI translation
• Content organization – Extract and categorize information

Choosing the Right Use Cases for 3-Billion Parameter Models

The model size matters. Here’s when Foundation Models work well vs when you need alternatives:

Perfect Use Cases

• App help chatbots – Answer questions about your app’s features
• Content summarization – Condense long text into key points
• Data extraction – Pull specific info from unstructured text
• Simple classification – Categorize content by type or sentiment

Consider Cloud APIs Instead

• Creative writing – Need larger models for quality output
• Complex reasoning – Mathematical or logical problem solving
• Current information – Anything requiring up-to-date knowledge
• Multi-language support – Beyond the 12 supported languages

Configuring Your Language Model Session for Production Apps

The LanguageModelSession has several important parameters you can customize:

let session = LanguageModelSession(
    model: .default, // Can use custom adapters here
    guardrails: .default, // Safety filters (strict by default)
    tools: [], // We'll add tool calling in part 2
    instructions: """
        You are a dog specialist. Your job is to give helpful 
        advice to new dog owners.
        """
)

Setting Effective System Instructions

Instructions are more powerful than regular prompts. They define your AI’s personality and boundaries:

let instructions = """
You are a dog specialist. Your job is to give helpful advice to new dog owners.
"""

// Test the boundaries
// User asks: "What is 1 + 1?"
// AI responds: "I'm sorry, I cannot assist with that request."

Instructions act as strong guardrails – even when users try to misuse your app, the AI stays in character.

Controlling AI Response Quality with Generation Options

Temperature Settings for Creativity Control

let options = GenerationOptions(
    sampling: .default, // Balanced creativity
    temperature: 1.0,   // 0 = robotic, 2 = chaotic
    maxTokens: nil      // Let it finish thoughts naturally
)

Avoid these common mistakes:

• temperature: 0 = Always identical, robotic responses
• temperature: 2 = Too random and incoherent
• Setting maxTokens too low = Cut off mid-sentence

Better Ways to Control Response Length

Instead of limiting tokens (which cuts off responses), use natural language:

// ❌ Bad: maxTokens: 200 (cuts off mid-sentence)

// ✅ Good: Add to instructions
"Keep responses to 100-200 words"
"Answer in 2 paragraphs" 
"Give brief, concise answers"

Implementing Real-Time Streaming Responses

Nobody wants to wait 23 seconds staring at a blank screen. Streaming shows text as it generates:

class ChatViewModel: ObservableObject {
    @Published var partialGenerated: String.PartialGenerated?
    @Published var isResponding = false
    private var streamingTask: Task<Void, Never>?

    func sendMessage(_ userInput: String) {
        isResponding = true

        streamingTask = Task {
            do {
                let stream = try session.streamResponse(to: userInput)

                for try await partial in stream {
                    // Check if task was cancelled
                    guard !Task.isCancelled else { break }

                    // Update UI with each new token
                    await MainActor.run {
                        self.partialGenerated = partial
                    }
                }

                // Streaming complete
                await MainActor.run {
                    self.isResponding = false
                    self.saveResponse()
                }

            } catch {
                await MainActor.run {
                    self.handleError(error)
                }
            }
        }
    }
}

Creating Smooth Streaming Animations in SwiftUI

Make your streaming responses feel polished with proper animations:

struct StreamingResponseView: View {
    let partialResponse: String.PartialGenerated

    var body: some View {
        Text(partialResponse.content, format: .markdown)
            .padding()
            .background(.gray.opacity(0.1), in: RoundedRectangle(cornerRadius: 12))
            .contentTransition(.opacity)
            .animation(.bouncy, value: partialResponse)
    }
}

Key animation principles:

• Use .animation(.bouncy, value: partialResponse) for smooth text updates
• Add .contentTransition(.opacity) to avoid choppy text changes
• Keep transition duration short (0.2-0.5 seconds max)

Fixing View Identity Problems

When streaming text replaces with final messages, SwiftUI can get confused about view identity:

// ❌ Causes UI jumps
ForEach(messages) { message in
    MessageView(message: message)
}
if let partial = partialGenerated {
    StreamingView(partial: partial)
}

// ✅ Fixed with consistent IDs
ForEach(messages) { message in
    MessageView(message: message)
        .id(message.id)
}
if let partial = partialGenerated {
    StreamingView(partial: partial)
        .id(partialId ?? UUID()) // Same ID used for final message
}

class ChatViewModel: ObservableObject {
    @Published var messages: [ChatMessage] = []
    @Published var userInput = ""
    private var session: LanguageModelSession
    private let instructions = "You are a dog specialist..."

    func resetSession() {
        // Cancel any ongoing streaming
        streamingTask?.cancel()

        // Clear UI state
        messages.removeAll()
        partialGenerated = nil
        isResponding = false

        // Create fresh session (important!)
        session = LanguageModelSession(instructions: instructions)
    }

    private func saveResponse() {
        guard let partial = partialGenerated else { return }

        // Add AI response to chat history
        messages.append(ChatMessage(
            id: partialId ?? UUID(),
            role: .assistant,
            content: partial.content
        ))

        // Clear streaming state
        partialGenerated = nil
        partialId = nil
    }
}

Proper Progress Indication

Show loading states only when appropriate:

if isResponding && partialGenerated == nil {
    // Show spinner only before streaming starts
    ProgressView()
} else if let partial = partialGenerated {
    // Show streaming content
    StreamingResponseView(partial: partial)
}

Handling Concurrent Requests and Session Limits

Each LanguageModelSession can only handle one request at a time:

func sendMessage(_ input: String) {
    // Prevent multiple concurrent requests
    guard !session.isResponding else { return }

    // Or create multiple sessions for parallel processing
    let newSession = LanguageModelSession(instructions: instructions)
}

Session management strategies:

• Single session: Simple conversations with memory
• Multiple sessions: Parallel processing different topics
• Session pools: Handle high-volume concurrent requests

Real-World Error Handling and User Feedback

The Foundation Models framework can fail in various ways. Handle them gracefully:

private func handleStreamingError(_ error: Error) {
    if let genError = error as? FoundationModels.GenerationError {
        switch genError.type {
        case .guardrailViolation:
            showMessage("I can't help with that type of request")
        case .exceedsContextWindowSize:
            showMessage("This conversation is getting too long. Let's start fresh!")
            resetSession()
        case .rateLimited:
            showMessage("I'm busy with other tasks. Please try again in a moment")
        default:
            showMessage("Something went wrong. Please try again")
        }
    }
}

Performance Optimization Tips for On-Device AI

Memory Management

• Monitor memory usage – the 3B model uses ~3GB RAM
• Consider releasing sessions when not needed
• Test on real devices, not just simulators

Battery Impact

• Long AI generations drain battery quickly
• Consider limiting response length for mobile use
• Show battery usage warnings for intensive tasks

Background Handling

• AI requests get rate-limited when app goes to background
• Save conversation state before backgrounding
• Resume gracefully when returning to foreground

What’s Next: Tool Calling and Knowledge Enhancement

This basic chatbot is just the foundation. The real power comes with tool calling – letting your AI fetch current data, search databases, and enhance its knowledge beyond the 2023 training cutoff.

In the next tutorial, we’ll add:

• Custom tool functions to fetch dog breed data
• Intent detection to decide when to use tools
• Knowledge enhancement for accurate, up-to-date responses
• Structured data integration with your app’s backend

The Foundation Models framework gives you a solid base for on-device AI, but tool calling makes it production-ready for real-world applications.

Download project files

Ready to enhance your chatbot with tool calling? Check out part 2 of this series where we add custom data sources and make our AI truly intelligent.

The post Building an AI Chatbot in SwiftUI with Foundation Models Framework appeared first on swiftyplace.

• What XCTest is and how it works
• How to write and run tests in Xcode
• Test basic logic in a ViewModel
• Avoid common testing mistakes
• Understand what parts of your app are worth testing

This guide is aimed at intermediate iOS developers—those who know Swift, have written apps, maybe even shipped a few—but haven’t yet made testing a regular habit. You’ll learn how to test logic without wasting time or overengineering your codebase.

How to Add Unit Tests to Your Xcode Project

Step 1: Create a Test Target

If your project doesn’t already have one:

1. In Xcode, go to File > New > Target
2. Choose XCTest for Unit and UI Test
3. Call it ItemAppTests

Step 2: Add Your First Test Case

By default, your app code is not visible in your test target unless you mark it as public. But constantly marking internal stuff as public just for testing is dumb.

Instead, use this in your test files:

@testable import YourApp

This allows your test code to access internal stuff—functions, classes, etc.—without changing your access levels just for testing.

You write unit tests by subclassing XCTestCase. This is a simple test function:

import XCTest
@testable import ItemApp

final class ItemAppTests: XCTestCase {
    func test_example() {
        XCTAssertTrue(true)
    }
}

Let’s break it down:

• import XCTest gives you the test tools.
• @testable import ItemApp makes your app’s internal classes accessible to your test target.
• The class must inherit from XCTestCase.
• Every test method starts with test – otherwise it won’t run.
• XCTAssertTrue(true) is just a placeholder—it’s a way to make the test pass.

How to Run Your Tests

You can run your tests from anywhere in Xcode. There are three ways:

1. The diamond icon
   Look to the left of any test method or class in the gutter.
   Click it to run that specific test.

2. Keyboard shortcut: ⌘ + U
   This runs all tests in your project.

3. Product > Test from the top menu.

If a test fails, Xcode will highlight the failed line and show you the actual vs expected values in the Test navigator on the left sidebar.

What Is XCTAssert?

XCTest provides a bunch of XCTAssert* functions to check if your code does what you expect.

Here are the most useful ones:

Example:

let count = 3
XCTAssertEqual(count, 3)
XCTAssertTrue(count > 0)
XCTAssertNotNil(viewModel.items.last)

If any of these assertions fail, the test fails, and you get clear feedback inside Xcode.

To help you understand what is going on when soemthing breaks later, you can add failure messages:

XCTAssertEqual(count, 3, "Expect that the item count is 3")
XCTAssertTrue(count > 0, "We should have at least have 1 item")

Testing a SwiftUI app with MVVM design pattern

We have a small SwiftUI app where users can:

• Add new Items by name.
• Remove the last item in the list.
• See all items displayed in a scroll view.

All state is handled by an ItemViewModel, which looks like this:

final class ItemViewModel: ObservableObject {

    @Published var items: [Item] = Item.examples
    @Published var deleteDisabled = false

    func deleteLastItem() {
        guard items.isEmpty == false else { return }
        items.removeLast()
        deleteDisabled = items.isEmpty
    }

    func addItem(name: String) {
        items.append(Item(name: name))
        deleteDisabled = items.isEmpty
    }
}

It also exposes a flag deleteDisabled which reflects whether deletion should be possible.

These methods contain simple logic, but that logic can break silently when refactoring or adding new features. That’s why we write unit tests—to lock down behavior and catch breakages immediately.

This is a good starting point because:

• It has simple logic we can test.
• It changes state in ways we can verify.
• It doesn’t depend on UI or system APIs.

Test 1: Adding an Item Should Increase the Count

We want to test that calling addItem(name:) correctly updates the items array.

We’re going to follow a clean test structure following “Given-When-Then”:

func test_add_new_item() {
    // --- GIVEN ---
    //  the initial state

    // --- WHEN ---
    // the action being tested    

    // --- THEN ---
    // the expected result
}

What are we testing?

• That the item count increases by 1
• That the last item in the list matches the name we added

func test_add_new_item() {
    // --- GIVEN ---
    let vm = ItemViewModel()
    let initialCount = vm.items.count
    let expectedName = "Test Item"

    // --- WHEN ---
    vm.addItem(name: expectedName)

    // --- THEN ---
    XCTAssertEqual(vm.items.count, initialCount + 1, 
                   "Item cound should be increased by onw")
    XCTAssertEqual(vm.items.last?.name, expectedName, 
                   "Expected that the last items title is the new items title")
}

This catches mistakes like forgetting to append the item or accidentally overwriting the array. It’s your first line of defense when logic changes.

Making Tests more Resilient for Future Refactoring

When writing tests, you should try to write them in a flexibile way so that they will pass in the future. To explain this look at this test implementation:

func test_add_new_item() {
    // --- GIVEN ---
    let vm = ItemViewModel()

    // --- WHEN ---
    vm.addItem(name: "Test Item")

    // --- THEN ---
    XCTAssertEqual(vm.items.count, 4, 
                   "Item cound should be increased by one")
    XCTAssertEqual(vm.items.last?.name, "Test Item", 
                   "Expected that the last items title is the new items title")
}

I set the new item count to 4. Which works as long as i start with exactly 3 items. But what happens when in the future I change the starting point and have a larger intitial items array? – You guessed it. The hardcode value of 4 will fail the test. This would be a false alarm, if the actuall behavior is still correct. In order to avoid false alarms, try to avoid hard coded assertions like we did in the above example and use more flexible assertions like:

    let vm = ItemViewModel()
    let expectedCount = vm.iems.count - 1

Test 2: Deleting the Last Item Should Remove It

We want to ensure that deleteLastItem() removes exactly one item and that the correct one is removed.

What are we testing?

• That the count is reduced by 1
• That the item previously at the end is no longer in the list

func test_delete_last_item() {
    // --- GIVEN ---
    let vm = ItemViewModel()
    let initialItems = vm.items
    let lastItem = initialItems.last
    let expectedCount = initialItems.count - 1

    // --- WHEN ---
    vm.deleteLastItem()

    // --- THEN ---
    XCTAssertEqual(vm.items.count, expectedCount, 
                  "Expected that the item count is lowered by one")
    XCTAssertFalse(vm.items.contains(where: { $0.id == lastItem?.id }), 
                  "Should have deleted last item")
}

If you change how deletion is implemented—say, filtering instead of removing the last—you might introduce subtle bugs. This test guards against that.

Test 3: Deleting All Items Should Disable the Delete Button

This one checks the deleteDisabled flag. When the list becomes empty, the delete button in the UI should be disabled. This flag is driven by internal logic, not UI state.

What are we testing?

• That deleteDisabled becomes true when the list is empty

func test_when_all_items_deleted_then_delete_is_disabled() {
    // --- GIVEN ---
    let vm = ItemViewModel()

    // --- WHEN ---
    while !vm.items.isEmpty {
        vm.deleteLastItem()
    }

    // --- THEN ---
    XCTAssertTrue(vm.deleteDisabled, "Delete should be disabled for empty items array")
}

This test is protecting user experience. If deleteDisabled isn’t set correctly, the delete button could remain active and trigger unexpected behavior in the UI.

Test 4: Adding an Empty Name Is Allowed (for Now)

This test checks a behavioral detail: should the ViewModel accept empty strings as item names? Currently, yes. We want to write a test that defines and locks in this behavior.

What are we testing?

• That items with empty names are accepted and added to the list

func test_add_empty_name_item_is_allowed() {
    // --- GIVEN ---
    let vm = ItemViewModel()

    // --- WHEN ---
    vm.addItem(name: "")

    // --- THEN ---
    XCTAssertEqual(vm.items.last?.name, "", 
                   "Should be allowed to add an item with emppty name field")
}

Even if this seems trivial, it locks in expected behavior. Later, if you add input validation, this test will fail—and that’s exactly what you want: clear visibility into changed assumptions.

That’s a solid principle—and yes, Vladimir Khorikov’s approach (from his Unit Testing book) is pragmatic and aligns well with long-term maintainability: don’t test everything—test what matters.

Let’s revise and expand the “What to test” section using that mindset:

What to Test: Focus on Logic That Matters

You don’t need to test everything. You need to test what can hurt you.

A good rule of thumb (inspired by Vladimir Khorikov’s Unit Testing book):

Test code that is high in complexity and/or high in business value.
Skip code that is simple and stable or low-value.

Don’t Waste Time On…

• Getters/setters or trivial code
• Things you don’t control (like Swift’s standard library)

In short: test where bugs hide and where logic changes break behavior.
You’ll write fewer tests—but they’ll do more work.

The Real Problems You’ll Face in Bigger Apps

Let’s be honest: the app we tested here is very simple. – In real apps, testing gets a lot harder. And that’s probably why many teams skip it or give up after writing a few tests.

Why?

Because real code touches more than just arrays in memory. It saves to disk, talks to APIs, handles background tasks, shows alerts, and reacts to user actions. That’s where the pain starts.

Here are the real-world problems you’ll hit:

You Can Still Use Real Code in Tests

You don’t need to mock everything. Sometimes using the real system is the better choice—especially for things you control.

For example:
Saving items to disk?
Use FileManager.temporaryDirectory in your tests.
That way you catch real issues (permissions, file not found, codable, etc.)
And you don’t affect other tests—as long as you clean up.

What You Can Learn Next

Once you’re past basic unit tests, here are good next steps—each could be its own follow-up post:

1. Testing file saving using temporary files
   – Real file system, isolated and safeUsing Core Data in tests with an in-memory store
   – No need to mock your model layer

2. Testing async code (networking, debouncing)
   – Use XCTestExpectation or async/await

3. Testing SwiftUI view logic
   – Don’t test layout, but do test state and actions

4. What shared state is and how to avoid flaky tests
   – Deep dive into test isolation

Testing is easy when everything lives in memory.
It gets valuable—and tricky—when real-world stuff comes in.

Summary

In this post, you learned how to:

• Use XCTest to write unit tests for a SwiftUI ViewModel
• Structure your tests using the GIVEN / WHEN / THEN format
• Focus on business logic and state changes, not just code coverage
• Handle edge cases and verify behavior that matters to users
• Understand the basics of what to test, what not to test, and why testing gets harder in real apps

Don’t aim for perfect tests. – Aim for useful tests that protect you from regressions and crashes.

Most bugs live in the UI. Now that your ViewModel is covered, it’s time to test what users actually see and tap.
Up next: XCUITest: How to Write UI Tests for SwiftUI Apps

The post Introduction to XCTest: How to Write Unit Tests for iOS apps appeared first on swiftyplace.

Most iOS app bugs happen in the UI layer. Unit tests won’t catch them, and manual testing is slow and unreliable. That’s where UI tests come in.

In this post, you’ll learn how to:

• Write your first UI test for a SwiftUI app using XCUITest
• Use accessibility identifiers to reliably find and interact with views
• Assert that your app behaves correctly—just like a real user would

You’ll use a simple SwiftUI app as an example, but everything here also applies to UIKit apps. XCUITest works across both.

These are real iOS tests—they launch the full app in a simulator and simulate actual user interaction.

Let’s dive in.

Project files: https://github.com/gahntpo/iOS-testing

Setting Up UI Testing in Xcode

You can start with a new Xcode project, or use your existing one.

Option 1: Create a New Project with Tests Enabled

When creating a new iOS project, for the Testing System sections choose either Swift Testing or XCTest. Note that UI tests only work with XCTest.

This creates:

• A unit test target
• A UI test target

Option 2: Add a UI Test Target to an Existing Project

If you already have a working SwiftUI app (like the ItemApp from earlier), you can add a UI test target manually:

1. In Xcode, go to File > New > Target
2. Choose iOS > UI Testing Bundle
3. Name it something like ItemAppUITests
4. Make sure it targets the right app

Now you’ll see a new folder with a file like this:

final class ItemAppUITests: XCTestCase {
    func testExample() {
        // your test will go here
    }
}

Great—you’re ready to start testing.

SwiftUI App Under Test

This is a demo app, where you can see a list of items, add and delete them.

In a previous post, I used the same app example to write unit tests with swift testing. You can read about it here.

Adding Accessibility Identifiers

To make views accessible to your UI tests, you need to add accessibility identifiers to them. These are string tags that XCUITest uses to find buttons, text fields, and other UI elements.
In the example app, you can see SwiftUI views like so:

Button("Remove Last") {
    viewModel.deleteLastItem()
}
.buttonStyle(.borderedProminent)
.disabled(viewModel.deleteDisabled)

This works, but XCUITest can’t find this button unless you give it a name. So we add:

.accessibilityIdentifier("button.delete")

Repeat this for all important UI elements.

Recommended Naming: Unique and Clear

Use a consistent naming scheme:

<screen>.<type>.<purpose>

Why?

• It prevents conflicts between views (e.g. two buttons named "add")
• It makes it clear where the element lives
• It scales well as your app grows

Examples

Pro Tip: Use a Central enum to Store Them

Hardcoding strings across your app and test files is a recipe for broken tests.

Instead, define identifiers once in a shared file:

enum UIIdentifiers {
    enum AddNewItemScreen {
        static let addButton = "AddNewItemScreen.button.add"
        static let itemNameTextField = "AddNewItemScreen.textfield.newItem"
        static let confirmButton = "AddNewItemScreen.button.confirm"
    }

    enum ItemListScreen {
        static let itemListView = "ItemListScreen.view.itemList"
        static let deleteButton = "ItemListScreen.button.delete"
        static let addButton = "ItemListScreen.button.add"
        static func item(_ name: String) -> String {
            "ItemListScreen.item.(name)"
        }
    }
}

This makes your UI tests:

• Easier to write
• Easier to refactor
• Less likely to break from typo bugs

Make sure to add this file to both your main app and ui testing target, so you can access it for you tests.

Next, I’ll show you how to update your actual SwiftUI views to use these identifiers—and then we’ll write your first UI test.

Updating the SwiftUI Views with Accessibility Identifiers

Add identifiers to ContentView for the scrollview items, delete and add buttons:

import SwiftUI

struct ContentView: View {

    @ObservedObject var viewModel: ItemViewModel
    @State private var showingAddSheet = false

    var body: some View {
        VStack {
            ScrollView {
                ForEach(viewModel.items) { item in
                    Text(item.name)
                        .padding()
                        .frame(maxWidth: .infinity)
                        .background(Capsule().fill(Color.yellow))
                        .accessibilityIdentifier(UIIdentifiers.ItemListScreen.item(item.name))
                }
            }
            .accessibilityIdentifier(UIIdentifiers.ItemListScreen.itemListView)

            Divider()

            HStack {
                Button("Remove Last") {
                    viewModel.deleteLastItem()
                }
                .buttonStyle(.borderedProminent)
                .disabled(viewModel.deleteDisabled)
                .accessibilityIdentifier(UIIdentifiers.ItemListScreen.deleteButton)

                Button {
                    showingAddSheet = true
                } label: {
                    Label("Add Item", systemImage: "plus")
                }
                .buttonStyle(.bordered)
                .accessibilityIdentifier(UIIdentifiers.AddNewItemScreen.addButton)
                .sheet(isPresented: $showingAddSheet) {
                    NewItemView(viewModel: viewModel)
                }
            }
        }
        .padding()
    }
}

For NewItemView add identifiers to the textfield and button like so:

struct NewItemView: View {

    @ObservedObject var viewModel: ItemViewModel
    @State private var newItemName = ""
    @Environment(.dismiss) var dismiss

    var body: some View {
        VStack(spacing: 20) {
            TextField("Item name", text: $newItemName)
                .padding()
                .textFieldStyle(.roundedBorder)
                .accessibilityIdentifier(UIIdentifiers.AddNewItemScreen.itemNameTextField)

            Button("Add Item") {
                if !newItemName.isEmpty {
                    viewModel.addItem(name: newItemName)
                    newItemName = ""
                    dismiss()
                }
            }
            .buttonStyle(.borderedProminent)
            .disabled(newItemName.isEmpty)
            .accessibilityIdentifier(UIIdentifiers.AddNewItemScreen.confirmButton)
        }
        .padding()
    }
}

Now your app is testable: every important UI element is uniquely and clearly tagged. You’re ready to write your first UI test.

Writing Your First SwiftUI UI Test with XCUITest

We want to check:

• That the screen loads correctly
• That we can locate the container (e.g., scroll view or list) of items
• That the expected number of items is visible

This test checks the happy path—the UI is working as expected and showing 4 predefined items.

I will start by writing the test function where we test the shown items like so:

func test_items_shown() {
    let app = XCUIApplication()
    app.launch()
}

We create a new XCUIApplication and launch it. Every UI test starts from a clean app launch—no shared state, no leftovers from previous tests.

Run the Test

You can now run it:

• Click the diamond next to the test method
• In the Test Navigator on the left, click the diamond for the corresponding test
• Or press ⌘ + U to run all tests
• Use ⌘ + ⇧ + U to build all tests without running

Locating the UI Elements

You can ask the app instance for UI elements. For example, I can access views by their type and accessibility id. The following finds the scrollview by id:

func test_items_shown() {
    let app = XCUIApplication()
    app.launch()
    let collection = app.scrollViews["items.collection"]
}

But if you want to change your implementation in the future and change from a scroll view to e.g. a list, the test will fail. This would mean the test is brittle (breaks with future refactoring). A better more flexible approach is to look for elements that match the identifier like so:

let id = UIIdentifiers.ItemListScreen.itemListView
let collection = app.descendants(matching: .any)[id]

Using .descendants(matching: .any)[id] to find any type of view by identifier. It’s more stable against refactors.

Another problem with XCUITest is that they can be flaky that means they randomly fail. One reason may be that the UI is not refreshing fast enough and the UI elemente have not appeared yet when you check the assertions. To solve this and prevent flaky tests you can use .waitForExistence(timeout:). It makes the test more stable—it gives the UI a second to appear before failing.

func test_items_shown() {
    let app = XCUIApplication()
    app.launch()
    
    let id = UIIdentifiers.ItemListScreen.itemListView
    let collection = app.descendants(matching: .any)[id]
    XCTAssertTrue(collection.waitForExistence(timeout: 1), 
                 "The items should be visible")
}

Next I want to find the rows in the scrollview. I can use another search and define a predicate:

    let itemId = UIIdentifiers.ItemListScreen.item("")
    let predicate = NSPredicate(format: "identifier CONTAINS '\(itemId)'")
    let items = collection.descendants(matching: .any).matching(predicate)

Since each item has an identifier like "ItemListScreen.item.first" or "ItemListScreen.item.second", we use a predicate to match anything that starts with "ItemListScreen.item.". This way, the test doesn’t depend on the exact names, just the count.

Thus the full test looks like:

import XCTest

final class ItemAppUITests: XCTestCase {
    func test_items_shown() {
        let app = XCUIApplication()
        app.launch()

        let collection = app.descendants(matching: .any)[UIIdentifiers.ItemListScreen.itemListView]
        XCTAssertTrue(collection.waitForExistence(timeout: 1), 
                      "The items should be visible")

        let itemId = UIIdentifiers.ItemListScreen.item("")
        let predicate = NSPredicate(format: "identifier CONTAINS '(itemId)'")            
        let items = collection.descendants(matching: .any).matching(predicate)

        XCTAssertTrue(items.count > 0, 
                      "There should be at least one item on the screen")
    }
}

This is a good assertion because:

• It’s flexible to future refactoring: we don’t expect exactly x items which might change in the future
• It’s visible: if it fails, it tells you why
• It avoids testing layout or view types—just the behaviour

Attach a Screenshot (Bonus)

    let screenshot = app.screenshot()
    let attachment = XCTAttachment(screenshot: screenshot)
    attachment.lifetime = .keepAlways
    add(attachment)

Attaching a screenshot is helpful for debugging later—especially in CI or when a test fails unexpectedly.

Defaults to ~XCTAttachment.Lifetime.deleteOnSuccess~, indicating that the attachment should be discarded when its test passes successfully, to save on storage space. Set this property to ~XCTAttachment.Lifetime.keepAlways~ to persist an attachment even when its test passes.

To find the screenshots go to the Test Navigator and chose the test:

You can also see how long the test runs. In the above example, the test takes 5sec.

You can view the screenshot for later debugging. You can also export it. This can be useful if you want to automatically generate screenshots for app store connect.

Testing Adding New Items

In the next test I want to verify that:

1. The “Add” button opens the new item sheet
2. The user can enter a name
3. Tapping “Add Item” closes the sheet
4. The new item appears in the list

This is a full user interaction flow test. It checks that the UI is wired up correctly and behaves as expected end-to-end.

Here’s your working test:

import XCTest

final class ItemAppUITests: XCTestCase {

    func test_addItem_showsItemInList() {
        // --- GIVEN ---
        let app = XCUIApplication()
        app.launch()

        // --- WHEN ---
        app.buttons[UIIdentifiers.AddNewItemScreen.addButton].tap()

        let textField = app.textFields[UIIdentifiers.AddNewItemScreen.itemNameTextField]
        XCTAssertTrue(textField.waitForExistence(timeout: 1))
        textField.tap()
        textField.typeText("New Item")

        app.buttons[UIIdentifiers.AddNewItemScreen.confirmButton].tap()

        // --- THEN ---
        let newItem = app.staticTexts[UIIdentifiers.ItemListScreen.item("New Item")]
        XCTAssertTrue(newItem.waitForExistence(timeout: 2))
    }
}

What This Test Does

• XCUIApplication().launch() boots your app just like a user would
• It taps the Add button (using the identifier) to open the sheet
• In the sheet we locate the "New Item TextField"
• It enters "New Item" into the text field
• It confirms the addition by taping the "confirmButton"
• It asserts that the item now exists in the list

This is the most important part: verifying that the item actually appears on screen. Not just that the code ran—but that the user sees the result.
Using .waitForExistence(timeout:) here gives the UI a moment to update and avoids false negatives on slower devices or CI.

Test: Deleting All Items Disables the Delete Button

In this test, we’ll simulate repeatedly tapping the “Remove Last” button until no items remain. Then we’ll assert that:

• The Delete button removes items from the list one by one
• All items are eventually removed
• The “Remove Last” button becomes disabled when the list is empty
• This test verifies the entire “delete flow” and UI state update logic.

I will create a new test function like so:

func test_delete_button_removes_all_items_and_disables_button() {
    // --- GIVEN ---
    let app = XCUIApplication()
    app.launch()

    let deleteButton = app.buttons[UIIdentifiers.ItemListScreen.deleteButton]
    let collection = app.descendants(matching: .any)[UIIdentifiers.ItemListScreen.itemListView]

    XCTAssertTrue(collection.waitForExistence(timeout: 2), 
                  "Items should be visible")
    XCTAssertTrue(deleteButton.waitForExistence(timeout: 2), 
                   "Delete button should exist")
}

We locate both the button and the container (scroll view/list) and make sure they’re present before continuing. Always assert the UI is ready before interacting.

Next, I will count how many items are currently visibile:

    let predicate = NSPredicate(format: "identifier CONTAINS 'item.'")
    let itemElements = collection.descendants(matching: .any).matching(predicate)
    let initialCount = itemElements.count

    XCTAssertGreaterThan(initialCount, 0, "There should be items to delete")
    XCTAssertTrue(deleteButton.isEnabled, "Delete button should be enabled initially")

Instead of hardcoding the number of delete taps, we:

• Count how many items are currently in the list
• Verify that there’s at least one item
• Confirm the Delete button is enabled

Why this matters: This makes the test resilient—it still works if the initial item list changes.

Tap Delete Until All Items Are Gone

    // --- WHEN ---
    for _ in 0..<initialCount {
        deleteButton.tap()
    }

We dynamically tap the Delete button for every item that exists. This simulates how a user might clear out the list manually.

Then: Verify UI Is Updated

    // --- THEN ---
    XCTAssertTrue(collection.waitForExistence(timeout: 2), 
                      "Item List should be visible") 
    let remainingItems = collection.descendants(matching: .any).matching(predicate)
    XCTAssertEqual(remainingItems.count, 0, 
                  "All items should be removed from the screen")
    XCTAssertFalse(deleteButton.isEnabled, 
                   "Delete button should be disabled after all items are removed")

We assert that:

• No items remain in the UI
• The Delete button is now disabled, as expected

This checks that the ViewModel → View state binding works and that the UI reacts correctly.

Advanced: Controlling App Behavior in Tests

UI tests always launch your app from scratch—which means you can control how it launches.

For example, you can pass launch arguments or environment variables to:

• Load mock data
• Use a temporary file for test storage
• Clear UserDefaults or caches
• Inject staging URLs or fake config

This keeps your tests clean, repeatable, and isolated.

I’ll cover this in a follow-up post:
“How to Inject Data and Configuration into Your iOS App for UI Tests”

It includes examples using CommandLine.arguments, ProcessInfo.environment, and temp file paths.

Pros and Cons of UI Testing in iOS with XCUITest

UI tests let you automate real user flows—but they’re not magic. They work by launching the entire app from scratch in a simulator and interacting with the UI like a human would. This gives you full visibility into what users experience—but it also comes with downsides.

Pros: Why UI Tests Are Worth It

Cons: The Real Trade-offs

What i saw so far from the iOS developer community, the most common sentiment about XCUITest are that they are flaky and slow.

Probably the biggest downside to XCUITest is the test speed. The above 3 tests take together 27 seconds. They run one after the other in the simulator. You can imagine that this becomes quickly too slow to run frequently, if you want to use these test during Test-Driven-Develelpment TDD. The longer tests take the less likely you will be to actually run them. That is way most apps only add a few test flows, the most important long happy path.

In the following you can see the test results for both ui and unit tests:

The slowest UI test takes 12 sec vs the slowest unit test with 0.0023 sec. Because of this massive difference, most iOS devs will avoid UI tests and concentrate mostly on writing unit tests. You can have hundreds of unit tests runing <1sec that you run frequently during your development process withouth blocking you.

This is unfortunate since most bugs in iOS development are UI related. Avoiding UI testing makes this worse. There have been 3rd party libraries that try to give you fast unit tests for SwiftUI UI related code. You can have a look at these:

• ViewInspector
• Snapshot testing
• Preference testing

The XCTest team is aware of the missing test tool. I hope that in the not so far future we will see some much needed UI testing tools that fit in the developer workflow.

Summary

In this post, you learned how to:

• Set up XCUITest to write UI tests for a SwiftUI iOS app
• Use accessibility identifiers to reliably find UI elements
• Validate real user flows like adding and deleting items
• Understand the trade-offs of UI testing: high value, but slower and more fragile than unit tests

UI tests won’t replace your unit tests—but they fill a gap unit tests can’t: verifying that the app behaves correctly from the user’s point of view.

Project files: https://github.com/gahntpo/iOS-testing

The post XCUITest: How to Write UI Tests for SwiftUI Apps appeared first on swiftyplace.

We’ll walk through writing your first test using the new Swift Testing Framework (Swift 6+), which is a big improvement to XCTest.

Project files: https://github.com/gahntpo/iOS-testing

A unit test is an automated test that

• Verifies a single unit of behavior,
• Does it quickly,
• And in isolation from other tests.

Vladimir Khorikov, Unit Testing: Principles, Practices, and Patterns

Setting Up Unit Tests in Xcode

Creating a New Project With Tests

When starting a new project in Xcode:

• Select App template.
• Make sure you check “Include Tests” when configuring the project.
• This will add a test target automatically (e.g., YourAppTests).

Adding Tests to an Existing Project

If you already have a SwiftUI project:

1. Open File > New > Target…
2. Select “Unit Testing Bundle”
3. Choose your app under “Target to be tested”
4. In your new test files, add:

@testable import YourAppModule

The Code We’re Testing

Let’s start with a simple ItemViewModel that powers a SwiftUI view. It displays a list of items and removes the last one when a button is tapped.

struct Item: Identifiable {
    var name: String
    let id: UUID
    init(name: String, id: UUID = UUID()) {
        self.name = name
        self.id = id
    }

    static var examples: [Item] {
        [Item(name: "first"), Item(name: "second"), Item(name: "third")]
    }
}

final class ItemViewModel: ObservableObject {
    @Published var items: [Item] = Item.examples
    @Published var deleteDisabled = false

    func removeLast() {
        guard items.isEmpty == false else { return }
        items.removeLast()
        deleteDisabled = items.isEmpty
    }
}

The main content view shows the items and a button to delete the last item:

struct ContentView: View {
    
    @ObservedObject var viewModel: ItemViewModel
    
    var body: some View {
        VStack {
            ScrollView {
                ForEach(viewModel.items) { item in
                    Text(item.name)
                        .padding()
                        .frame(maxWidth: .infinity)
                        .background(Capsule().fill(Color.yellow))
                }
            }
            
            Button("Remove Last") {
               viewModel.deleteLastItem()
            }
            .buttonStyle(.borderedProminent)
            .disabled(viewModel.deleteDisabled)
        }
    }
}

Writing Unit Tests Using Swift Testing

Swift 6 introduced a new way to write tests—no need for XCTestCase or inheritance. Here’s what a clean Swift Testing setup looks like:

import Testing
@testable import ItemApp

struct ItemViewModelTests {

    @Test func items_when_remove_button_then_items_count_lowered() {
        let vm = ItemViewModel()
        
        vm.removeLast()

        #expect(vm.items.count == 2)
    }
}

Add the @Test marco in front of the test function, otherwise you Xcode will not recognize it as a test function.

 Running Your Tests in Xcode

You can run tests by any of the following methodes:

• Press ⌘ + U to run all tests.
• Use the Test Navigator (⌘ + 6) to see individual test results.
• run one test by pressing on the diamond next to the @Test macro

Failed tests will be shown with a red icon and passed tests will show with a green checkmark:

Testing Best practices

Writing tests is easy but writing tests that will help you catch and fix bugs in the future is hard. Here is an example of a test that is readable and clearly structured with a good assertion:

    @Test("Remove Button lowers item count")
    func items_when_remove_button_then_items_count_lowered() {
        // --- GIVEN ---
        let vm = ItemViewModel()
        let itemCount = vm.items.count
        let expectedItemCount = itemCount - 1
        #expect(vm.items.count > 0) // precondition
        
        // --- WHEN ---
        vm.deleteLastItem()
        
        // --- THEN ---
        #expect(vm.items.count == expectedItemCount,
                "Expected that the array has \(expectedItemCount) items")
    }

Tests follow Given–When–Then or  Arrange-Act-Assert structure.

The When section should only have one line of code (clearly indicate what behavior you are testing). Otherwise you might consider refactoring your code to encapsulate the multiline code into one single call.

Name Tests in Plain English

Avoid tying test names to implementation details that might change. Prefer:

func items_when_remove_button_then_items_count_lowered() 

over

func itemViewModel_removeLast_success()

– if you rename removeLast(), the first stays meaningful, the second forces you to update tests too.

Make Tests Resilient while Refactoring

Rather than asserting a hard-coded expected value (e.g. 2):

#expect(vm.items.count == 2)

Instead derive it .Now if you change initial items (or add a new default), your test still passes without rewriting “2” everywhere.

let itemCount = vm.items.count
let expectedItemCount = itemCount - 1

#expect(vm.items.count == expectedItemCount)

I cannot stress enough how frustrating failed tests are that give you false alarms that means they fail but your app is working as expected. They are demotivating and will take addtional time away from you. Please try to write tests that are flexible enough in future refactorings.

You want to write tests that give me a clear failure notification. Spend a significant amount of your time finding good assertions. What is the expected behavior. In above example, I am not expecting that the item count i always a fixed number 2. I would expect that the itme count is lowered by 1.

Testing Edge Cases: Guard Clauses

Our removeLastItem() returns early when the items array is early:

func deleteLastItem() {
   guard items.isEmpty == false else { return }
   items.removeLast()
    deleteDisabled = items.isEmpty
}

Test this edge case too:

@Test func no_items_when_remove_button_then_nothing_happens() async throws {
        // --- GIVEN ---
       let vm = ItemViewModel()
        vm.items = []
        
        // --- WHEN ---
        vm.deleteLastItem()
        
        // --- THEN ---
        #expect(vm.items.isEmpty)
}

This ensures your guard clause actually protects you, not just the happy path.

What to Test (and What Not)

Aim your tests at code that’s either:

1. Complex (lots of branches, business logic)
2. Business-critical (payment flows, data integrity)

Skip trivial models or boilerplate that you’ll rewrite constantly. If changing an initializer or model property breaks dozens of superficial tests, you’ll lose confidence fast and stop writing tests.

How to Test the UI in SwiftUI Apps

Unit tests are fast—but they don’t interact with the UI. XCUITests fill that gap for end-to-end flows (button taps, navigation), but they’re slow. Only automate the most important user journeys—don’t record a dozen tiny UI tests that take minutes to run every build. You can read more about the different types of tests in ios development in this blog post.

Project files: https://github.com/gahntpo/iOS-testing

An alternative to XCUITest are unit tests for SwiftUI interfaces. You can use snapshot tests, ViewInspector or preference testing. These are much faster and reliable then XCUITests.

Key Takeaways

• Start small: test one function at a time (AAA/Given-When-Then).
• Name clearly in plain English to survive refactors.
• Derive expected values instead of hard-coding.
• Cover edge cases: guard clauses, empty data.
• Prioritize complexity and business significance over boilerplate.
• Error messages: write clear failure messages so you know what you meant months later.
• Write good assertions: focus on behavior, avoid brittle checks (e.g. fixed numbers).
• Don’t write bad tests: if a test isn’t valuable or maintainable, it’s better left unwritten.

With just a handful of focused, resilient tests, you’ll catch regressions instantly, code with confidence, and spend far less time repeating manual QA. Your future self (and your users) will thank you.

The post Getting Started with Unit Testing for iOS Development appeared first on swiftyplace.

One afternoon I was experimenting with EnvironmentKeys—trying to drive navigation and coordinate between screens without resorting to imperative hacks. SwiftUI’s environment feels like a top‑down broadcast: you inject a value at the root, and child views pick it up. But what if you want the opposite? What if a child view could whisper something back up the tree?

Enter PreferenceKeys—SwiftUI’s built‑in “bottom‑up” communication channel. I stumbled on them via the standard navigation‑title machinery (SwiftUI uses a preference under the hood to let child views set their own title). In that moment I thought:
“If SwiftUI itself can bubble up its internal state this way… why can’t I?”

So I attached a tiny custom preference to a view, let it bubble up, and then read it off in my hosting code. Suddenly I could observe exactly which views were on‑screen, what their internal state was, and react—without touching the view’s implementation.

This lead to a new testing framework that I published on Github: SwiftLens

From EnvironmentKeys to PreferenceKeys

EnvironmentKeys are SwiftUI’s way of injecting values from parent to children:

extension EnvironmentValues {
    @Entry var themeColor: Color = .pink
}

The default color is pink, but you can pass a different color to childviews like:

VStack {
    Text("This is another view")
    
    CustomView(text: "This lives in another environment")
      .environment(\.themeColor, Color.blue)
}

All views inside the VStack get the new blue them color and use it like so:

struct CustomView: View {
    @Environment(.themeColor) var themeColor
    let text: String
    var body: some View {
        Text(text)
            .foregroundStyle(themeColor)
    }
}

As you can see the environment passes keys down the view hierarchy. It is a top-down approach.

PreferenceKeys are the mirror image: children push values up, and parents collect them.

For example, I could pass up the view hierachy the accessibility identifiers of the screens:

struct LensCaptureKey: PreferenceKey {
    static var defaultValue: [String] = []
    static func reduce(value: inout [String], nextValue: () -> [String]) {
        value.append(contentsOf: nextValue())
    }
}

and set them on the views like so:

struct DetailView: View {
    let item: Int
    var body: some View {
        VStack {
           ...
        }
        .padding()
        .navigationTitle("Detail for (item)")
        .preference(key: LensCaptureKey.self, 
                    value: ["screen.detailview.\(item)"])
    }
}

You can think of this as any view can “tag” itself with an identifier and some metadata—and SwiftUI will deliver all of those tags to an ancestor via onPreferenceChange.

You can then catch them at a higher level in the view hierarchy with the onPreferenceChange modifier:

struct ContentView: View {
    var body: some View {
        NavigationStack {
            RootView()
                .navigationTitle("Root")
                .navigationDestination(for: Int.self) { item in
                    DetailView(item: item)
                }
        }
        .onPreferenceChange(LensCaptureKey.self) { keys in
            print(keys)
        }
    }
}

When navigating inside the navigation stack, you will see the updated print statements:
Initially when you at the rootview -> [“screen.rootview”]
navigating to item 0 -> [“screen.rootview”, “screen.detailview.0”]
continue navigating to item 11 -> [“screen.rootview”, “screen.detailview.0”, “screen.detailview.11”]
pressing back button -> [“screen.rootview”, “screen.detailview.0”]
pressing back button -> [“screen.rootview”]

Because each view calls .preferencKey(“…”), SwiftUI automatically collects them via your LensCaptureKey and invokes the parent’s onPreferenceChange. You get real‑time feedback on exactly which screens are active—no hacks, no introspection, no brittle accessibility selectors.

Bottom‑up: PreferenceKeys bubble from children up to parents

How SwiftUI Uses PreferenceKeys Under the Hood

Before I repurposed them for testing, I saw PreferenceKeys in action powering:

• Navigation titles
• Toolbar items
• List section headers

⠀…all of which child views “declare,” and the system hoists up to configure the navigation bar or toolbar. It felt like discovering a secret API invitation from Apple.
I also want to stress this in case you wonder if I am using some magic hack here, which I don´t, it´s a SwiftUI native API that has been around since iOS 13 and never changed. I am simply using PreferenceKeys in a creative way .

Next up, we’ll see how to wire this same mechanism into a test suite (using async/await and a simple observer) so your UI tests can wait for exactly the right views to appear or disappear—with zero flakiness.

Minimal Testing Setup

Before we dive into programmatic navigation, let’s get our feet wet with the absolute bare minimum to test a PreferenceKey tag. I will use unit tests to run these tests, which will make them super fast.
Here’s what we need:

import Testing
@testable import TestingWithPreferencesProject

struct TestingWithPreferencesProjectTests {

    @MainActor
    func rootScreenPreference_is_Captured() throws {
        //–– 1. Create the observer

        //–– 2. Wrap ContentView in an onPreferenceChange
        let sut = ContentView()
            .onPreferenceChange(LensCaptureKey.self) { preference in
                // pass the preferences to the observer
            }

        //–– 3. Host it in a window inside UIHostingController

        //–– 4. wait for SwiftUI render

        //–– 5. Assert that "screen.rootview" was emitted
    }
}

Step‑by‑Step

Lets define a simple observer where we’ll store any tags we see in an array. This file lives in the test suite.

import Foundation

final class LensObserver {
   @Published var lensCaptures: [String] = []
}

and use it in the test function and write the assertion against the observer values:

    @MainActor
    func rootScreenPreference_is_Captured() throws {
        //–– 1. Create the observer
        let observer = LensObserver()

        //–– 2. Wrap ContentView in an onPreferenceChange
        let testView = ContentView()
            .onPreferenceChange(LensCaptureKey.self) {
                observer.lensCaptures = $0
            }

        //–– 3. Host it in a window inside UIHostingController

        //–– 4. wait for SwiftUI render
        RunLoop.main.run(until: Date().addingTimeInterval(0.1))

        //–– 5. Assert that "screen.rootview" was emitted
        #expect(observer.lensCaptures.contains("screen.rootview"))
    }