The AttributeGraph – The Engine Behind Every SwiftUI View

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.

Where @State Actually Lives

When you write:

@State private var name = ""

@State private var name = ""

@State is a property wrapper. Inside it, there’s a reference — Apple calls it a _location — that points to an attribute in the graph. The actual value lives there. I highlighted the state attribute as blue in the above infographic.

Here’s what happens step by step when SwiftUI encounters your view for the first time:

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

The struct is disposable. The state attribute in the graph is the source of truth.

Single Source of Truth: A Graph Topology

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.

Identity: How the Graph Knows “Which” View You Mean

The graph needs a way to match your view struct to the right attribute. It does this through Identity.

There are two kinds:

Structural Identity

This is the default. SwiftUI uses your view’s position in the code to identify it.

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

Each Text has a different identity because it’s at a different position in the VStack. SwiftUI uses this position as the key to look up attributes in the graph.

This is also why if/else branches create different identities:

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

HomeView and LoginView have completely different identities. They have completely different attributes in the graph. When isLoggedIn flips from false to true, the graph destroys all attributes for LoginView and creates new ones for HomeView.

Explicit Identity

You provide this with .id() or ForEach.

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

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

Each RowView is identified by item.id. If you remove an item from the array, the graph destroys the attributes for that identity. If you add a new item, new attributes are created.

And here’s the power move:

ChildView()
    .id(someValue)

ChildView()
    .id(someValue)

When someValue changes, SwiftUI treats this as a completely new view. The old attributes are destroyed. New ones are created with fresh initial values. This is your manual “reset state” button.