So what is a view model, really? In this post, I want to give you a clear, practical definition that you can apply to your own code. Here’s the main rule that I find most practical, so you have something to hold on to:

A view model owns UI state and is responsible for mutating that state properly and consistently.

Notice what’s not in that sentence: a single view. A view model isn’t tied to one view. It can support one view, an entire screen, or several views that share the same state. (Other people might say otherwise, but I am giving you the system that works best for me)

That responsibility is the whole point. In SwiftUI, state drives the UI. When something on screen is wrong, the cause is almost always state that’s wrong. And state goes wrong because the code that mutates it is messy: scattered across views, duplicated in slightly different versions, or running steps in the wrong order. A view model gives those mutations one home, so they happen the same way every time.

That’s it. Everything else in this post explains what that means, why it’s useful, and where the boundaries are.

Where MVVM Comes From

MVVM stands for Model-View-ViewModel. It was introduced in 2005 by Microsoft architects Ken Cooper and Ted Peters. I don’t usually spend much time on history, but here it matters because understanding where the pattern came from helps us understand what it’s actually trying to do.

MVVM was born in Windows Presentation Foundation, or WPF. The UI in WPF is written in XAML, a declarative markup language, and it relies heavily on data bindings and reactive updates. In other words, it’s state-driven, declarative programming. Sound familiar? That’s very close to how SwiftUI works.

So what problem was MVVM designed to solve? It came down to people. In WPF, teams naturally split into two groups: UI-facing developers, who Microsoft called “designer developers,” and logic developers working behind the scenes. The challenge was letting these two groups work in parallel without stepping on each other’s toes.

What kept happening was that logic crept into the view: network requests, formatting, data transformations. The view code became cluttered and hard to maintain, and when everyone has to work in the same file, collaboration breaks down fast.

The solution was to pull that complex logic out of the view and into a separate layer. The view was left with nothing but declarative UI, and the logic developers had their own layer to work in. That separate layer is the view model.

The Backing Layer: A Presentation Layer Pattern

The best way to think about a view model is as the backing layer behind your UI. You have the view on one side and your data on the other, and you place an intermediate layer in between. That layer handles the more complex concerns: state management, formatting, anything you don’t want cluttering your view code.

I like to compare it to an old-school calculator. On the front, you see the buttons and the display. That’s your view. Now imagine you unscrew the case and look inside: the battery, the circuit board, some cables. That’s your backing layer. As a user, you just want to press buttons and get results. You don’t want to see or deal with the internals. A view model works the same way: it keeps the inner workings hidden behind a clean surface.

That’s why I often prefer the term UI backing layer over “view model.” It describes what the thing actually does.

This also leads to an important clarification. Because we’re talking about layers, you’ll sometimes hear MVVM described as a “UI architecture pattern.” That can be misleading, because it gives the impression that MVVM is a full app architecture. It’s not. MVVM is a presentation layer pattern. It’s about the view and the code that directly backs it.

• It’s not about visual design, like layout, colors, or components.
• It doesn’t tell you how to structure your whole app. Networking, persistence, navigation, and dependencies need their own layers and patterns.
• At its core, it’s about separation of concerns within the UI layer.

The Three Layers

Let’s look at each part of the pattern and what it’s responsible for.

The View

The view is the UI layer. In SwiftUI, these are your View structs, and their job is to take state and decide what to display. Logged in? Show the main content. Logged out? Show the login screen.

Views also handle the finer details of presentation. Is a button enabled or disabled? What text goes into a label? What font, what position, what layout? These are all view concerns. The view is the part that makes things look good.

Views also receive user interactions. When someone taps a button, the view picks that up. Sometimes it handles the interaction directly, but more often it passes the user’s intent along to the view model. The view just says “the user tapped this” and moves on.

The View Model

The view model is the UI backing layer. Because SwiftUI is state-driven, everything revolves around UI state, and managing that state can get complex. When do you change it? What moves you from loading to success, or to an error? What happens when a network request comes back? All of this needs to live somewhere, and that somewhere is the view model.

The view model owns the UI state and decides when and how it changes. It can also prepare data for display, like formatting a price, and act as a gatekeeper for what’s allowed to happen.

The Model

The model is your data: the structures your app works with, and the logic that naturally belongs to that data, like validation rules.

You’ll find that different developers mean different things by “model.” Some put their networking code here too. That’s a valid interpretation, but to keep things clear, I keep the model narrow: the data itself, plus the logic intrinsic to it.

What Defines a View Model: UI State + Mutations

You can characterize any view model by two things: what state it holds, and how it can change that state. That’s really all that defines it.

• UI state: the data your views need to render. The items in a list, whether something is loading, an error message, which item is selected, whether a button is allowed to be tapped.
• Methods to change UI state: controlled mutations of that data. Adding an item, logging in, deleting a theme.

Because the view model backs the UI, its state has to be connected to the views that display it. That comes with two technical requirements:

• @Observable: SwiftUI needs to track the state so it can update the views whenever it changes. Without observation, the view has no way of knowing that something happened.
• @MainActor: the UI reads this state, and UI work happens on the main actor. So the state, and the code that changes it, lives there too.

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []   // UI state

    func addItem(id: String) { /* ... */ }    // mutation
    func removeItem(id: String) { /* ... */ } // mutation
}

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []   // UI state

    func addItem(id: String) { /* ... */ }    // mutation
    func removeItem(id: String) { /* ... */ } // mutation
}

There’s one more rule I find really helpful: a view model communicates through state, never through UI instructions. Say a user isn’t allowed to buy a certain product. The view model doesn’t say “disable the button.” It says “this action is not allowed.” The view is the one that translates that into a disabled button.

In the same way, a view model can prepare data for display, like turning a raw price into a formatted string. But it never decides how that information is rendered. It knows what to show, never how to show it. That’s view territory.

Why Put State and Mutations Together?

I like to use the law of proximity here: things that change together should live together.

You can look at UI state from two directions. When the state changes, the UI changes, so the state should live close to the views that use it. That’s true. But the state and the code that changes it belong together just as tightly.

Think about a SwiftUI view hierarchy where several views use the same state, and each of those subviews can mutate it. The state declaration moves higher up the view tree, but the code that changes it is scattered across different subviews. Things get messy quickly. If you want to know where a value was changed, you have to go hunting through the hierarchy.

A view model brings them back together. The state lives in one place, and the methods that change it live right next to it. You get a single source of truth for the state, and one place that’s responsible for changing it properly and consistently.

That gives you a few concrete benefits:

• Consistent mutations: every change goes through the same methods, so it happens the same way every time.
• No duplicated logic: if several views need to make the same change, they call the same method. Duplicated logic tends to drift. Sooner or later you update one copy and forget the other, and your state goes out of sync.
• Easier to follow: when you want to know how the state changes, you look in one place.

Example: The Shopping Cart

Let’s see how these layers play out with a shopping cart.

The Model

The model is the raw data: a cart item with a product ID and a quantity, and the product information itself.

struct CartItem {
    let id: String
    var quantity: Int
}

struct Product {
    let id: String
    let name: String
    let price: Double
}

struct CartItem {
    let id: String
    var quantity: Int
}

struct Product {
    let id: String
    let name: String
    let price: Double
}

This isn’t what the UI wants to show, though. The view needs a name, a quantity, and nicely formatted prices, all in one place. So we add a display type that has exactly what the view needs:

struct CartDisplayItem {
    let id: String
    let name: String
    let quantity: Int
    let formattedPrice: String
    let formattedSubtotal: String
}

struct CartDisplayItem {
    let id: String
    let name: String
    let quantity: Int
    let formattedPrice: String
    let formattedSubtotal: String
}

The View Model

The view model owns the state of what’s in the cart. It turns the raw data into display items, calculates the total, and acts as a gatekeeper: if the view wants to change the cart, it has to call addItem or removeItem. It can’t reach in and change the items directly, which is what private(set) makes sure of.

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []
    private let products: [String: Product]

    init(products: [String: Product]) {
        self.products = products
    }

    // Converts model data into what the view displays
    var displayItems: [CartDisplayItem] {
        items.compactMap { item in
            guard let product = products[item.id] else { return nil }
            let subtotal = product.price * Double(item.quantity)
            return CartDisplayItem(
                id: item.id,
                name: product.name,
                quantity: item.quantity,
                formattedPrice: formatPrice(product.price),
                formattedSubtotal: formatPrice(subtotal)
            )
        }
    }

    var formattedTotal: String {
        let total = items.reduce(0.0) { sum, item in
            guard let product = products[item.id] else { return sum }
            return sum + product.price * Double(item.quantity)
        }
        return formatPrice(total)
    }

    // Gatekeeper: the view tells us what it wants, we decide if it's allowed
    func canAddItem(id: String) -> Bool {
        true // e.g. check stock or purchase limits
    }

    func addItem(id: String) {
        if let index = items.firstIndex(where: { $0.id == id }) {
            items[index].quantity += 1
        } else {
            items.append(CartItem(id: id, quantity: 1))
        }
    }

    func removeItem(id: String) {
        items.removeAll { $0.id == id }
    }

    private func formatPrice(_ price: Double) -> String {
        price.formatted(.currency(code: "USD"))
    }
}

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []
    private let products: [String: Product]

    init(products: [String: Product]) {
        self.products = products
    }

    // Converts model data into what the view displays
    var displayItems: [CartDisplayItem] {
        items.compactMap { item in
            guard let product = products[item.id] else { return nil }
            let subtotal = product.price * Double(item.quantity)
            return CartDisplayItem(
                id: item.id,
                name: product.name,
                quantity: item.quantity,
                formattedPrice: formatPrice(product.price),
                formattedSubtotal: formatPrice(subtotal)
            )
        }
    }

    var formattedTotal: String {
        let total = items.reduce(0.0) { sum, item in
            guard let product = products[item.id] else { return sum }
            return sum + product.price * Double(item.quantity)
        }
        return formatPrice(total)
    }

    // Gatekeeper: the view tells us what it wants, we decide if it's allowed
    func canAddItem(id: String) -> Bool {
        true // e.g. check stock or purchase limits
    }

    func addItem(id: String) {
        if let index = items.firstIndex(where: { $0.id == id }) {
            items[index].quantity += 1
        } else {
            items.append(CartItem(id: id, quantity: 1))
        }
    }

    func removeItem(id: String) {
        items.removeAll { $0.id == id }
    }

    private func formatPrice(_ price: Double) -> String {
        price.formatted(.currency(code: "USD"))
    }
}

