Swiftui Performance

SwiftUI Performance

Purpose

Use this skill to review and refactor SwiftUI code with a performance-first mental model focused on change locality.

SwiftUI performance work should explain which change invalidates which part of the UI, why that work matters, and how to keep updates local.

Scope

Use this skill for:

• SwiftUI screen, list, row, layout, drawing, animation, and lifecycle reviews
• targeted refactors that reduce unnecessary updates or rendering work
• profiling plans only when they validate a SwiftUI performance hypothesis

Do not use this skill for:

• UIKit-only performance problems
• app launch performance unless the issue is inside SwiftUI root view or scene construction
• networking, backend latency, database performance, or caching unless they affect SwiftUI updates
• generic Instruments walkthroughs without a SwiftUI code path
• broad architecture rewrites without a concrete SwiftUI performance risk

Core Model

Answer three questions first:

1. What changed?
2. Which views depend on that change?
3. How much UI work happens because of it?

Then inspect:

• Identity: does SwiftUI preserve the same logical view across updates?
• Lifetime: is state owned by the smallest stable component that needs it?
• Dependencies: does each view read only the data it needs to render?
• Rendering: is body cheap, predictable, and free from heavy transformation work?
• Lifecycle: is async work tied to .task, .onAppear, or explicit actions rather than started from body?

A SwiftUI view is a value description of UI. Do not treat it as a long-lived UIKit-style object.

Review Workflow

Inspect the smallest relevant code path before suggesting broad changes.

Check in this order:

1. Stable and intentional identity.
2. Expensive work in body.
3. Broad state or model reads.
4. State ownership and lifetime.
5. List, row, and pagination structure.
6. Closure-heavy inputs, custom bindings, and unnecessary type erasure.
7. Layout, drawing, and animation cost in repeated content.
8. Async lifecycle, cancellation, and main-actor work.
9. Profiling or debug probes when confirmation is useful.

Prefer targeted refactors over architectural rewrites.

Evidence Rule

Always separate:

• static code review findings
• likely risks
• hypotheses
• measured results
• user-provided evidence
• tool-generated evidence

Never invent timing numbers or claim profiling results unless the user provided evidence or a profiling command was actually run.

Prefer:

This parent view reads the whole model, so changes to that model can invalidate a large part of the screen.

Avoid:

This costs 500 ms.

Common Red Flags

Flag these patterns when they appear on an update or scrolling path:

• unstable IDs such as .id(UUID()) or var id: UUID { UUID() }
• index-based identity for mutable collections
• sorting, filtering, grouping, formatting, parsing, decoding, or database reads inside body
• filtering inside ForEach instead of preparing visible rows first
• passing one giant model into every child view
• broad computed properties that hide many state reads
• AnyView in large repeated collections
• custom Binding(get:set:) when a key-path binding would work
• many stored non-visual closures in row views
• GeometryReader, preferences, heavy shadows, masks, blurs, or overlays in every row
• async work started directly from body
• unguarded .onAppear pagination triggers inside rows