swiftui-performance — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited swiftui-performance (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 2 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Audit SwiftUI view performance from a reproducible symptom to measured remediation. Route animation design to swiftui-animation, production telemetry to metrickit, ownership/leak analysis to ios-memgraph-analysis, navigation behavior to swiftui-navigation, state architecture to swiftui-patterns, and layout construction to swiftui-layout-components.
device, OS, and build configuration.
broad refactor.
Use this triage list for both code and trace analysis:
bodyMap each suspect from the triage list to exact code. Report likely causes with code references, but label them code-backed hypotheses until a trace confirms cost. Propose a minimal repro or measurement when evidence is missing.
Use the SwiftUI Instruments template on a Release build and real device when possible. Reproduce the exact interaction, capturing SwiftUI lanes, Time Profiler, and Hangs/Hitches as relevant. Ask for the trace or screenshots of the lanes and call tree.
Apply the same triage list to trace evidence. Correlate long or frequent SwiftUI updates with the Time Profiler call tree and the reproduced interaction. Separate trace-backed findings from code-backed hypotheses and name the next measurement that would resolve remaining uncertainty.
Apply targeted fixes:
@State/@Observable closer to leaf views).ForEach and lists.body into model-layer precomputation, an explicit derivedvalue updated when its inputs change, a memoized helper, or background processing. Use @State only when the view owns both the value and its update lifecycle; it is not a generic cache for arbitrary computation.
equatable() only when equality is cheaper than recomputing the subtree andthe compared inputs have stable value semantics.
| Smell | Evidence to seek | Targeted fix |
|---|---|---|
Formatter, sort, filter, or decode in body | Long/frequent body updates with matching call-tree cost | Recompute when inputs change; downsample/decode off the main actor |
UUID() or unstable id: \.self | Recreated rows, lost state, excess updates | Use stable model identity |
Root if/else swaps | State reset or update spikes when toggled | Localize conditional content/modifiers when semantics allow |
| Broad model reads | Many unrelated views update together | Pass narrow values or move reads into focused child views |
| Geometry writes during layout | Repeating layout/update cycle | Threshold changes or replace the feedback path with stable layout |
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:
Use the SwiftUI template in Instruments (Cmd+I to profile). Current SwiftUI lanes include Update Groups, Long View Body Updates, Long Representable Updates / Representable Updates, Other Long Updates / Other Updates, and the Cause & Effect Graph. Correlate those with Time Profiler and Hangs/Hitches.
Add Self._printChanges() in debug builds to log which property triggered a view update:
var body: some View {
#if DEBUG
let _ = Self._printChanges() // "MyView: @self, _count changed."
#endif
Text("Count: \(count)")
}See references/optimizing-swiftui-performance-instruments.md for the full profiling workflow.
Identity controls view lifetime and state. Use stable model IDs in repeated content and reserve .id(_:) changes for intentional resets. Prefer @ViewBuilder or generic composition over AnyView in profiled hot rows. Treat root conditional branches as suspects—not automatic defects—when evidence shows state churn or expensive recreation.
Text(title)
.foregroundStyle(isHighlighted ? .yellow : .primary)
ForEach(items) { item in
Row(item: item).id(item.stableID)
}Use lazy containers when profiling shows eager construction, layout, or update work is material; there is no universal item-count threshold. Route grid/list construction choices to swiftui-layout-components.
Guardrails:
onAppear because of prefetching. Do not make onAppear the only setup point for data a row needs to render.onAppear and onDisappear as visibility signals, not lifetime guarantees.ForEach; avoid if branches that make each element produce zero or one row.ForEach element to a constant number of top-level subviews. Wrap row contents in a stable container if needed. Use -LogForEachSlowPath YES while debugging list/table slow paths.Layout before feeding geometry changes back into row state.Observation tracks properties read during view evaluation. Reduce fan-out by passing narrow derived values or moving reads into focused child views.
// Split reads into child views so each tracks only what it renders.
struct ProfileView: View {
let model: ProfileModel
var body: some View {
VStack {
NameRow(model: model) // only tracks name
EmailRow(model: model) // only tracks email
AvatarView(model: model) // only tracks avatar
SettingsForm(model: model) // only tracks settings
}
}
}Cheap computed values can remain derived; expensive transformations need an explicit owner, input set, and refresh trigger. Do not add view models as a performance ritual—measure first and route general state design to swiftui-patterns.
@Observable models into focused ones, or use computed properties/closures to narrow observation scope..onGeometryChange (iOS 16+) with thresholds.Equatable, then use .animation(_:value:) for simple value-bound changes or .animation(_:body:) for narrower modifier-scoped implicit animation.id: or make items Identifiable so SwiftUI can diff efficiently instead of rebuilding the entire list.@State defeats value semantics. Use plain @State with structs.Task.detached for cases where you intentionally break actor inheritance and handle cancellation yourself.DateFormatter/NumberFormatter allocations inside bodyIdentifiable items or explicit id:@Observable models expose only the properties views actually readMainActor (image processing, parsing)onAppear as the only setup point.animation(_:value:) for value-bound changes or .animation(_:body:) for narrower modifier scope@State is not used as an unspecified cache; every derived value has an explicit owner and refresh triggerequatable() is used only when comparison is cheaper than recomputation and inputs have stable value semantics@Observable view models are @MainActor-isolated; types crossing concurrency boundaries are Sendable~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.