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
- Code provided -> Start with Code-First Review
- Only symptoms described -> Ask for code/context, then Code-First Review
- 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:
- Record: Product > Profile, SwiftUI template (Release build)
- Reproduce: Exact interaction (scroll, navigate, animate)
- Capture: SwiftUI timeline + Time Profiler
- 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/@Observablecloser to leaf views) - Stabilize identities for
ForEachand 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.mdreferences/optimizing-swiftui-performance-instruments.mdreferences/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.
More from anyproto/anytype-swift
tests-developer
Smart router to testing patterns and practices. Use when writing unit tests, creating mocks, testing edge cases, or working with Swift Testing and XCTest frameworks.
2localization-developer
Context-aware routing to the Anytype iOS localization system. Use when working with .xcstrings files, Loc constants, hardcoded strings, or user-facing text.
2liquid-glass-developer
Context-aware routing to iOS 26 Liquid Glass implementation patterns. Use when working with glass effects, GlassEffectContainer, morphing transitions, or iOS 26 visual effects.
2ios-dev-guidelines
Context-aware routing to Swift/iOS development patterns, architecture, and best practices. Use when working with .swift files, ViewModels, Coordinators, refactoring, or discussing Swift/SwiftUI patterns.
2swift-concurrency-developer
Expert guidance on Swift concurrency using the Office Building mental model. Use when working with actors, isolation, Sendable, TaskGroups, or fixing concurrency warnings and data race issues.
2swiftui-patterns-developer
SwiftUI view structure, composition, and best practices. Use when refactoring SwiftUI views, organizing view files, or extracting subviews.
2