The View

With all that logic in the view model, the view becomes very simple. No formatting, no calculations. Just a ForEach with some Text views, a font, and a disabled modifier.

struct CartView: View {
     var viewModel: CartViewModel

    var body: some View {
        VStack {
            ForEach(viewModel.displayItems, id: .id) { item in
                HStack {
                    Text(item.name)
                    Text("×(item.quantity)")
                    Spacer()
                    Text(item.formattedSubtotal)
                }
            }

            Text("Total: (viewModel.formattedTotal)")
                .font(.headline)

            Button("Add iPhone") {
                viewModel.addItem(id: "iphone")
            }
            .disabled(!viewModel.canAddItem(id: "iphone"))
        }
    }
}

struct CartView: View {
     var viewModel: CartViewModel

    var body: some View {
        VStack {
            ForEach(viewModel.displayItems, id: .id) { item in
                HStack {
                    Text(item.name)
                    Text("×(item.quantity)")
                    Spacer()
                    Text(item.formattedSubtotal)
                }
            }

            Text("Total: (viewModel.formattedTotal)")
                .font(.headline)

            Button("Add iPhone") {
                viewModel.addItem(id: "iphone")
            }
            .disabled(!viewModel.canAddItem(id: "iphone"))
        }
    }
}

Notice how canAddItem works. The view model only answers “is this allowed?” The view decides that “not allowed” means a disabled button.

Now imagine all of this living inside the view: the price formatting, the subtotal and total calculations, the rules for adding and removing items. The view would get big and messy fast, and every other view that touches the cart would need its own copy of that logic.

“One View Model per Screen”: A Rule That Trips You Up

You’ll often hear that MVVM comes with a rule: one view model per screen, or even one per view. I understand why people like it. It’s simple, it’s easy to explain, and every screen gets its own neat little backing class.

But I think it’s a rule that breaks your app sooner or later, because it goes directly against the single source of truth.

Think about the shopping cart. The cart screen shows the items. But the product list also needs the cart: the user adds items from there, and maybe the tab bar shows a badge with the number of items. If every screen gets its own view model, you now have two view models holding their own copy of the cart. Add an item on the product list, and the cart screen doesn’t know about it. So you start syncing them: notifications, callbacks, reloading on appear. That’s exactly the messy state we wanted to avoid. You also end up writing the same addItem logic twice, and those two versions will drift apart.

There’s a second problem: lifetime. A view model created by a screen lives only as long as that screen. Navigate away and back, and the state is gone and has to be loaded again, even if it should have survived.

The issue is that the rule scopes view models by screens. But screens are a UI concern. What a view model actually manages is state, so that’s what should decide its scope.

A Practical Approach: Scope by State, Not by Screen

Here are the guidelines I use instead:

1. Start from the state, not the screen. Ask: what state is this, and which views need it?
2. Every piece of UI state has exactly one owner. One view model owns the cart. Not one per screen that shows the cart.
3. Place the owner where the state needs to live. High enough in the view tree that every view that needs the state can reach it, and long-lived enough that the state survives as long as it should. If only one screen needs it, keep it there.
4. Share the instance, don’t copy the state. Views that need the same state get the same view model passed in, and they all call the same methods to change it.

In the example above, CartView is short lived because its inside a sheet. It gets the ViewModel passed in from its parent. The product list needs it too. The ownership moves up: the app owns one CartViewModel and hands it to every view that needs it:

struct ContentView: View {
    @State private var cartViewModel = CartViewModel()
    @State private var cartIsShown = false
    
    var body: some View {
        ProductListView(cartViewModel, cartViewModel)
           .sheet(isShown: cartIsShown) {
               CartView(cartViewModel: cartViewModel)
            }
    }
}

struct ContentView: View {
    @State private var cartViewModel = CartViewModel()
    @State private var cartIsShown = false
    
    var body: some View {
        ProductListView(cartViewModel, cartViewModel)
           .sheet(isShown: cartIsShown) {
               CartView(cartViewModel: cartViewModel)
            }
    }
}

The product list adds an item, the badge updates, and the cart screen shows it, because they’re all looking at the same state, changed through the same methods.

Notice that “one view model per screen” can still happen with this approach. If some state really belongs to only one screen, its view model naturally ends up there. The difference is that it’s a result of where the state belongs, not a rule you apply up front.

Drawing the Line: UI State vs. Background Work

In the cart example, everything happened locally. In a real app, adding an item to a cart probably means asking a server whether the item is still available. So where does that network code go? Into the view model?

This is where one question helps you decide which layer code belongs to: does it own UI state?

• Yes → it’s a view model (or a store, whatever you want to call it). It’s @Observable, it runs on @MainActor, and views are connected to it.
• No → it belongs in a supporting layer behind the view model, like a service. It’s not observable, it’s not on the main actor, and it’s free to do its work in the background, for example with @concurrent functions.

This isn’t just a naming preference. It’s the reason I draw the line exactly here. Anything the UI needs to observe has to be observable and has to live on the main actor, because that’s where SwiftUI reads it. Anything that doesn’t touch UI state shouldn’t be there. Networking, decoding JSON, reading and writing files: that’s heavy work, and we want it off the main actor so the UI stays responsive.

The user taps a button. The view passes that intent to the view model. The view model asks the service to do the work in the background. The data comes back, the view model updates its UI state on the main actor, and SwiftUI updates the view.

In code, the service is a small helper with no state of its own:

nonisolated struct CartService {
    @concurrent
    func addItem(id: String) async throws -> [CartItem] {
        // Send the request, decode the response,
        // and return the cart as the server sees it
    }
}

nonisolated struct CartService {
    @concurrent
    func addItem(id: String) async throws -> [CartItem] {
        // Send the request, decode the response,
        // and return the cart as the server sees it
    }
}

And the view model uses it, but stays in charge of the state:

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []
    private(set) var errorMessage: String?
    private let service = CartService()

    func addItem(id: String) async {
        do {
            items = try await service.addItem(id: id)
        } catch {
            errorMessage = "Couldn't add the item. Please try again."
        }
    }
}

@MainActor
@Observable
final class CartViewModel {
    private(set) var items: [CartItem] = []
    private(set) var errorMessage: String?
    private let service = CartService()

    func addItem(id: String) async {
        do {
            items = try await service.addItem(id: id)
        } catch {
            errorMessage = "Couldn't add the item. Please try again."
        }
    }
}

The service doesn’t know anything about the UI. The view model doesn’t know how the network request works. Each one has a clear job, and the boundary between them is exactly the boundary between the main actor and the background. This is good use of Separation of Concern principle (SoC).

This also explains why naming matters. If something owns UI state, call it a view model or a store, even if someone labeled it a “service.” I see this a lot in code on GitHub and in blog posts: a “service” that holds UI state in a project that supposedly has no view models. It’s basically one, and the wrong name hides which code runs where and what the UI connects to.

There’s more to say about this supporting layer, including the difference between services and repositories. I’ll cover that in a separate post.

A View Model Is Not “All Business Logic”

You’ll often read that the view model is where your “business logic” goes. The problem is that “business logic” is a bag of everything. It doesn’t actually help you decide where a piece of code belongs.

If you split it up, it becomes much clearer. Some business logic is about state: deciding what the UI should show and formatting data so it’s easy to display. That belongs in the view model. But a lot of business logic is about data access: network requests, file I/O, encoding and decoding. That belongs behind the view model, in the supporting layer.

So instead of “the view model holds the business logic,” I’d put it this way: the view model holds the UI state and the logic that changes it. Everything else gets offloaded. This can lead to the dreaded “God” View Model, another mess we want to avoid.

A Tool, Not a Rule

MVVM doesn’t mean you have to use a view model for every single view. In one of the original blog posts, Cooper and Peters made a point of saying they didn’t see it as a purist thing you apply everywhere. They saw it as a pattern that comes up naturally during development, something you reach for when the situation calls for it.

You always have the choice to keep all your code in the view. It’s your codebase. But when your views start piling up logic and state mutations, a view model is a very good tool to have.

This brings us back to the argument that “the view is already the view model.” If you compare SwiftUI with WPF, where MVVM started, there are a lot of similarities: declarative UI, data bindings, reactive updates. And the goals are the same: keep your code organized, keep your views simple, and have clear rules for separating code into layers.

So the argument is a bit strange when you think about it. Nobody ever said you need a view model. The real question is when one helps you, and in which situations.

Wrapping Up

Let’s bring it all together. A view model is a UI backing layer, and it’s defined by two things:

• A single source of truth for UI state: the data your views need to render.
• A single source of state mutations: the methods responsible for changing that state properly and consistently.

Because it backs the UI, it’s @Observable and runs on @MainActor. Anything that doesn’t own UI state, like networking or file access, belongs in a supporting layer behind it, where it can do its work in the background.

But a view model is also an extra layer, and every layer has a cost. In the next post, When to Use a View Model (and When It’s Overkill), we’ll look at concrete examples of when that cost is worth paying, and when a view-only solution is the better choice.

The post What Is a View Model in SwiftUI MVVM, Really appeared first on swiftyplace.

