swiftui-performance

intent

diagnose and fix swiftui rendering performance problems end-to-end. use this skill when a user reports janky scrolling, high cpu usage, excessive view updates, slow animations, memory bloat, or layout thrash. the skill moves from code review through instrumentation profiling to root-cause analysis and concrete fixes, prioritizing by impact.

inputs

required:

• target view or feature code (partial or full)
• symptom description and repro steps (exact interaction: scroll, tap, navigate, animate)
• device/os/xcode version
• build configuration (debug or release; always profile release)

optional but recommended:

• instruments trace export (.trace file) or screenshot of swiftui timeline + time profiler call tree
• baseline metrics (fps, cpu %, memory peak, frame drops)
• data model code and state management patterns (@State, @Observable, @Published)
• environment setup (how data flows into the view)

external connections:

• xcode instruments (local, no auth needed)
• release build on physical device (simulator data is unreliable for performance)

procedure

step 1: code-first review

input: user provides code, symptoms, and repro steps.

action:

1. scan the view hierarchy for the target view/feature.
2. trace state flow: identify @State, @Observable, @Published, @EnvironmentObject, and how they update.
3. check data flow: where does the model live, how does it propagate, what triggers invalidation.
4. look for code smells (see decision points below).
5. if code review reveals a clear culprit, propose a fix and jump to step 4 (remediate).
6. if inconclusive, move to step 2 (profile).

output: summary of likely root causes with code references, or decision to profile.

---

step 2: guide the user to profile

input: code review is inconclusive or user requests data-driven diagnosis.

action:

1. open xcode, plug in a physical device, build in release mode.
2. press cmd+i to launch instruments.
3. select the swiftui template (or custom: add swiftui view body, swiftui view properties, time profiler, hangs instruments).
4. press record, then reproduce the exact interaction (scroll, tap, navigation, animation) for 5-10 seconds.
5. stop recording and let xcode process the trace.
6. inspect swiftui lanes: look for tall stacks or dense blocks indicating heavy body re-evaluations or layout passes.
7. inspect time profiler: identify top functions by self time (expect swiftui internals, layout, rendering).
8. export the trace or take screenshots of both lanes.

output: trace file or screenshot, device/os/build config, metrics (if visible: frame rate, cpu, memory).

---

step 3: analyze and diagnose

input: code and trace (or screenshots), baseline metrics.

action:

1. cross-reference trace with code: find the view or modifier that correlates with the tall stack or cpu spike.
2. prioritize by impact: view invalidation storms are typically the highest cost; layout thrash and image decoding are secondary.
3. check for these culprits in order:
   • view invalidation from broad state changes (a single property change invalidates 10+ views).
   • unstable identity in lists (id churn, uuid() per render, or missing .id()).
   • top-level if/else conditional view swapping (different root view type on each render).
   • heavy work in body (formatters, filtering, sorting, image decoding on main thread).
   • layout thrash (deep nesting, geometryreader inside lazy containers, preference chains).
   • large images without downsampling.
   • over-animated hierarchies (implicit animations on large view trees).
4. estimate impact: if a view re-evaluates 100 times per frame instead of 1, that's a hard blocker.

output: ordered list of issues with evidence (trace reference, code line, estimated impact).

---

step 4: remediate

input: diagnosis from step 3.

action:

1. apply fixes in priority order (highest impact first).
2. for view invalidation: narrow @state and @observable scope to leaf views; split large models into focused ones.
3. for unstable identity: replace id: .self with a stable identifier; avoid uuid() in body or .id().
4. for conditional swapping: use @viewbuilder to preserve structural identity; move if/else into modifiers (e.g., .foregroundStyle(condition ? .yellow : .primary)) instead of branching the view type.
5. for heavy work: precompute and cache (sorting, filtering, formatting); move off main actor (image processing, json parsing, file i/o).
6. for layout: reduce nesting depth; remove geometryreader from lazy containers; use fixed sizing when possible.
7. for images: downsample or resize before rendering; load async, not synchronously in body.
8. for animations: use .animation(:value:) for value-bound changes or .animation(:body:) for modifier-scoped implicit animation; avoid broad implicit animations on large trees.

output: concrete code changes with before/after snippets.

---

step 5: verify

input: user re-runs the same instruments capture after applying fixes.

action:

1. ask the user to re-profile the same interaction on the same device with the same build configuration.
2. compare the trace with the baseline: look for shorter stacks, fewer body re-evaluations, lower cpu, smoother frame rate.
3. if metrics improved, celebrate and ask if there are other symptoms to address.
4. if metrics stayed the same, suspect a different culprit; loop back to step 3 and dig deeper.

output: delta table (before/after cpu %, frame drops, memory peak) and sign-off.

---

decision points

