What performance issues can this skill diagnose?

It diagnoses slow rendering, janky scrolling, high CPU usage, memory growth, hangs, and excessive view updates in SwiftUI by performing a code-first review and, if needed, guiding you through Instruments profiling.

Does this skill require Instruments traces, or does it start with code review?

It starts with code review to identify issues like invalidation storms, unstable list identities, and heavy work in `body`. It only requests Instruments traces or profiling evidence if code review alone cannot explain the symptoms.

What code smells does it look for?

It checks for six categories: invalidation storms from broad observation or environment reads, unstable identity in lists and `ForEach`, heavy derived work computed inside `body`, layout thrash from complex hierarchies, large image decode/resize work on the main thread, and animation/transition work applied too broadly.

What does the final output include?

The audit report includes a before/after metrics table, issues ranked by impact, proposed fixes with estimated effort, and references to profiling checklists, code-smell catalogs, and Apple/WWDC resources on SwiftUI performance.

What inputs do I need to provide?

Provide the target SwiftUI view/feature code, a description of the symptom (e.g., slow rendering, janky scrolling), reproduction steps, and data flow details (`@State`, `@Binding`, observable models). If code review is inconclusive, also provide a profiling trace export or screenshots with device and build configuration.

Skill

Audit SwiftUI Performance Issues

Name: SwiftUI Performance Audit
Availability: OnlineOnly
Author: Antigravity

A code-first SwiftUI performance audit skill diagnosing invalidation storms, layout thrash, and view-update issues before profiling.

Get skill

Antigravity

Own this? Claim it

Spark score

out of 100

Updated last month

Version 1.0.0

Add to Favorites

Why it matters

Diagnose and resolve performance bottlenecks in SwiftUI applications. This skill provides a code-first audit and guides users through profiling with Instruments when necessary.

Outcomes

What it gets done

Classify SwiftUI performance symptoms (rendering, scrolling, CPU, memory).

Perform code-first review for common performance smells.

Guide users on collecting profiling evidence using Instruments.

Analyze performance data and provide remediation strategies.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-swiftui-performance-audit | bash

Overview

SwiftUI Performance Audit

A code-first SwiftUI performance audit skill diagnosing invalidation storms, identity churn, layout thrash, and main-thread work, escalating to Instruments profiling guidance when code review is inconclusive. Use it when slow rendering, janky scrolling, or high CPU is reported in SwiftUI; it starts from code and only requests profiling evidence when code review alone can't explain the symptom.

What it does

This skill diagnoses SwiftUI performance issues starting from code review, escalating to Instruments profiling guidance only when code review alone can't explain the symptoms. It classifies the reported symptom (slow rendering, janky scrolling, high CPU, memory growth, hangs, or excessive view updates), then intakes the target view/feature code, exact reproduction steps, data flow (@State, @Binding, environment dependencies, observable models), and whether the issue appears on device vs simulator and Debug vs Release. The code-first review looks for six categories of code smells: invalidation storms from broad observation or environment reads, unstable identity in lists and ForEach, heavy derived work computed inside body or view builders, layout thrash from complex hierarchies/GeometryReader/preference chains, large image decode or resize work running on the main thread, and animation/transition work applied more broadly than needed. If code review is inconclusive, it guides the user through collecting runtime evidence - a SwiftUI timeline/Time Profiler trace export or screenshots, device/OS/build configuration, the exact interaction profiled, and before/after metrics for comparison - using a dedicated profiling-intake checklist. Analysis maps evidence to the most likely category (invalidation, identity churn, layout thrash, main-thread work, image cost, animation cost), prioritizes by actual impact rather than ease of explanation, and explicitly distinguishes code-level suspicion from trace-backed evidence, calling out when more evidence is still needed. Remediation applies targeted fixes: narrowing state scope to reduce observation fan-out, stabilizing ForEach/list identities, moving heavy work out of body into derived state or memoized/precomputed values (using @State only for genuinely view-owned state, not as an ad hoc computation cache), using .equatable() only when equality checking is cheaper than recomputing and inputs are truly value-semantic, downsampling images before rendering, and reducing layout complexity or using fixed sizing where possible. Verification asks the user to re-run the same capture and compare against baseline metrics. Final output is a short before/after metrics table, issues ranked by impact, and proposed fixes with estimated effort, formatted per a report template. Reference files cover the profiling-intake checklist, a code-smell catalog with Observation-specific fan-out guidance, the report template, and linked Apple/WWDC resources on SwiftUI performance, hangs, and Instruments usage.

When to use - and when NOT to

Use it when a user reports slow rendering, janky scrolling, layout thrash, or high CPU in SwiftUI, or when a code-first audit plus Instruments guidance is needed. It performs a code-first diagnosis and only requests profiling evidence when code review alone cannot explain the symptoms - it does not claim to diagnose performance issues without either code or runtime evidence.

Inputs and outputs

Inputs: the target SwiftUI view/feature code, symptom classification, reproduction steps, and (if code review is inconclusive) a profiling trace export or screenshots with device/build configuration.
Outputs: a prioritized list of likely root causes with code references, targeted remediation suggestions, and a formatted audit report with a before/after metrics table and effort-estimated fixes.

Who it's for

iOS developers diagnosing SwiftUI performance problems (slow rendering, janky scrolling, high CPU, hangs) who want a structured code-first audit before resorting to full Instruments profiling.

FAQ

Common questions

Discussion