Swift concurrency added a new problem on top of that, and it’s painful. As soon as you add networking, caching, or authentication, the compiler starts complaining. Sendable errors, main actor isolation errors, data race warnings. You add @MainActor somewhere, and a new error shows up somewhere else. At some point you start wondering: does Swift concurrency even work with SwiftUI? And if it does, how are you supposed to structure your app so it fits?

It does work. In this post, I’ll show you how I structure my SwiftUI apps so that they stay organized and maintainable, and so that SwiftUI and Swift concurrency work together instead of against each other.

Concurrency Is Part of Your Architecture

Swift concurrency is built into the type system. Isolation is part of a type, just like its properties and functions. That means every time you decide what goes into a type, you’re also making a concurrency decision, whether you realize it or not.

What decides the isolation a type needs is the state it holds. So when I separate my code into components, I look at their state. There are three kinds I care about: UI state, non-UI state, and no state at all. Each one leads to a different kind of component.

My View Model is for UI State, and Methods to change UI State

UI state is anything your views read to render themselves: the list of products, a loading flag, an error message. Apple gave us @Observable for exactly this. It tracks which properties a view reads and updates the view when they change.

Because SwiftUI renders on the main actor, that state belongs on the main actor too:

@MainActor
@Observable
final class ProductListViewModel {
    var products: [Product] = []
    var isLoading = false
    var errorMessage: String?

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func loadProducts() async {
        isLoading = true
        defer { isLoading = false }

        do {
            products = try await service.fetchProducts()
        } catch {
            errorMessage = "Could not load products."
        }
    }
}

@MainActor
@Observable
final class ProductListViewModel {
    var products: [Product] = []
    var isLoading = false
    var errorMessage: String?

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func loadProducts() async {
        isLoading = true
        defer { isLoading = false }

        do {
            products = try await service.fetchProducts()
        } catch {
            errorMessage = "Could not load products."
        }
    }
}

Thinking about the view model this way made me rethink what I put into it. My view models used to collect everything: caches, tokens, helper state, anything that didn’t fit elsewhere. Now I follow a simple rule: the view model owns and mutates UI state. Functions that are called fromt the UI e.g. button press, call the view model methods that are @MainActor.

That keeps my view models small, and focused on a clear Separation of Concern.

My Services Are Stateless

A service fetches data, decodes it, maybe transforms it, and returns it. It doesn’t need to remember anything. And when a type has no state, there’s nothing to protect from data races.

That makes services the easiest layer to get right. A service is just a struct:

nonisolated struct RemoteProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [Product] {
        let url = URL(string: "https://api.example.com/products")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Product].self, from: data)
    }
}

nonisolated struct RemoteProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [Product] {
        let url = URL(string: "https://api.example.com/products")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Product].self, from: data)
    }
}

It’s nonisolated because it doesn’t belong to any actor. This allows me to move it across actors. For the heavy work, like decoding a large response, I mark the function with @concurrent so it runs in the background instead of blocking the main actor.

The view model calls it with await, the work happens off the main actor, and the result comes back to the view model, which assigns it to its UI state. One clear crossing point, and the compiler checks it for me.

Heavy Work Inside a View Model

Sometimes part of a view model function does heavy work. Filtering and sorting a large list, for example, or processing an image. The view model is on the main actor, so that work would block the UI.

In that case, I pull the heavy part out into its own function and mark it @concurrent:

@MainActor
@Observable
final class ProductListViewModel {
    var allProducts: [Product] = []
    var filteredProducts: [Product] = []

    func search(for query: String) async {
        filteredProducts = await filter(allProducts, matching: query)
    }

    @concurrent
    private func filter(_ products: [Product], matching query: String) async -> [Product] {
        products
            .filter { $0.name.localizedCaseInsensitiveContains(query) }
            .sorted { $0.name < $1.name }
    }
}

@MainActor
@Observable
final class ProductListViewModel {
    var allProducts: [Product] = []
    var filteredProducts: [Product] = []

    func search(for query: String) async {
        filteredProducts = await filter(allProducts, matching: query)
    }

    @concurrent
    private func filter(_ products: [Product], matching query: String) async -> [Product] {
        products
            .filter { $0.name.localizedCaseInsensitiveContains(query) }
            .sorted { $0.name < $1.name }
    }
}

The @concurrent function runs in the background, so it can’t touch the view model’s state directly. Everything it needs comes in as parameters, and the result goes back as a return value. The main actor function passes the data in, awaits the result, and assigns it to the UI state.

It’s the same pattern as with services: the state stays on the main actor, and only Sendable values cross over to the background and back.

If you notice that you’re writing a lot of these functions in one view model, that’s usually a sign the work belongs in a service instead.

Protocols and Sendable

Sendable errors are really annoying. They show up in places you don’t expect, and the messages don’t always tell you what’s actually wrong.

Most of my Sendable errors came from services that were classes with some state hidden inside: a cached response, a counter, a mutable configuration. The moment such a service was stored in a main actor view model and called across isolation boundaries, the compiler complained. And it was right, because that state really could be accessed from two places at once.

With a stateless struct, the problem disappears. A struct without mutable state is Sendable naturally, so I put the requirement right into the protocol:

nonisolated protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

nonisolated protocol ProductService: Sendable {
    func fetchProducts() async throws -> [Product]
}

Every service I inject is now guaranteed to be safe to pass around. And the protocol gives me something I use all the time: I can swap the real service for a mock in previews and tests.

nonisolated struct MockProductService: ProductService {
    func fetchProducts() async throws -> [Product] {
        [Product(id: UUID(), name: "Preview Product", price: 9.99)]
    }
}

#Preview {
    ProductListView(viewModel: ProductListViewModel(service: MockProductService()))
}

nonisolated struct MockProductService: ProductService {
    func fetchProducts() async throws -> [Product] {
        [Product(id: UUID(), name: "Preview Product", price: 9.99)]
    }
}

#Preview {
    ProductListView(viewModel: ProductListViewModel(service: MockProductService()))
}

No server, no network, no Sendable errors. Just data in my preview.

Models: What Crosses From the Background to the Main Actor

Data travels from the service, which runs in the background, to the view model on the main actor. Whatever crosses that boundary has to be Sendable.

The Simple Way: A Struct

In most cases, I just use a struct for my model:

nonisolated struct Product: Identifiable, Codable, Sendable {
    let id: String
    let name: String
    let price: Decimal
}

nonisolated struct Product: Identifiable, Codable, Sendable {
    let id: String
    let name: String
    let price: Decimal
}

The service decodes it in the background and returns it, and the view model assigns it to its UI state. A struct with immutable properties is Sendable, so it crosses the boundary without complaints.

For many apps, this is all you need.

When the UI Modifies the Data: DTOs

Sometimes a struct isn’t enough. The user can rename a product or mark it as a favorite, and the views should update right away. For that, you want an @Observable class:

@MainActor
@Observable
final class Product: Identifiable {
    let id: String
    var name: String
    var isFavorite: Bool

    init(dto: ProductDTO) {
        id = dto.id
        name = dto.name
        isFavorite = dto.isFavorite
    }
}

@MainActor
@Observable
final class Product: Identifiable {
    let id: String
    var name: String
    var isFavorite: Bool

    init(dto: ProductDTO) {
        id = dto.id
        name = dto.name
        isFavorite = dto.isFavorite
    }
}

This class is UI state, so it’s isolated to the main actor. That means the service can’t create it in the background. Instead, the service returns a DTO, a data transfer object, which is a simple Sendable struct:

nonisolated struct ProductDTO: Codable, Sendable {
    let id: String
    let name: String
    let isFavorite: Bool
}

nonisolated struct ProductDTO: Codable, Sendable {
    let id: String
    let name: String
    let isFavorite: Bool
}

nonisolated struct RemoteProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [ProductDTO] {
        let url = URL(string: "https://api.example.com/products")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([ProductDTO].self, from: data)
    }
}

nonisolated struct RemoteProductService: ProductService {
    @concurrent
    func fetchProducts() async throws -> [ProductDTO] {
        let url = URL(string: "https://api.example.com/products")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([ProductDTO].self, from: data)
    }
}

The DTO crosses the boundary, and the view model turns it into the observable model on the main actor:

func loadProducts() async {
    do {
        let dtos = try await service.fetchProducts()
        products = dtos.map(Product.init)
    } catch {
        errorMessage = "Could not load products."
    }
}

func loadProducts() async {
    do {
        let dtos = try await service.fetchProducts()
        products = dtos.map(Product.init)
    } catch {
        errorMessage = "Could not load products."
    }
}

So the work is split by isolation. Fetching and decoding happen in the background and produce Sendable DTOs. Creating the observable models happens on the main actor, where they’re used as UI state. When you save changes, it goes the other way: the view model creates a DTO from the model and hands it to the service.

State the UI Never Sees Gets Its Own Actor

Some state isn’t UI state, but it’s still state. My favorite example is a token store. It holds the authentication token, refreshes it when it expires, and hands it to the network layer. No view ever displays the token.

So it doesn’t belong in the view model, and it doesn’t belong on the main actor. But it’s shared mutable state: several requests might ask for the token at the same time, and two of them might try to refresh it at once. That’s what actors are for:

actor TokenStore {
    private var token: String?
    private var refreshTask: Task<String, Error>?

    func validToken() async throws -> String {
        if let token { return token }

        if let refreshTask {
            return try await refreshTask.value
        }

        let task = Task { try await refreshToken() }
        refreshTask = task
        defer { refreshTask = nil }

        let newToken = try await task.value
        token = newToken
        return newToken
    }

    private func refreshToken() async throws -> String {
        // Call your auth endpoint here
        "new-token"
    }
}