if user provides working code but only a symptom description (e.g., "scrolling is janky"): then ask for repro steps, build config (debug or release), and the exact view code. do not guess. code review without context is unreliable.

if code review finds an obvious culprit (e.g., uuid() in .id(), formatters in body, broad @observable model): then propose a fix immediately and skip profiling. provide a code example and estimated effort. offer to verify later if the user applies the fix.

if code review is inconclusive (code looks reasonable but user reports performance issues): then move to step 2 (profiling). code review alone cannot detect all problems; instrumentation is required.

if the user is profiling a debug build: then stop and ask them to profile a release build on a physical device. debug builds disable optimizations and include runtime overhead, producing misleading data.

if the trace shows a tall stack in swiftui layout or rendering code: then the culprit is likely layout thrash (deep nesting, geometryreader, preference chains) or a large view count. check for lazy container misuse or unstable identity.

if the trace shows many body re-evaluations in a single view: then the culprit is likely broad @observable scope or unstable state dependency. narrow the scope by splitting the model or moving reads into child views.

if the user reports frame drops but cpu is low: then the bottleneck may be memory (gc pauses), gpu rendering (overdraw, blend mode cost), or i/o (image loading blocking the main thread). ask for memory profiling and check for synchronous i/o in body.

if images are large or decoding happens synchronously in body: then decode off the main thread and store the uiimage result. use task.detached or asyncimage.

if a list has no identifiers or uses id: .self on mutable items: then swiftui cannot diff efficiently and rebuilds the entire list on each change. fix by making items identifiable or using a stable id: closure.

if the user is animating non-equatable state: then swiftui cannot determine equality and redraws every frame. conform the state to equatable, then use .animation(_:value:) for simple value-bound changes.

output contract

provide a report with these sections:

1. summary: one-sentence root cause (e.g., "view invalidation from broad @observable model").
2. evidence: trace reference or code line where the problem occurs.
3. top issues: ordered by estimated impact (cpu cost, memory impact, frame drop potential).
4. proposed fixes: concrete code changes with before/after snippets and estimated effort (low: 10min, medium: 1hr, high: 4hr+).
5. metrics table (if baseline data provided):

   metric         | before | after  | delta
   --------------|--------|--------|--------
   cpu (avg)      | 45%    | 12%    | -73%
   frame drops    | 24     | 2      | -92%
   memory peak    | 180mb  | 165mb  | -8%
   body evals/sec | 1200   | 80     | -93%
   

6. review checklist: items the user should verify in their code (no formatters in body, lazy containers used correctly, @observable scope narrow, etc.).

all fixes must include a minimal code example and rationale.

outcome signal

the skill worked if:

• the user understands the root cause (can explain it back to you).
• the proposed fix is concrete and actionable (not vague or speculative).
• the user can verify the fix by re-profiling and comparing metrics.
• frame rate improves, cpu drops, or memory peak decreases after the fix.
• the user's original symptom (janky scrolling, high cpu, etc.) is no longer present or is significantly reduced.

if metrics do not improve after a fix, either the fix addressed a non-critical issue or the diagnosis was incomplete. loop back to profiling and dig deeper.

---

common code smells and fixes

expensive allocations in body

problem: dateformatter(), numberformatter(), measurementformatter() are expensive to create and re-create on every body evaluation.

// DON'T
var body: some View {
    let formatter = NumberFormatter()
    Text(formatter.string(from: 42) ?? "")
}

fix: cache formatters in a static or model property.

// DO
final class AppFormatters {
    static let number = NumberFormatter()
    static let measure = MeasurementFormatter()
}

var body: some View {
    Text(AppFormatters.number.string(from: 42) ?? "")
}

---

unstable identity in lists

problem: id: .self fails for mutable items; uuid() per render destroys and recreates views.

// DON'T
ForEach(items, id: \.self) { item in Row(item) }
ForEach(items) { item in Row(item).id(UUID()) }

fix: use a stable identifier.

// DO
ForEach(items, id: \.id) { item in Row(item) }
// or if items are Identifiable
ForEach(items) { item in Row(item) }

---

filtering and sorting in body

problem: filter and sort run on every body evaluation, not just when data changes.

// DON'T
ForEach(items.filter { $0.isEnabled }.sorted(by: { $0.name < $1.name })) { item in
    Row(item)
}

fix: precompute and cache, then update only when inputs change.

// DO
@State private var filtered: [Item] = []
@State private var sorted: [Item] = []

.onAppear {
    updateFiltered()
}
.onChange(of: items) {
    updateFiltered()
}

private func updateFiltered() {
    filtered = items.filter { $0.isEnabled }
    sorted = filtered.sorted { $0.name < $1.name }
}

var body: some View {
    ForEach(sorted, id: \.id) { item in Row(item) }
}

