Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Audit and improve SwiftUI runtime performance from code review and architecture. Use for requests to diagnose slow rendering, janky scrolling, high CPU/memory usage, excessive view updates, or layout thrash in SwiftUI apps, and to provide guidance for user-run Instruments profiling when code review alone is insufficient.
Audit and improve SwiftUI runtime performance from code review and architecture. Use for requests to diagnose slow rendering, janky scrolling, high CPU/memory usage, excessive view updates, or layout thrash in SwiftUI apps, and to provide guidance for user-run Instruments profiling when code review alone is insufficient.
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
Attribution: copied from @Dimillianβs Dimillian/Skills (2025-12-31).
Audit SwiftUI view performance end-to-end, from instrumentation and baselining to root-cause analysis and concrete remediation steps.
If the user provides code, start with "Code-First Review." If the user only describes symptoms, ask for minimal code/context, then do "Code-First Review." If code review is inconclusive, go to "Guide the User to Profile" and ask for a trace or screenshots.
Collect: Target view/feature code. Data flow: state, environment, observable models. Symptoms and reproduction steps. Focus on: View invalidation storms from broad state changes. Unstable identity in lists (id churn, UUID() per render). Heavy work in body (formatting, sorting, image decoding). Layout thrash (deep stacks, GeometryReader, preference chains). Large images without downsampling or resizing. Over-animated hierarchies (implicit animations on large trees). Provide: Likely root causes with code references. Suggested fixes and refactors. If needed, a minimal repro or instrumentation suggestion.
Explain how to collect data with Instruments: Use the SwiftUI template in Instruments (Release build). Reproduce the exact interaction (scroll, navigation, animation). Capture SwiftUI timeline and Time Profiler. Export or screenshot the relevant lanes and the call tree. Ask for: Trace export or screenshots of SwiftUI lanes + Time Profiler call tree. Device/OS/build configuration.
Prioritize likely SwiftUI culprits: View invalidation storms from broad state changes. Unstable identity in lists (id churn, UUID() per render). Heavy work in body (formatting, sorting, image decoding). Layout thrash (deep stacks, GeometryReader, preference chains). Large images without downsampling or resizing. Over-animated hierarchies (implicit animations on large trees). Summarize findings with evidence from traces/logs.
Apply targeted fixes: Narrow state scope (@State/@Observable closer to leaf views). Stabilize identities for ForEach and lists. Move heavy work out of body (precompute, cache, @State). Use equatable() or value wrappers for expensive subtrees. Downsample images before rendering. Reduce layout complexity or use fixed sizing where possible.
Look for these patterns during code review.
var body: some View { let number = NumberFormatter() // slow allocation let measure = MeasurementFormatter() // slow allocation Text(measure.string(from: .init(value: meters, unit: .meters))) } Prefer cached formatters in a model or a dedicated helper: final class DistanceFormatter { static let shared = DistanceFormatter() let number = NumberFormatter() let measure = MeasurementFormatter() }
var filtered: [Item] { items.filter { $0.isEnabled } // runs on every body eval } Prefer precompute or cache on change: @State private var filtered: [Item] = [] // update filtered when inputs change
List { ForEach(items.sorted(by: sortRule)) { item in Row(item) } } Prefer sort once before view updates: let sortedItems = items.sorted(by: sortRule)
ForEach(items.filter { $0.isEnabled }) { item in Row(item) } Prefer a prefiltered collection with stable identity.
ForEach(items, id: \.self) { item in Row(item) } Avoid id: \.self for non-stable values; use a stable ID.
Image(uiImage: UIImage(data: data)!) Prefer decode/downsample off the main thread and store the result.
@Observable class Model { var items: [Item] = [] } var body: some View { Row(isFavorite: model.items.contains(item)) } Prefer granular view models or per-item state to reduce update fan-out.
Ask the user to re-run the same capture and compare with baseline metrics. Summarize the delta (CPU, frame drops, memory peak) if provided.
Provide: A short metrics table (before/after if available). Top issues (ordered by impact). Proposed fixes with estimated effort.
Add Apple documentation and WWDC resources under references/ as they are supplied by the user. Optimizing SwiftUI performance with Instruments: references/optimizing-swiftui-performance-instruments.md Understanding and improving SwiftUI performance: references/understanding-improving-swiftui-performance.md Understanding hangs in your app: references/understanding-hangs-in-your-app.md Demystify SwiftUI performance (WWDC23): references/demystify-swiftui-performance-wwdc23.md
Workflow acceleration for inboxes, docs, calendars, planning, and execution loops.
Largest current source with strong distribution and engagement signals.