Swiftui Performance

# Demystify SwiftUI Performance (WWDC23) (Summary)

Context: WWDC23 session on building a mental model for SwiftUI performance and
triaging hangs, hitches, and excessive update work.

## Contents
- Core mental model
- Dependencies and invalidation
- Expensive body work
- Identity rules for lists and tables
- Initialization and lifecycle pitfalls
- Debugging tools
- Fix patterns
- What to verify after a change

## Core mental model

SwiftUI performance starts with one rule: only work that is required for the
current state should happen for the current frame.

A slow screen usually means one of these is false:

- too much work happens per update
- updates happen too often
- identity is unstable, so SwiftUI redoes work it could have reused

The session's practical loop is:

- Measure
- Identify
- Optimize
- Re-measure

Do not skip the last step. SwiftUI optimizations are easy to misjudge by eye.

## Dependencies and invalidation

A view updates when one of its dependencies changes.

Common dependency sources:

- `@State`
- `@Binding`
- `@Observable` / `@ObservedObject`
- `@Environment`
- container-derived identity (`ForEach`, `List`, `Table`)

The performance goal is not "fewer dependencies" in the abstract. The goal is
**precise dependencies** so only the view that needs to update actually updates.

### Practical implications

- Avoid a row depending on a whole collection if it only needs one element.
- Avoid broad environment-driven updates for fast-changing values.
- Extract subviews when a smaller view can read a smaller state surface.

### Debug-only dependency inspection

`Self._printChanges()` is useful in debug builds when you are not sure why a
view keeps updating.

Use it to answer:

- which property changed?
- which parent view re-rendered?
- is the view reacting to state it should not care about?

Do not treat `_printChanges()` output as a shipping-time profiling tool.

## Expensive body work

View bodies need to stay cheap.

Typical mistakes:

- string formatting in `body`
- array filtering and sorting in `body`
- expensive image work in `body`
- constructing large attributed strings during render
- initializing heavy models in-line with view creation

```swift
// DON'T
var body: some View {
    List(items.filter(shouldShow).sorted(by: sortRule)) { item in
        Text(numberFormatter.string(from: item.value as NSNumber) ?? "")
    }
}

// DO
var body: some View {
    List(viewModel.visibleItems) { item in
        Text(item.formattedValue)
    }
}
```

The winning pattern is precomputation at the model boundary, not clever work in
`body`.

## Identity rules for lists and tables

Identity is one of the biggest hidden performance levers in SwiftUI.

### Stable identity matters

Use stable IDs that survive refreshes and sorting. If identity churns, SwiftUI
cannot reuse rows, preserve animations, or diff efficiently.

### Constant row count matters

Inside `ForEach`, SwiftUI expects a predictable mapping between data elements and
rendered views.

Avoid patterns like:

```swift
ForEach(items) { item in
    if item.isVisible {
        Row(item: item)
    }
}
```

Prefer:

```swift
ForEach(visibleItems) { item in
    Row(item: item)
}
```

### Avoid `AnyView` in hot list rows

Type erasure can hide useful structural information and increase work in large
lists or tables.

### Table-specific note

`TableRow` resolves to a single row. Keep row structure predictable and use the
streamlined `Table` APIs when possible.

## Initialization and lifecycle pitfalls

### Heavy model creation in view init/body

Keep view initialization lightweight. Start async work with `.task` or from a
model object.

```swift
// DON'T
struct DetailView: View {
    let loader = BigLoader() // heavy construction
}

// DO
struct DetailView: View {
    @State private var model: DetailModel?

    var body: some View {
        content
            .task {
                model = await loadDetailModel()
            }
    }
}
```

### Hidden work from compute