swiftui-performance-audit

SwiftUI Performance Audit

Overview

Audit SwiftUI view performance from instrumentation and baselining to root-cause analysis and concrete remediation steps.

Workflow Decision Tree

1. If user provides code: Start with Code-First Review
2. If user only describes symptoms: Ask for minimal code/context, then Code-First Review
3. If code review is inconclusive: Guide user to profile with Instruments

1. Code-First Review

Collect

• Target view/feature code
• Data flow: state, environment, observable models
• Symptoms and reproduction steps

Focus On

• View invalidation storms from broad state changes
• Unstable identity in lists (id churn, UUID() per render)
• Heavy work in body (formatting, sorting, image decoding)
• Layout thrash (deep stacks, GeometryReader, preference chains)
• Large images without downsampling
• Over-animated hierarchies (implicit animations on large trees)
• Non-lazy containers (VStack/HStack) holding large collections instead of LazyVStack/LazyHStack
• Async work in .task without relying on its automatic cancellation when the view disappears
• Closures that may run off the main thread (Shape.path(in:), visualEffect, Layout protocol methods, onGeometryChange) touching @MainActor state directly instead of capturing values

Provide

• Likely root causes with code references
• Suggested fixes and refactors
• Minimal repro or instrumentation suggestion if needed

2. Guide User to Profile

Before reaching for Instruments, a cheaper first step: ask the user to add Self._printChanges() (prints to stdout) or Self._logChanges() (iOS 17+, logs to the com.apple.SwiftUI subsystem under "Changed Body Properties") as the first line of the suspect view's body. Both print @self when the view value itself changed and @identity when the view's persistent data was recycled -- this often narrows down the offending state before a trace is needed. Remove these calls before shipping.

If code review is inconclusive, explain how to collect data: