- Home
- Skills
- Rshankras
- Claude Code Apple Skills
- Swiftui Debugging
swiftui-debugging_skill
- Swift
56
GitHub Stars
5
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill rshankras/claude-code-apple-skills --skill swiftui-debugging- body-reevaluation.md11.3 KB
- common-pitfalls.md13.0 KB
- lazy-loading.md9.6 KB
- SKILL.md6.2 KB
- view-identity.md7.9 KB
Overview
This skill diagnoses SwiftUI performance problems and guides targeted fixes for unnecessary re-renders, view identity issues, slow body evaluations, and lazy-loading mistakes. It helps you find what is triggering view updates, reduce jank in lists and grids, and apply concrete workarounds for common pitfalls. Use it to systematically narrow performance hotspots and validate fixes with Instruments or signposts.
How this skill works
The skill walks through a decision tree based on observed symptoms (excessive re-renders, choppy scrolling, lost state, or unknown slowness). It recommends lightweight instrumentation (Self._printChanges(), os_signpost) and profiling with the SwiftUI Instruments template to see which bodies and properties change. It then maps findings to concrete fixes: stabilize view identity, restrict observation scope, introduce lazy containers, avoid allocations in body, and prefer efficient APIs.
When to use it
- Views re-rendering too often or unexpectedly
- Scrolling is janky or lists/grids are slow
- A view loses state or unexpectedly animates
- You see expensive body evaluations in Instruments
- You use AnyView, formatters, or objects in body and suspect a cost
Best practices
- Use Self._printChanges() to identify which properties trigger body evaluations
- Split large views into smaller subviews so observation scope is minimized
- Prefer LazyVStack/LazyHStack or List for large collections (50+ items)
- Avoid creating formatters or view models in body; reuse static/shared instances
- Use stable identifiers for .id() (database IDs or UUIDs), never random values or array indices
Example use cases
- Diagnose why a SwiftUI view re-renders when unrelated model fields change
- Fix choppy scrolling caused by eager VStack/ForEach by switching to lazy containers
- Track body evaluation hotspots with Instruments SwiftUI template and os_signpost
- Resolve state loss caused by unstable .id() values or conditional view branching
- Eliminate performance regression from AnyView type erasure or object allocation in body
FAQ
Insert let _ = Self._printChanges() in the view body. The console shows which @self, @identity, or property changed and triggered the re-evaluation.
When should I use LazyVStack vs VStack?
Use LazyVStack for large or unbounded collections or when many cells could be offscreen. A plain VStack evaluates all children eagerly and can cause memory and CPU spikes.
Is AnyView always bad for performance?
AnyView adds type erasure that can defeat SwiftUI diffing. Prefer @ViewBuilder, Group, or explicit generics. Use AnyView only when necessary and measure impact.