Refine SwiftUI Code with Best Practices
A skill for writing, reviewing, and refactoring SwiftUI code - state management, performance, animations, and Instruments profiling.
Why it matters
Elevate your SwiftUI development by ensuring adherence to the latest best practices in state management, view composition, performance, and accessibility. This skill provides a fact-based guidance layer for building, reviewing, and refactoring SwiftUI code.
Outcomes
What it gets done
Review existing SwiftUI code for deprecated APIs and incorrect property wrapper usage.
Improve code by refactoring for optimal state management and view composition.
Implement new SwiftUI features following Apple's design guidance and performance patterns.
Ensure accessibility and iOS 26+ Liquid Glass adoption are correctly handled.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-swiftui-expert-skill | bash Overview
SwiftUI Expert Skill
SwiftUI Expert Skill covers writing, reviewing, and refactoring SwiftUI code - state management, view composition, animations, accessibility - plus a distinctive Instruments trace recording/analysis workflow to diagnose performance issues, governed by an explicit correctness checklist. Use it when writing, reviewing, or performance-debugging SwiftUI code on iOS or macOS; it deliberately does not enforce a specific app architecture and only adopts Liquid Glass when explicitly requested.
What it does
SwiftUI Expert Skill covers writing, reviewing, or refactoring SwiftUI code for iOS or macOS - state management and @Observable data flow, view composition and invalidation/performance, lists and ForEach identity, environment usage, localization, animations, and Liquid Glass (iOS 26+) adoption. It operates under explicit rules: consult a deprecated-to-modern API reference at the start of every task, prefer native SwiftUI over UIKit/AppKit bridging unless necessary, focus on correctness and performance without enforcing a specific architecture (MVVM, VIPER, etc.), only adopt Liquid Glass when the user explicitly requests it, and gate version-specific APIs with #available plus sensible fallbacks.
It defines distinct workflows for reviewing existing code (flag deprecated APIs, validate #available gating for iOS 26+ features), improving existing code (replace deprecated APIs, refactor hot paths to reduce unnecessary state updates, extract complex view bodies into subviews), and implementing new features (design data flow first by identifying owned vs. injected state, structure views for optimal diffing, apply correct animation patterns, use accessible Button elements).
A distinctive capability is Instruments trace recording and analysis: it can record a new .trace session via a record_trace.py script (choosing the SwiftUI template on real devices, falling back to Time Profiler on the Simulator where the SwiftUI lane is empty, and supporting a stop-file for agent-driven sessions), then analyze an existing trace via analyze_trace.py - scoping to a time window via log messages or os_signpost intervals, checking main_running_coverage_pct to distinguish blocked (<25%) from CPU-bound (≥75%) work, using swiftui-causes.top_sources to find structural invalidation bugs (like a wide EnvironmentWriter or UserDefaultObserver.send()), and using --fanin-for to find what's driving updates to a specific expensive view - before returning a prioritized, evidence-cited plan.
A topic router maps 25+ specific areas (state management, view structure, performance, list patterns, layout, sheets/navigation, scroll, focus, three tiers of animation, accessibility, Swift Charts, image optimization, Liquid Glass, macOS scenes/window styling/views, text patterns, localization, previews) to dedicated reference files. A correctness checklist enumerates hard rules that are always bugs when violated: @State must be private, @Binding only for child-modifies-parent state, passed values never declared @State/@StateObject, @StateObject for view-owned vs @ObservedObject/@Bindable for injected objects, ForEach must use stable identity (never .indices/\.offset), constant view count per ForEach element, no closures in custom @Environment/@FocusedValue keys, stable @Entry defaults, .animation(_:value:) must include the value parameter, private @FocusState, and self-contained previews with no live-service dependency.
When to use - and when NOT to
Use this skill when writing, reviewing, or refactoring SwiftUI code on iOS or macOS - state management design, performance investigation (including recording and analyzing Instruments traces), animation implementation, accessibility, or Liquid Glass adoption.
Do not use it to enforce a specific app architecture (it explicitly declines to mandate MVVM/VIPER/etc.) or to adopt Liquid Glass without the user explicitly asking for it. Its guidance and generated code still require environment-specific testing, security review, and user approval before destructive or costly changes are applied.
Inputs and outputs
Input: SwiftUI source code to review/refactor/implement, or an Instruments .trace file to analyze.
Output: reviewed/refactored code following the correctness checklist, or a trace analysis workflow, for example:
python3 "${SKILL_DIR}/scripts/analyze_trace.py" --trace <path> \
--json-only --top 10 [--window START_MS:END_MS]
Along with this it produces prioritized performance recommendations citing specific evidence (coverage percentage, hot symbols, cause-graph edges) routed to the relevant topic reference.
Who it's for
iOS/macOS developers writing or maintaining SwiftUI applications who need rigorous state-management and performance correctness, plus Instruments-driven performance debugging, rather than generic SwiftUI tips.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.