actor TokenStore {
    private var token: String?
    private var refreshTask: Task<String, Error>?

    func validToken() async throws -> String {
        if let token { return token }

        if let refreshTask {
            return try await refreshTask.value
        }

        let task = Task { try await refreshToken() }
        refreshTask = task
        defer { refreshTask = nil }

        let newToken = try await task.value
        token = newToken
        return newToken
    }

    private func refreshToken() async throws -> String {
        // Call your auth endpoint here
        "new-token"
    }
}

The actor protects its state. If several requests ask for a token while a refresh is running, they all wait for the same refresh instead of starting their own. That kind of bug is really hard to find at runtime, and here the structure prevents it.

My Cheat Sheet

This is how it all comes together:

When I create a new type, I check what state it holds. That tells me which layer it belongs to and how it’s isolated, so I don’t have to fix concurrency errors afterward.

A Note on Project Settings

The code in this post assumes a new Xcode 26 project, where default main actor isolation is turned on. In that setup, every type is on the main actor unless you opt out, which is why the services, protocols, and models are marked nonisolated. The view model is main actor either way, but I keep the explicit @MainActor so the intent is clear.

If your project doesn’t use default main actor isolation, it’s the other way around. You don’t need the nonisolated markers, but you do need to add @MainActor to your view models yourself. @Observable doesn’t do that for you.

My Advice

If you’re fighting Swift concurrency right now, here’s what I’d recommend:

• Before you create a type, look at its state. UI state, non-UI state, or no state. That tells you where it belongs.
• Keep your view models for UI state. If the UI doesn’t read it, move it out.
• Make services stateless whenever you can. A stateless struct is the easiest thing to make Sendable.
• Use protocols that require Sendable. You get safe injection and easy mocks for previews and tests.
• Make your models value types. They cross every boundary without complaints.
• Give shared non-UI state its own actor. Don’t hide it in a view model or a singleton.
• When you hit a Sendable error, check where your state lives before adding annotations. Most of the time, the error is pointing at your structure.

The compiler is showing you exactly where your state is in the wrong place. Once your app is structured around state, it mostly stays quiet.

Further Reading

If you want to go deeper into how to separate your SwiftUI code, from views and view models to services and modules, check out my course.

Apple’s WWDC25 sessions

• Explore concurrency in SwiftUI. A good starting point if you’re wondering how SwiftUI and Swift concurrency fit together. It shows how SwiftUI runs on the main actor by default and hands work off to other actors.
• Embracing Swift concurrency. The best overview of the core concepts. It walks through taking an app from single-threaded to concurrent, with chapters on value types, actor-isolated types, and actors that match the layers in this post.
• Code-along: Elevate an app with Swift concurrency. A hands-on session that starts with a main-actor app, moves work to the background, and works through fixing data-race safety errors. It also covers the approachable concurrency settings.

Swift documentation

• The Swift Programming Language: Concurrency. The official language guide chapter on async/await, actors, and Sendable.
• Swift 6 Migration Guide. Useful if you’re moving an existing project to Swift 6 and hitting data-race errors.

Swift Evolution proposals

For the details behind the code in this post:

• SE-0461: Run nonisolated async functions on the caller’s actor by default. Introduces @concurrent and explains why it’s needed for background work.
• SE-0466: Control default actor isolation inference. The proposal behind default main actor isolation in new Xcode projects.
• SE-0449: Allow nonisolated to prevent global actor inference. Explains why you can mark types and protocols as nonisolated.

The post How I Architect SwiftUI Apps for Swift Concurrency – So the Compiler Stays Quiet appeared first on swiftyplace.

To understand Sendable, you first need to understand the problem it solves. And that problem is one of the most painful kinds of bugs in app development: data races.

The Crash You Can’t Reproduce

Let’s start with some code that many of us have written at some point. Here’s a simple cache for image data:

final class ImageCache {
    private var images: [URL: Data] = [:]

    func image(for url: URL) -> Data? {
        images[url]
    }

    func store(_ data: Data, for url: URL) {
        images[url] = data
    }
}

final class ImageCache {
    private var images: [URL: Data] = [:]

    func image(for url: URL) -> Data? {
        images[url]
    }

    func store(_ data: Data, for url: URL) {
        images[url] = data
    }
}

Nothing special. Now say you show a list of products, and each row loads its image in the background. When a download finishes, it stores the data in the shared cache so you don’t have to download it again:

func loadImages(for urls: [URL], cache: ImageCache) async {
    await withTaskGroup(of: Void.self) { group in
        for url in urls {
            group.addTask {
                guard let (data, _) = try? await URLSession.shared.data(from: url) else { return }
                cache.store(data, for: url)
            }
        }
    }
}

func loadImages(for urls: [URL], cache: ImageCache) async {
    await withTaskGroup(of: Void.self) { group in
        for url in urls {
            group.addTask {
                guard let (data, _) = try? await URLSession.shared.data(from: url) else { return }
                cache.store(data, for: url)
            }
        }
    }
}

You test it, and everything works. Images load, scrolling is smooth, the cache does its job. You ship it.

Then the crash reports come in. Not many, maybe one in a thousand sessions. The stack traces point somewhere deep inside Dictionary. You try to reproduce it on your device, and you can’t. You scroll the list a hundred times, and nothing happens.

This is a data race. And in Swift 5, the compiler didn’t say a word about it.

What a Data Race Is

A data race happens when two pieces of code access the same mutable state at the same time, and at least one of them writes to it.

In the image cache, that’s exactly what happens. Two rows finish their downloads at the same moment, and both call store on the same cache. Both write to the same dictionary at once. If the dictionary is in the middle of growing its storage when the second write comes in, its internal memory ends up in a broken state, and the app crashes.

You can make this visible with an even smaller example. Here’s a counter, incremented 1,000 times from concurrent tasks:

final class Counter {
    var value = 0

    func increment() {
        value += 1
    }
}

let counter = Counter()

await withTaskGroup(of: Void.self) { group in
    for _ in 0..<1000 {
        group.addTask { counter.increment() }
    }
}

print(counter.value)

final class Counter {
    var value = 0

    func increment() {
        value += 1
    }
}

let counter = Counter()

await withTaskGroup(of: Void.self) { group in
    for _ in 0..<1000 {
        group.addTask { counter.increment() }
    }
}

print(counter.value)

You’d expect 1,000. But run it a few times, and you might get 973, then 988, then 1,000. The result changes every time. value += 1 looks like one step, but it’s really three: read the value, add one, write it back. When two tasks read the same value at the same moment, both write back the same result, and one increment is lost.

Why Data Races Are So Painful

Data races are some of the hardest bugs to deal with, for several reasons.

They’re random. Whether a race happens depends on timing: which task runs first, how busy the device is, how fast the network responds. That’s why the cache worked perfectly on your device and crashed for one user in a thousand.

They hide. The crash often happens far from the actual cause. The stack trace points into Dictionary, but the real problem is that two tasks shared the cache without protection.

They corrupt data silently. Not every race crashes. The counter didn’t crash. It just gave the wrong result. In a real app, that could be a wrong total in a shopping cart or a lost user setting, and you might never notice.

Preventing them was all on you. Before Swift concurrency, you protected shared state with locks or serial dispatch queues. That works, but only if you remember it everywhere, every time. Forget one lock, and the bug is back.

The tools only helped at runtime. Thread Sanitizer can detect data races, but only if the race actually happens while it’s running. If the timing doesn’t line up during your test, it finds nothing.

Swift Concurrency Moves This into the Compiler

This is the problem Swift concurrency was designed to solve. Instead of hoping you remember every lock, the compiler checks for data races before your app ever runs.

To do that, Swift concurrency is built into the type system. Isolation is part of a type, just like its properties and functions. Every piece of code runs in an isolation domain, as described in the concurrency chapter of The Swift Programming Language:

• The main actor, where your UI code runs.
• A specific actor, which protects its own state.
• Nonisolated, which doesn’t belong to any actor.

Inside one isolation domain, only one piece of code runs at a time, so accessing state there is safe. The danger is when values cross from one domain to another, like when the cache is captured by several tasks running at the same time.

And this is where the compiler steps in. In Swift 6, the loadImages function from the beginning doesn’t compile anymore. The compiler sees that the cache is shared between tasks that can run concurrently, and that it isn’t safe to share. It tells you that ImageCache isn’t Sendable.

What Sendable Means

Sendable is a promise that a value is safe to pass from one isolation domain to another. It was introduced in SE-0302, and you can find the full rules in Apple’s Sendable documentation.

When a type is Sendable, the compiler knows that sharing it across tasks or actors can’t cause a data race. When it isn’t, the compiler stops you from passing it across.

A few things are worth knowing:

• It’s checked at compile time. Sendable has no runtime cost. It only exists so the compiler can check your code.
• It’s only checked at boundaries. Within one isolation domain, non-Sendable types are completely fine. The compiler only cares when a value crosses from one domain to another.
• It’s about state. Whether a type can be Sendable depends on what state it holds and how that state is protected.

Which Types Are Sendable

Structs and Enums

Structs and enums are value types. When you pass one to another isolation domain, it’s copied, so both sides have their own copy and nothing is shared.

That’s why a struct can have var properties and still be Sendable. Each copy has its own mutable state, and changing one doesn’t affect the other.

struct Product: Sendable {
    let id: UUID
    var name: String    // fine, each copy has its own name
}

struct Product: Sendable {
    let id: UUID
    var name: String    // fine, each copy has its own name
}

A struct or enum is Sendable automatically if all its stored properties are Sendable. Standard types like Int, String, Data, Array, Dictionary, and Optional are Sendable as long as their contents are. One exception: public types don’t get this automatically, so you need to declare Sendable explicitly.

But a struct isn’t automatically safe just because it’s a struct. If it holds a class that isn’t Sendable, the copy still points to the same shared instance:

struct Order {
    var product: Product
    var cache: ImageCache   // a non-Sendable class, so Order isn't Sendable
}

struct Order {
    var product: Product
    var cache: ImageCache   // a non-Sendable class, so Order isn't Sendable
}