---

top-level conditional view swapping

problem: if/else at the root of body creates two separate view types, causing identity churn and state reset.

// DON'T
var body: some View {
    if isEditing {
        EditingView(model: model)
    } else {
        ReadOnlyView(model: model)
    }
}

fix: use one stable base view and localize conditions to modifiers or child sections.

// DO: one stable base, conditions in modifiers
var body: some View {
    Form {
        Section {
            TextField("Name", text: $name)
                .disabled(!isEditing)
        }
    }
    .toolbar {
        ToolbarItem {
            Button(isEditing ? "Done" : "Edit") { isEditing.toggle() }
        }
    }
}

---

broad @observable scope

problem: a single @observable model tracks many properties; a view reads all of them, so it re-renders when any change.

// DON'T
@Observable class Profile {
    var name: String = ""
    var email: String = ""
    var avatar: URL?
    var settings: [String: Bool] = [:]
}

struct ProfileView: View {
    let profile: Profile
    var body: some View {
        VStack {
            Text(profile.name)
            Text(profile.email)
            AsyncImage(url: profile.avatar)
            Toggle("Dark Mode", isOn: $settings["darkMode"] ?? false)
        }
    }
}

fix: split into focused child views so each only reads what it needs.

// DO
struct ProfileView: View {
    let profile: Profile
    var body: some View {
        VStack {
            NameRow(profile: profile)
            EmailRow(profile: profile)
            AvatarView(profile: profile)
            SettingsToggle(profile: profile)
        }
    }
}

struct NameRow: View {
    let profile: Profile
    var body: some View {
        Text(profile.name)  // only reads name
    }
}

---

synchronous image decoding

problem: decoding happens on the main thread, blocking render.

// DON'T
let uiImage = UIImage(data: data)!
Image(uiImage: uiImage)

fix: decode off-thread and store the result.

// DO
@State private var image: UIImage?

.onAppear {
    Task.detached {
        let decoded = await decodeImageData(data)
        await MainActor.run {
            self.image = decoded
        }
    }
}

var body: some View {
    if let image {
        Image(uiImage: image)
    }
}

private func decodeImageData(_ data: Data) -> UIImage? {
    return UIImage(data: data)?.resized(to: CGSize(width: 200, height: 200))
}

---

implicit animations on large trees

problem: animating a broad state change triggers implicit animation on every view in the tree, causing jank.

// DON'T
withAnimation {
    isExpanded.toggle()  // animates 100+ subviews
}

fix: use value-bound animation or narrow the modifier scope.

// DO: value-bound animation
@State private var isExpanded = false

var body: some View {
    Section {
        if isExpanded { details }
    }
    .animation(.easeInOut, value: isExpanded)
}

// or scope to a single modifier
var body: some View {
    VStack {
        Button("Toggle") { isExpanded.toggle() }
        if isExpanded {
            details
                .transition(.opacity)
        }
    }
}

---

geometryreader inside lazy containers

problem: geometryreader forces eager measurement and defeats lazy loading.

// DON'T
LazyVStack {
    ForEach(items) { item in
        GeometryReader { geo in
            Row(item: item)
                .frame(height: geo.size.height)
        }
    }
}

fix: move measurement outside the lazy container or use ongeometrychange (ios 16+).

// DO: measure outside
var body: some View {
    GeometryReader { geo in
        LazyVStack {
            ForEach(items) { item in
                Row(item: item)
                    .frame(height: 44)
            }
        }
    }
}

// or use ongeometrychange
LazyVStack {
    ForEach(items) { item in
        Row(item: item)
            .onGeometryChange(
                for: CGSize.self,
                of: { $0.size },
                action: { size in
                    itemHeights[item.id] = size.height
                }
            )
    }
}

---

computed properties that do heavy work

problem: computed properties re-evaluate on every body call.

// DON'T
var filtered: [Item] {
    items.filter { $0.isEnabled }  // runs every time body is called
}

var body: some View {
    List(filtered) { item in Row(item) }
}

fix: use @state and update on change.

// DO
@State private var filtered: [Item] = []

.onAppear {
    updateFiltered()
}
.onChange(of: items) {
    updateFiltered()
}

private func updateFiltered() {
    filtered = items.filter { $0.isEnabled }
}

var body: some View {
    List(filtered) { item in Row(item) }
}

---

anyview erases identity

problem: anyview destroys type identity and forces inefficient diffing.

// DON'T
func makeView(for item: Item) -> AnyView {
    if item.isPremium {
        return AnyView(PremiumRow(item: item))
    } else {
        return AnyView(StandardRow(item: item))
    }
}

fix: use @viewbuilder to preserve structural identity.

// DO
@ViewBuilder
func makeView(for