anyproto/swiftui-performance-developer

SwiftUI Performance Developer (Smart Router)

Purpose

Audit SwiftUI view performance through code review and provide guidance for Instruments profiling when needed.

When Auto-Activated

• Diagnosing slow rendering, janky scrolling, high CPU/memory
• Excessive view updates or layout thrash
• Keywords: performance, slow, jank, hitch, laggy, stuttering, CPU, memory, update

Workflow Decision Tree

1. Code provided -> Start with Code-First Review
2. Only symptoms described -> Ask for code/context, then Code-First Review
3. Code review inconclusive -> Guide user to profile with Instruments

Fundamental Performance Insight (WWDC24)

SwiftUI views are value types (structs) that describe UI state - they are NOT long-lived objects. Breaking up one view into multiple subviews doesn't hurt performance because views are just declarative descriptions.

Key insight: SwiftUI maintains an efficient data structure behind the scenes. When state changes, new view values are created and SwiftUI determines what actually needs updating. You don't need to compromise code organization for performance.

// ✅ GOOD - Splitting into subviews is FREE
var body: some View {
    VStack {
        HeaderView(title: title)        // Separate view = fine
        ContentView(items: items)       // Separate view = fine
        FooterView(action: saveAction)  // Separate view = fine
    }
}
// SwiftUI only updates the specific subview when its state changes

Code-First Review Focus

Look for these common performance issues:

State-Driven Updates (WWDC24)

SwiftUI tracks dependencies automatically. Any data a view reads in body becomes a dependency:

@Observable class PetModel {
    var name: String = ""      // ← If read in body, becomes dependency
    var hasAward: Bool = false // ← Only triggers update if actually read
}

struct PetRow: View {
    let pet: PetModel

    var body: some View {
        HStack {
            Text(pet.name)       // Dependency: name
            if pet.hasAward {    // Dependency: hasAward
                Image(systemName: "star.fill")
            }
        }
    }
}
// When pet.hasAward changes, SwiftUI calls body again automatically

Performance benefit: Only views that actually read changed data get updated.

View Invalidation Storms

// BAD - Broad state triggers all views
@Observable class Model {
    var items: [Item] = []
}

// GOOD - Granular per-item state
@Observable class ItemModel {
    var isFavorite: Bool
}

Unstable Identity in Lists

// BAD - id churn causes full re-render
ForEach(items, id: \.self) { item in Row(item) }

// GOOD - Stable identity
ForEach(items, id: \.id) { item in Row(item) }

Heavy Work in body

// BAD - Allocation every render
var body: some View {
    let formatter = NumberFormatter()  // slow
    Text(formatter.string(from: value))
}

// GOOD - Cached formatter
static let formatter = NumberFormatter()
var body: some View {
    Text(Self.formatter.string(from: value))
}

Sorting/Filtering in ForEach

// BAD - Re-sorts every body eval
ForEach(items.sorted(by: sortRule)) { Row($0) }

// GOOD - Pre-sorted collection
let sortedItems = items.sorted(by: sortRule)
ForEach(sortedItems) { Row($0) }

Large Images Without Downsampling

// BAD - Decodes full resolution on main thread
Image(uiImage: UIImage(data: data)!)

// GOOD - Downsample off main thread first

Common Code Smells

| Pattern | Problem | Fix | |---------|---------|-----| | NumberFormatter() in body | Allocation per render | Static cached formatter | | .filter { } in ForEach | Recomputes every render | Pre-filter, cache result | | id: \.self on non-stable values | Identity churn | Use stable ID property | | UUID() per render | New identity every time | Store ID in model | | GeometryReader deep in tree | Layout thrash | Move up or use fixed sizes | | if condition { View } in ForEach | Variable view count forces full build | Use opacity(0) or pre-filter | | AnyView in List rows | Hides identity and view count | Use @ViewBuilder or concrete types |

Instruments Profiling Guidance

When code review is inconclusive, guide user to profile:

1. Record: Product > Profile, SwiftUI template (Release build)
2. Reproduce: Exact interaction (scroll, navigate, animate)
3. Capture: SwiftUI timeline + Time Profiler
4. Analyze:
   • "Long View Body Updates" (orange >500us, red >1000us)
   • "Hitches" lane for frame misses
   • Time Profiler call tree for hot frames

Ask user for:

• Trace export or screenshots
• Device/OS/build configuration

Remediation Checklist

• [ ] Narrow state scope (@State/@Observable closer to leaf views)
• [ ] Stabilize identities for ForEach and lists
• [ ] Move heavy work out of body (precompute, cache, @State)
• [ ] Use equatable() for expensive subtrees
• [ ] Downsample images before rendering
• [ ] Reduce layout complexity or use fixed sizing

References

For detailed WWDC guidance:

• references/demystify-swiftui-performance-wwdc23.md
• references/optimizing-swiftui-performance-instruments.md
• references/understanding-improving-swiftui-performance.md

Related Skills

• ios-dev-guidelines -> General Swift/iOS patterns
• swiftui-patterns-developer -> View structure and composition

---

Navigation: This skill provides SwiftUI performance audit patterns. For general iOS development, see ios-dev-guidelines.

Attribution: Patterns adapted from Dimillian/Skills repository. WWDC24 insights from "SwiftUI Essentials" session.