Classes Without var

A class is a reference type. Passing it around doesn’t copy it. Everyone shares the same instance.

But if nobody can change that instance, sharing it is safe. A class with only let properties of Sendable types can be Sendable. It has to be final, though, because a subclass could add mutable state. And you need to declare the conformance yourself:

final class Configuration: Sendable {
    let baseURL: URL
    let timeout: TimeInterval

    init(baseURL: URL, timeout: TimeInterval) {
        self.baseURL = baseURL
        self.timeout = timeout
    }
}

final class Configuration: Sendable {
    let baseURL: URL
    let timeout: TimeInterval

    init(baseURL: URL, timeout: TimeInterval) {
        self.baseURL = baseURL
        self.timeout = timeout
    }
}

Classes With var

This is the classic problem, and it’s exactly what our image cache and counter are. A class with mutable state, shared between isolation domains, means two pieces of code can read and write the same state at the same time.

A class like this can’t simply be Sendable. It needs protection, and there are a few ways to add it.

Isolate it to the main actor. A @MainActor class is Sendable, because all access to its state happens on the main actor, one at a time. This is what your view models look like:

@MainActor
final class CounterViewModel {
    var count = 0   // protected by the main actor
}

@MainActor
final class CounterViewModel {
    var count = 0   // protected by the main actor
}

Turn it into an actor. That’s coming up next.

Protect it with a lock. You can synchronize the state yourself, for example with Mutex from the Synchronization framework. With older locks like NSLock, you mark the class @unchecked Sendable, which tells the compiler to trust you. More on that later.

Actors

Actors are always Sendable (WWDC session Protect mutable state with Swift actors.). They can have mutable state because they protect it themselves: only one caller accesses an actor’s state at a time. Everyone else waits for their turn, which is why you call an actor’s methods with await from outside.

actor TokenStore {
    private var token: String?

    func store(_ newToken: String) {
        token = newToken
    }
}

actor TokenStore {
    private var token: String?

    func store(_ newToken: String) {
        token = newToken
    }
}

One thing to keep in mind: an actor protects its own state, not the values you pass into it. The parameters and return values of its methods still need to be Sendable.

Closures

Closures matter too, because tasks are closures. A closure that runs in another isolation domain needs to be @Sendable, which means it can only capture Sendable values and can’t capture mutable local variables.

That’s exactly what went wrong in loadImages: the closure passed to addTask captured the non-Sendable cache. Many confusing errors with Task and callbacks come down to this rule.

Summary

Fixing the Image Cache

Back to the cache. Which option fits?

The cache is shared mutable state. It needs to be shared, because every row should benefit from images that other rows already downloaded. And the UI doesn’t read the cache directly. So the right fit is an actor:

actor ImageCache {
    private var images: [URL: Data] = [:]

    func image(for url: URL) -> Data? {
        images[url]
    }

    func store(_ data: Data, for url: URL) {
        images[url] = data
    }
}

actor ImageCache {
    private var images: [URL: Data] = [:]

    func image(for url: URL) -> Data? {
        images[url]
    }

    func store(_ data: Data, for url: URL) {
        images[url] = data
    }
}

The only change in loadImages is an await:

group.addTask {
    guard let (data, _) = try? await URLSession.shared.data(from: url) else { return }
    await cache.store(data, for: url)
}

group.addTask {
    guard let (data, _) = try? await URLSession.shared.data(from: url) else { return }
    await cache.store(data, for: url)
}

Now only one task at a time can access the dictionary. When two downloads finish at the same moment, one waits for the other.

Why not the other options? A struct would give every task its own copy, so it wouldn’t be a shared cache anymore. Putting the cache on the main actor would also be safe, but then every background task would have to hop over to the main actor just to store some data, competing with your UI for no reason.

The crash is gone. And it’s gone not because you remembered a lock, but because the compiler won’t let you share the cache unsafely again.

The Real Problem: Shared Mutable State Without Protection

If you take one thing from this post, let it be this: mutable state alone isn’t the problem. A struct can have var properties and be perfectly safe.

The problem is state that is shared and mutable without protection. Take away any one of those three, and the data race is gone:

• Value types avoid sharing, because every copy is separate.
• Immutable classes avoid mutation, because nobody can change them.
• Actors and the main actor add protection, because only one caller accesses the state at a time.

Sendable is how the compiler checks that one of these is true for every value crossing a boundary.

What This Means for Structuring Your App

Once you see Sendable this way, it changes how you structure your code. The question for every type becomes: what kind of state does it hold?

• UI state lives on the main actor. That’s your view models and coordinators.
• Non-UI state lives in its own actor. That’s your image cache or a token store.
• No state means nothing to protect. That’s stateless services and value-type models.

When your components are organized this way, most Sendable errors never show up in the first place. I go deeper into this in How I Structure SwiftUI Apps So the Compiler Stays Quiet.

What Sendable Errors Are Telling You

Sendable errors can be really annoying. But most of them say the same thing: mutable state is about to cross a boundary without protection.

The most common causes I see are:

• Class-based models. A model class with var properties passed from a service to a view model.
• Services with hidden state. A service class that keeps a cache or a counter inside.
• Closures capturing mutable variables. A var captured by a Task or a callback.

So before adding annotations to make an error go away, ask where this state should live. Often the fix is to turn a class into a struct, move state into an actor, or make a service stateless.

The Escape Hatches

Swift gives you ways to turn off the checks: @unchecked Sendable for types and nonisolated(unsafe) for variables.

They have legitimate uses. If you protect a class’s state with a lock yourself, @unchecked Sendable tells the compiler you’ve got it covered. With Mutex from the Synchronization framework, you often don’t even need that, because Mutex itself is Sendable, so a final class that stores its state in a let mutex can be checked by the compiler.

But if you use these just to silence errors, you’re bringing back exactly the kind of crash from the beginning of this post. The compiler stops checking, and you’re back to random crashes you can’t reproduce.

Why Some Non-Sendable Code Still Compiles

At some point, you’ll notice that a non-Sendable value crosses a boundary and the compiler doesn’t complain. That’s not a bug.

Since Swift 6, the compiler can see when you pass a non-Sendable value to another isolation domain and never use it again in the original one. If you hand it off completely, nothing is shared, so there’s no risk of a data race. The rules haven’t changed: the compiler is just smart enough to see that the state isn’t actually shared.

Wrap-Up

Data races used to be some of the hardest bugs to find. They were random, they hid behind misleading crash reports, and preventing them depended on never forgetting a single lock.

Sendable changes that. It turns those runtime crashes into compiler errors, on your machine, before your users ever see them. The errors can be annoying, but every one of them points to state that could have crashed your app.

Think about where your state lives, whether it’s shared, and how it’s protected. Once you do, Sendable stops feeling like a fight with the compiler.

Further Reading

• Eliminate data races using Swift Concurrency (WWDC22)
• Protect mutable state with Swift actors (WWDC21)
• Migrate your app to Swift 6 (WWDC24)
• Embracing Swift concurrency (WWDC25)
• Swift 6 migration guide
• How I Structure SwiftUI Apps So the Compiler Stays Quiet.

The post What Is Sendable in Swift? How Swift Concurrency Protects Your State appeared first on swiftyplace.

How many files do I open? How many hops before I find the right line? How confident am I that my change won’t break something three screens away?

I’ve started measuring architecture by these small, boring moments. And what I’ve found — again and again — is that the codebases that feel best to work with share a few traits: they’re simple, they’re consistent, and they’re a little repetitive.

That last one surprises people. We’ve been trained to think repetition is a code smell. I think it’s often the opposite.

The Allure of Abstraction

Let me show you a pattern I keep running into in SwiftUI projects: the global router. You can see an example project on Github here which is a BlueSky client.

It always starts the same way. You have four tabs, each needs a title and an icon, so you model it as an enum:

enum AppTab: String, CaseIterable, Identifiable {
    case feed
    case notifications
    case profile
    case settings

    var id: String { rawValue }

    var title: String {
        switch self {
        case .feed: "Feed"
        case .notifications: "Notifications"
        case .profile: "Profile"
        case .settings: "Settings"
        }
    }

    var icon: String {
        switch self {
        case .feed: "house"
        case .notifications: "bell"
        case .profile: "person"
        case .settings: "gearshape.fill"
        }
    }
}

enum AppTab: String, CaseIterable, Identifiable {
    case feed
    case notifications
    case profile
    case settings

    var id: String { rawValue }

    var title: String {
        switch self {
        case .feed: "Feed"
        case .notifications: "Notifications"
        case .profile: "Profile"
        case .settings: "Settings"
        }
    }

    var icon: String {
        switch self {
        case .feed: "house"
        case .notifications: "bell"
        case .profile: "person"
        case .settings: "gearshape.fill"
        }
    }
}

Then your tab view loops over the cases:

struct AppTabView: View {
    @State var selectedTab: AppTab = .feed

    var body: some View {
        TabView(selection: $selectedTab) {
            ForEach(AppTab.allCases) { tab in
                tab.rootView
                    .tabItem {
                        Label(tab.title, systemImage: tab.icon)
                    }
                    .tag(tab)
            }
        }
    }
}

struct AppTabView: View {
    @State var selectedTab: AppTab = .feed

    var body: some View {
        TabView(selection: $selectedTab) {
            ForEach(AppTab.allCases) { tab in
                tab.rootView
                    .tabItem {
                        Label(tab.title, systemImage: tab.icon)
                    }
                    .tag(tab)
            }
        }
    }
}

Clean. No repetition. The enum drives everything. This feels right.

Then the app grows. You need navigation destinations, so you add a route enum:

enum AppRoute: Hashable {
    case postDetail(Post)
    case userProfile(User)
    case settings
    case followers(User)
    case following(User)
    case editProfile
    // ... keeps growing
}

enum AppRoute: Hashable {
    case postDetail(Post)
    case userProfile(User)
    case settings
    case followers(User)
    case following(User)
    case editProfile
    // ... keeps growing
}

You need sheets, so you add another enum:

enum SheetDestination: Identifiable {
    case auth
    case newPost
    case mediaViewer(MediaItem)
    case editProfile
    case reportContent(Post)

    var id: String { /* ... */ }
}

enum SheetDestination: Identifiable {
    case auth
    case newPost
    case mediaViewer(MediaItem)
    case editProfile
    case reportContent(Post)

    var id: String { /* ... */ }
}

And a centralized modifier to wire it all up:

struct AppDestinationsModifier: ViewModifier {
    @Environment(Router.self) var router

    func body(content: Content) -> some View {
        content
            .navigationDestination(for: AppRoute.self) { route in
                switch route {
                case .postDetail(let post):
                    PostDetailView(post: post)
                case .userProfile(let user):
                    ProfileView(user: user)
                case .settings:
                    SettingsView()
                case .followers(let user):
                    FollowersListView(user: user)
                case .following(let user):
                    FollowingListView(user: user)
                case .editProfile:
                    EditProfileView()
                }
            }
            .sheet(item: $router.presentedSheet) { destination in
                switch destination {
                case .auth:
                    AuthenticationLoginView()
                case .newPost:
                    ComposerView()
                case .mediaViewer(let media):
                    MediaDetailView(media: media)
                case .editProfile:
                    EditProfileView()
                case .reportContent(let post):
                    ReportView(post: post)
                }
            }
    }
}

struct AppDestinationsModifier: ViewModifier {
    @Environment(Router.self) var router

    func body(content: Content) -> some View {
        content
            .navigationDestination(for: AppRoute.self) { route in
                switch route {
                case .postDetail(let post):
                    PostDetailView(post: post)
                case .userProfile(let user):
                    ProfileView(user: user)
                case .settings:
                    SettingsView()
                case .followers(let user):
                    FollowersListView(user: user)
                case .following(let user):
                    FollowingListView(user: user)
                case .editProfile:
                    EditProfileView()
                }
            }
            .sheet(item: $router.presentedSheet) { destination in
                switch destination {
                case .auth:
                    AuthenticationLoginView()
                case .newPost:
                    ComposerView()
                case .mediaViewer(let media):
                    MediaDetailView(media: media)
                case .editProfile:
                    EditProfileView()
                case .reportContent(let post):
                    ReportView(post: post)
                }
            }
    }
}

At this point, search your project for Router or AppRoute. You’ll find it in nearly every file. That innocent enum has become the most coupled dependency in your entire application. A god object that everything needs and nothing can work without.

Here’s the boring alternative. No enum. No router. Just tabs:

TabView(selection: $selectedTab) {
    FeedView()
        .tabItem { Label("Feed", systemImage: "house") }
        .tag(AppTab.feed)

    NotificationsView()
        .tabItem { Label("Notifications", systemImage: "bell") }
        .tag(AppTab.notifications)

    ProfileView()
        .tabItem { Label("Profile", systemImage: "person") }
        .tag(AppTab.profile)

    SettingsView()
        .tabItem { Label("Settings", systemImage: "gearshape.fill") }
        .tag(AppTab.settings)
}

TabView(selection: $selectedTab) {
    FeedView()
        .tabItem { Label("Feed", systemImage: "house") }
        .tag(AppTab.feed)

    NotificationsView()
        .tabItem { Label("Notifications", systemImage: "bell") }
        .tag(AppTab.notifications)

    ProfileView()
        .tabItem { Label("Profile", systemImage: "person") }
        .tag(AppTab.profile)

    SettingsView()
        .tabItem { Label("Settings", systemImage: "gearshape.fill") }
        .tag(AppTab.settings)
}

I have to repeat the code to write NavigaitonStack and the destinations for each Tab:

struct FeedView: View {
   ...

    var body: some View {
        NavigationStack(path: $path) {
            FeedsListView()
                .navigationDestination(for: FeedDestination.self) { destination in
                    switch destination {
                        case .feed(let feedItem):
                            PostsFeedView(client: client, feedItem: feedItem)
                        case .post(let post):
                            PostDetailView(post: post)
                        case .timeline:
                            PostsTimelineView(client: client)
                        case .profile(let profile):
                            ProfileView(profile: profile)
                        case .profilePosts(let profile, let filter):
                            PostsProfileView(client: client, profile: profile, filter: filter)
                        case .profileLikes(let profile):
                            PostsLikesView(client: client, profile: profile)
                    }
                }
        }
    }
}

struct FeedView: View {
   ...

    var body: some View {
        NavigationStack(path: $path) {
            FeedsListView()
                .navigationDestination(for: FeedDestination.self) { destination in
                    switch destination {
                        case .feed(let feedItem):
                            PostsFeedView(client: client, feedItem: feedItem)
                        case .post(let post):
                            PostDetailView(post: post)
                        case .timeline:
                            PostsTimelineView(client: client)
                        case .profile(let profile):
                            ProfileView(profile: profile)
                        case .profilePosts(let profile, let filter):
                            PostsProfileView(client: client, profile: profile, filter: filter)
                        case .profileLikes(let profile):
                            PostsLikesView(client: client, profile: profile)
                    }
                }
        }
    }
}

More repetitive? Sure. But now let me show you what happens when we start working with both.

Ticket 1: Change a Tab Icon

First ticket of the day. The Settings tab uses a filled gear icon. Design wants the outline version instead. A one-line change.

The direct version. I open the app file, I see the tabs, I see "gearshape.fill", I change it to "gearshape". One file. Done. The icon is right next to the view it belongs to. I didn’t have to think.

TabView(selection: $selectedTab) {
    FeedListView()
        .tabItem { Label("Feed", systemImage: "house") }
        .tag(AppTab.feed)

    ...

    SettingsView()
        .tabItem { Label("Settings", systemImage: "gearshape.fill") } // change this line
        .tag(AppTab.settings)
}

TabView(selection: $selectedTab) {
    FeedListView()
        .tabItem { Label("Feed", systemImage: "house") }
        .tag(AppTab.feed)

    ...

    SettingsView()
        .tabItem { Label("Settings", systemImage: "gearshape.fill") } // change this line
        .tag(AppTab.settings)
}

The router version. I open the app file, I find the TabView, I see ForEach(AppTab.allCases). The label references tab.icon. So I navigate to the AppTab enum, find the icon computed property, scroll to the .settings case, and change it there.

enum AppTab: String, CaseIterable, Identifiable {
    case feed
    case notifications
    case profile
    case settings

    var id: String { rawValue }

    var title: String {
       ...
    }

    var icon: String {
        switch self {
        case .feed: "house"
        case .notifications: "bell"
        case .profile: "person"
        case .settings: "gearshape.fill" // change this line
        }
    }
}

enum AppTab: String, CaseIterable, Identifiable {
    case feed
    case notifications
    case profile
    case settings

    var id: String { rawValue }

    var title: String {
       ...
    }

    var icon: String {
        switch self {
        case .feed: "house"
        case .notifications: "bell"
        case .profile: "person"
        case .settings: "gearshape.fill" // change this line
        }
    }
}

Same result, but I had to open a second file and trace through a level of indirection to get there. The icon doesn’t live where the tab is. It lives on a property, on an enum case, in a model file.

On its own, this is nothing. One extra file. But these “nothing” moments happen twenty times a day.

Ticket 2: Reorder the Tabs

Product wants Profile before Notifications. The tab bar should read: Feed, Profile, Notifications, Settings.

The direct version. I move the Profile code block above the Notifications block:

TabView(selection: $selectedTab) {
    FeedListView()
        .tabItem { Label("Feed", systemImage: "house") }
        .tag(AppTab.feed)

    ProfileView()                // moved up
        .tabItem { Label("Profile", systemImage: "person") }
        .tag(AppTab.profile)

    NotificationsView()          // moved down
        .tabItem { Label("Notifications", systemImage: "bell") }
        .tag(AppTab.notifications)

    SettingsView()
        .tabItem { Label("Settings", systemImage: "gearshape") }
        .tag(AppTab.settings)
}

TabView(selection: $selectedTab) {
    FeedListView()
        .tabItem { Label("Feed", systemImage: "house") }
        .tag(AppTab.feed)

    ProfileView()                // moved up
        .tabItem { Label("Profile", systemImage: "person") }
        .tag(AppTab.profile)

    NotificationsView()          // moved down
        .tabItem { Label("Notifications", systemImage: "bell") }
        .tag(AppTab.notifications)

    SettingsView()
        .tabItem { Label("Settings", systemImage: "gearshape") }
        .tag(AppTab.settings)
}

Declaration order is display order. It’s so obvious it barely requires thought.

The router version. The TabView uses ForEach(AppTab.allCases). The allCases property comes from the CaseIterable protocol, which returns cases in the order they’re declared in the enum. So to reorder the tabs on screen, I reorder the cases in the enum definition:

enum AppTab: String, CaseIterable, Identifiable {
    case feed
    case profile        // moved up
    case notifications  // moved down
    case settings
}

enum AppTab: String, CaseIterable, Identifiable {
    case feed
    case profile        // moved up
    case notifications  // moved down
    case settings
}

Stop and think about what just happened. I changed a model definition. The declaration order of an enum’s cases to achieve a UI change. Nothing in the TabView tells you this. Nothing in the view layer hints at it. The connection between “what I see on screen” and “what I need to change in code” passes through a protocol conformance that’s completely invisible unless you already know how CaseIterable works.

If you know this pattern, you’ll find it in five minutes. If you’re a junior developer or an intern picking up this ticket on a Friday afternoon, you might spend half an hour wondering how to reorder the views in the TabView with a ForEach.

Ticket 3: Add a New Screen

Here’s where the real cost shows up. The Profile tab needs a new screen: a “Blocked Users” list, accessible from the user’s profile page. Straightforward feature work.

But first, let me show you what the router pattern has grown into by this point. As the app added more screens, all navigation destinations were centralized into a single modifier applied to the entire tab view:

public struct AppDestinations: ViewModifier {
    public func body(content: Content) -> some View {
        content
            .navigationDestination(for: RouterDestination.self) { destination in
                switch destination {
                case .feed(let feedItem):
                    PostsFeedView(feedItem: feedItem)
                case .post(let post):
                    PostDetailView(post: post)
                case .timeline:
                    PostsTimelineView()
                case .profile(let profile):
                    ProfileView(profile: profile)
                case .profilePosts(let profile, let filter):
                    PostsProfileView(profile: profile, filter: filter)
                case .profileLikes(let profile):
                    PostsLikesView(profile: profile)
                }
            }
    }
}

public struct AppDestinations: ViewModifier {
    public func body(content: Content) -> some View {
        content
            .navigationDestination(for: RouterDestination.self) { destination in
                switch destination {
                case .feed(let feedItem):
                    PostsFeedView(feedItem: feedItem)
                case .post(let post):
                    PostDetailView(post: post)
                case .timeline:
                    PostsTimelineView()
                case .profile(let profile):
                    ProfileView(profile: profile)
                case .profilePosts(let profile, let filter):
                    PostsProfileView(profile: profile, filter: filter)
                case .profileLikes(let profile):
                    PostsLikesView(profile: profile)
                }
            }
    }
}

Look at this switch statement for a moment. Six destinations. Which ones belong to the Feed tab? Which ones belong to the Profile tab? Can the Feed tab navigate to profileLikes? Can the Profile tab navigate to timeline? You can’t tell. Everything is flattened into one bucket with no indication of which tab uses what.

So, back to the ticket. To add the Blocked Users screen, I need to:

1. Add a new case to the RouterDestination enum
2. Add a new branch to this switch statement
3. Hope that I’m not accidentally making this screen reachable from tabs that shouldn’t have it

enum RouterDestination: Hashable {
    case feed(FeedItem)
    case post(Post)
    case timeline
    case profile(Profile)
    case profilePosts(Profile, PostFilter)
    case profileLikes(Profile)
    case blockedUsers              // new
}

enum RouterDestination: Hashable {
    case feed(FeedItem)
    case post(Post)
    case timeline
    case profile(Profile)
    case profilePosts(Profile, PostFilter)
    case profileLikes(Profile)
    case blockedUsers              // new
}

case .blockedUsers:
    BlockedUsersView()

case .blockedUsers:
    BlockedUsersView()

Done? Technically yes. But think about what just happened. I added a Profile feature to a global modifier that the Feed tab, the Notifications tab, and the Settings tab all share. Nothing in this code says “this destination belongs to Profile.” It just sits in the pile with everything else.

And think about what this file looks like two years from now. The app keeps growing. More screens, more destinations:

case .feed(let feedItem): PostsFeedView(feedItem: feedItem)
case .post(let post): PostDetailView(post: post)
case .timeline: PostsTimelineView()
case .profile(let profile): ProfileView(profile: profile)
case .profilePosts(let profile, let filter): PostsProfileView(...)
case .profileLikes(let profile): PostsLikesView(profile: profile)
case .blockedUsers: BlockedUsersView()
case .search(let query): SearchResultsView(query: query)
case .followers(let user): FollowersListView(user: user)
case .following(let user): FollowingListView(user: user)
case .editProfile: EditProfileView()
case .thread(let post): ThreadView(post: post)
case .hashtag(let tag): HashtagFeedView(tag: tag)
case .quotePosts(let post): QuotePostsView(post: post)
case .mutedWords: MutedWordsView()

case .feed(let feedItem): PostsFeedView(feedItem: feedItem)
case .post(let post): PostDetailView(post: post)
case .timeline: PostsTimelineView()
case .profile(let profile): ProfileView(profile: profile)
case .profilePosts(let profile, let filter): PostsProfileView(...)
case .profileLikes(let profile): PostsLikesView(profile: profile)
case .blockedUsers: BlockedUsersView()
case .search(let query): SearchResultsView(query: query)
case .followers(let user): FollowersListView(user: user)
case .following(let user): FollowingListView(user: user)
case .editProfile: EditProfileView()
case .thread(let post): ThreadView(post: post)
case .hashtag(let tag): HashtagFeedView(tag: tag)
case .quotePosts(let post): QuotePostsView(post: post)
case .mutedWords: MutedWordsView()

Fifteen cases. All in one switch. Every developer on the team edits this same file whenever they add a screen, anywhere in the app. Profile developer and Feed developer and Settings developer all touching the same enum, the same switch, the same modifier. Merge conflicts become routine. And the worst part: a change to profile navigation could affect the feed tab, and you wouldn’t know until runtime.

Now imagine a real production app. Not fifteen screens. Fifty. A hundred. This file becomes an archaeological dig site, and every new screen makes the dig deeper.

The root cause is structural. You’ve taken navigation that is inherently local (“from this screen, you can go to these screens”) and made it global. Global things don’t scale.

Now the same ticket with the boring approach. Each tab has its own NavigationStack and declares its own destinations:

// Feed tab
NavigationStack {
    FeedListView()
        .navigationDestination(for: Post.self) { post in
            PostDetailView(post: post)
        }
        .navigationDestination(for: FeedItem.self) { item in
            PostsFeedView(feedItem: item)
        }
}

// Profile tab
NavigationStack {
    ProfileView()
        .navigationDestination(for: PostFilter.self) { filter in
            PostsProfileView(filter: filter)
        }
        .navigationDestination(for: User.self) { user in
            UserDetailView(user: user)
        }
}

// Feed tab
NavigationStack {
    FeedListView()
        .navigationDestination(for: Post.self) { post in
            PostDetailView(post: post)
        }
        .navigationDestination(for: FeedItem.self) { item in
            PostsFeedView(feedItem: item)
        }
}

// Profile tab
NavigationStack {
    ProfileView()
        .navigationDestination(for: PostFilter.self) { filter in
            PostsProfileView(filter: filter)
        }
        .navigationDestination(for: User.self) { user in
            UserDetailView(user: user)
        }
}

Adding the Blocked Users screen? I add a .navigationDestination to the Profile tab’s stack:

// Profile tab
NavigationStack {
    ProfileView()
        .navigationDestination(for: PostFilter.self) { filter in
            PostsProfileView(filter: filter)
        }
        .navigationDestination(for: User.self) { user in
            UserDetailView(user: user)
        }
        .navigationDestination(for: BlockedUsersRoute.self) { _ in
            BlockedUsersView()    // new, only here
        }
}

// Profile tab
NavigationStack {
    ProfileView()
        .navigationDestination(for: PostFilter.self) { filter in
            PostsProfileView(filter: filter)
        }
        .navigationDestination(for: User.self) { user in
            UserDetailView(user: user)
        }
        .navigationDestination(for: BlockedUsersRoute.self) { _ in
            BlockedUsersView()    // new, only here
        }
}

That’s it. One file. One tab. The Feed tab doesn’t know about it. The Notifications tab isn’t affected. No shared enum to extend. No shared switch to edit. No merge conflict with the developer adding search to the Feed tab.

I can look at the Profile tab’s code and see every screen it can navigate to. I can look at the Feed tab’s code and see every screen it can navigate to. The structure tells me the truth. I don’t need to cross-reference a central registry to figure out which destinations belong where.

Yes, I wrote NavigationStack multiple times. Yes, if both Feed and Profile can navigate to PostDetailView, it shows up in two places. That’s more code. That’s more repetition. And I’ll take that trade every single time, because the alternative is a centralized switch statement that grows without limit and tells me nothing about which feature owns which screen.

The router version scales by making one file bigger and bigger. The direct version scales by keeping each tab small and independent. One approach has a ceiling. The other doesn’t.

The Abstraction Tax

There’s a pattern running through all three of these tickets. The router version always takes more hops. Always requires opening more files. Always demands that I understand the system before I can make a simple change: the enum, the protocol conformance, the centralized modifier, the destination switch.

Each individual layer feels small and reasonable when you add it. “I’ll just put the icons on the enum.” “I’ll just centralize the destinations.” “I’ll just use CaseIterable for the tab order.” Each one is a defensible decision in isolation.

But they stack. And the cost isn’t paid by the person who built the abstraction. They understand it perfectly, they just created it. The cost is paid by every person who reads the code afterward. The next developer on the team. The new hire trying to onboard. You, three months from now, after you’ve forgotten the details.

And those three tickets? They’re not edge cases. They’re the most common kind of work in any codebase. Change an icon. Reorder some items. Add a new screen. This is what a normal week looks like. If your architecture makes normal work harder, it’s not helping you.

Repetition Isn’t the Enemy

At this point you might be looking at the boring version with four NavigationStack declarations, PostDetailView showing up in two tabs, .tabItem written out four times, and thinking: isn’t this exactly what DRY tells me not to do?

DRY stands for “Don’t Repeat Yourself.” The idea is straightforward: if the same piece of knowledge exists in two places, eventually one gets updated and the other doesn’t. You define a tax rate in your checkout flow and again in your invoice generator. Someone updates checkout to 10%. Nobody touches the invoice. It still says 8%. Customers get charged one thing and invoiced another. That’s a real bug, and DRY prevents it. Put the tax rate in one place, reference it everywhere.

But a NavigationStack in the Feed tab and a NavigationStack in the Profile tab aren’t the same piece of knowledge defined twice. They’re two different things that happen to use the same API. Each one is scoped to its own tab. Each one owns different destinations. They’re configured independently and they change independently. There’s nothing to drift apart because they were never the same thing.

Same with PostDetailView appearing as a destination in two tabs. That feels like duplication, but what would actually go wrong? If you change PostDetailView(post:) to PostDetailView(post:showComments:), every call site that’s outdated fails to compile. You get a red error in both tabs. You fix them in thirty seconds. The compiler already prevents the drift that DRY is designed to prevent.

The discomfort with the boring version is real, but it’s pattern recognition misfiring. We’ve trained ourselves to see any repetition as a problem. Sometimes repetition is just structure. Four tabs, four navigation stacks. That’s not duplication. That’s how tabs work.

What “Simple, Consistent, and a Little Repetitive” Means

When I say I prefer boring code, I mean something specific.

Simple means the path from “what I see on screen” to “what I change in code” is short. If I see a gear icon in the tab bar, I should find "gearshape" within one or two file hops. Not on a computed property on an enum case in a model file.

Consistent means the same pattern is used the same way everywhere. Every tab has its own NavigationStack. Every tab declares its own destinations locally. You learn the pattern once, and you can predict where things live in any part of the app.

New developer onboarding becomes a thirty-second conversation. “Each tab has a NavigationStack. Destinations are declared in the tab that uses them.” That’s the architecture. There’s no router to learn, no centralized modifier to memorize, no CaseIterable trick to discover.

A little repetitive means I’ll write NavigationStack four times. I’ll write .tabItem { Label(...) } four times. I’ll declare destinations per tab instead of in a shared modifier. And I won’t feel bad about it, because each of those repetitions makes the code more local, more self-contained, and more obvious.

Every time I’m tempted to extract a shared abstraction, I ask myself: does this repetition actually cause problems? Will these four NavigationStack declarations drift apart in a way that matters? Or am I just uncomfortable with code that looks a little verbose?

Usually it’s the discomfort. And I’ve learned to sit with that discomfort, because the alternative, another layer of indirection, another file hop, another concept someone has to learn, is worse.

The Friday Afternoon Test

Here’s the test I keep coming back to. It’s Friday afternoon. You’ve been coding all week. You’re tired. A ticket comes in. Change an icon. Reorder tabs. Add a new screen to the Profile tab.

In the simple, boring codebase, you open the relevant file, you see the code laid out directly in front of you, you make the change. Ten minutes, including running the app to verify.

In the clever, abstracted codebase, you open the file and the actual content is somewhere else. Driven by an enum. Routed through a modifier. Ordered by a protocol conformance. You start jumping. File to file, layer to layer, holding the mental thread of where you started. You find the right spot eventually, but it took three times as long and you’re still not sure your change won’t ripple into a tab you never meant to touch.

Both get you to the same result. One of them will still work fine when the app has fifty screens and three new developers who’ve never seen the codebase. The other will have a RouterDestination enum with eighty cases and a AppDestinations modifier that nobody wants to touch.

Don’t add abstractions you don’t need. Prefer code you can follow without a tour guide, even if it means writing NavigationStack four times. The app doesn’t care how clever your architecture is. It cares whether you can ship the next ticket without breaking the last one.

Further Reading

Navigation in SwiftUI. Apple’s documentation on NavigationStack and navigationDestination is worth reading carefully. A lot of the router patterns people reach for exist because they carried habits over from other frameworks. SwiftUI’s declarative navigation already solves many of the problems routers were built for. Sometimes the best abstraction is the one the framework already gives you.

• WWDC22 Session 10054, “The SwiftUI cookbook for navigation” (shows NavigationStack and navigationDestination in practice, the API the “boring” version is built on)
• Apple’s NavigationStack

Coordinator pattern. If your navigation decisions depend on logic that doesn’t belong in a view, coordinators are worth exploring. A background network request finishes and you need to present a specific sheet based on the result. A push notification arrives and you need to navigate somewhere. Who holds that logic? A coordinator sits above the view layer, owns the navigation state, and makes those decisions. The key: don’t build one global coordinator. Build small, scoped ones per feature. For most simple apps you won’t need them, but when navigation starts depending on async events and external triggers, they give you a clean home for that logic.

Modularization with Swift packages. The global router is a modularization killer. It imports every screen in the app, which means it depends on every feature. You can’t extract your Profile feature into its own package without the router package also depending on it, and on Feed, and on Settings, and on everything else. The approach in this post avoids that entirely. Each tab already owns its navigation and only knows about its own screens. When the time comes to split into packages, the boundaries are already there.

The post Simple, Consistent, and a Little Repetitive appeared first on swiftyplace.

The AttributeGraph

SwiftUI maintains an internal data structure called the AttributeGraph. It’s a directed graph where every node represents a value. A view’s body, a modifier, a piece of state, and the edges are the dependencies between them.

When a state value changes, SwiftUI walks the edges to find exactly which nodes are affected and only reevaluates those. This is how SwiftUI decides whether your view’s body needs to run again. It’s not diffing a DOM. It’s tracking state dependencies.

If you’ve ever opened Instruments and looked at the SwiftUI cause-and-effect graph, you’ve seen a slice of this. That’s the AttributeGraph. The nodes, the edges, the dependency chains. That’s what’s running your app.

What does the @State Property Wrapper do?

When SwiftUI sees @State, it creates a node in the AttributeGraph to store this value. Here’s what that looks like in practice:

struct ParentView: View {
    // This creates a node in the AttributeGraph that holds the Int.
    // ParentView.body has a dependency edge to this node.
    @State private var counter = 0

    var body: some View {
        VStack {
            // `counter` flows into ChildView as an input — another edge in the graph.
            // When counter changes, SwiftUI walks the edges and knows
            // both ParentView.body and ChildView.body need reevaluation.
            ChildView(label: "You selected (counter)")
            Button("Increment: (counter)") { counter += 1 }
        }
    }
}

struct ChildView: View {
    let label: String  // an input edge from the parent's node
    var body: some View {
        Text(label)
    }
}

struct ParentView: View {
    // This creates a node in the AttributeGraph that holds the Int.
    // ParentView.body has a dependency edge to this node.
    @State private var counter = 0

    var body: some View {
        VStack {
            // `counter` flows into ChildView as an input — another edge in the graph.
            // When counter changes, SwiftUI walks the edges and knows
            // both ParentView.body and ChildView.body need reevaluation.
            ChildView(label: "You selected (counter)")
            Button("Increment: (counter)") { counter += 1 }
        }
    }
}

struct ChildView: View {
    let label: String  // an input edge from the parent's node
    var body: some View {
        Text(label)
    }
}

@State doesn’t store the value in ParentView. ParentView is a struct. A short-lived value type. It gets created, body gets evaluated, and it goes away. The actual counter value persists in the AttributeGraph across those struct lifetimes. The struct dies, the node in the graph doesn’t.

If you’ve opened Instruments and looked at the cause and effect graph, you’ve seen a slice of this. That’s the AttributeGraph. The nodes, the edges, the dependency chains. That’s what’s running your app.

In the right sidebar, inside Instruments, you can see more details from the AttributeGraph and follow the updating process.

(A) This is updating an existing view

(B) The source node is a state node from ParentView._counter to

(C) Destination ParentView.body

What happens when you ignore this

This matters the moment you try to initialize @State from a parent value. You have a NavigationSplitView. The sidebar shows a list of users. When someone selects one, the detail pane loads that user’s profile. The detail view needs a userID from the parent to get started.

The natural instinct is to initialize the view model in init and pass the value there:

struct DetailView: View {
    @State private var viewModel: ViewModel

    init(userID: UUID) {
        _viewModel = State(wrappedValue: ViewModel(id: userID))
    }
}

struct DetailView: View {
    @State private var viewModel: ViewModel

    init(userID: UUID) {
        _viewModel = State(wrappedValue: ViewModel(id: userID))
    }
}

It works the first time. You select a user, the detail pane loads. Then you select a different user. The detail pane doesn’t update. It’s still showing the first user.

Why it breaks

Let`s see, how the AttributeGraph looks behind these flow. First the selection is nil and no detail is shown:

Next selecting an item from the sidebar. The AttributeGraph adds a node for the new DetailView and stores the asscoated state with it:

@State creates a node in the AttributeGraph. SwiftUI reads the underscore syntax once. When that view identity is born. After that, the storage lives in the graph.

When the parent passes a new userID, init runs again. _viewModel = State(wrappedValue: ViewModel(id: newUserID)) executes. And SwiftUI throws the new value away. It already has a node for this identity. It doesn’t need a new one.

You now have two sources of truth. The parent knows the selection changed. The child’s view model is still working with the old userID. They’re out of sync.

The fix

Stop trying to re-initialize. React to the change instead. Pass userID as a plain property and let the view model own the response:

struct DetailView: View {
    let userID: UUID
    @State private var viewModel: ViewModel?

    var body: some View {
        UserDetailContent(viewModel: viewModel)
            .task(id: userID) {
                if viewModel == nil {
                    viewModel = ViewModel()
                }
                await viewModel?.load(for: userID)
            }
    }
}

struct DetailView: View {
    let userID: UUID
    @State private var viewModel: ViewModel?

    var body: some View {
        UserDetailContent(viewModel: viewModel)
            .task(id: userID) {
                if viewModel == nil {
                    viewModel = ViewModel()
                }
                await viewModel?.load(for: userID)
            }
    }
}

userID is a plain property. An input edge in the graph. @State holds the view model as a node. .task(id:) fires whenever userID changes, including the first time the view appears. The view model is created once, and load(for:) handles every subsequent change.

The parent owns the selected ID. The view model owns the loaded data. One source of truth on each side.

Going deeper

This example is from chapter 3 of my book, SwiftUI Data Flow. The whole book is built around understanding how the AttributeGraph, view identity, and state ownership actually work. Ao you can reason about your SwiftUI code instead of guessing.

30% off until the end of September.

Read about the AttributeGraph in this post.

The post What is @State actually doing in SwiftUI appeared first on swiftyplace.

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"
    }
}