SwiftUI Performance Audit

What it does

SwiftUI Performance Audit organizes an investigation into slow rendering, dropped frames, CPU spikes, memory growth or excessive view updates. It begins with the affected code and data flow, then requests runtime profiling evidence when needed. The central distinction is between a plausible code smell and a measured cause: a suspicious body implementation is a lead, not proof of a bottleneck.

When to use it

• A photo list scrolls unevenly when images appear.
• A change to shared observable state causes unrelated screens to update.
• An interaction hangs on device but appears acceptable in the simulator.

Step-by-step workflow

1. Record the symptom, exact reproduction, device, OS and Debug/Release configuration. Obtain the target view and state/model flow.
2. Review observation scope, list identity, expensive work in body, layout chains, main-thread image work and broad animations.
3. Prioritize likely causes with code references. Request a minimal reproduction or profiling evidence when inspection cannot resolve uncertainty.
4. Use SwiftUI timeline and Time Profiler evidence to distinguish invalidation, layout, CPU or image costs. State where the trace is insufficient.
5. Apply a targeted change and repeat the same scenario. Compare measured results under matching device and build conditions.

Example request

Use swiftui-performance-audit on our photo list. It drops frames while scrolling 500 items on an iPhone in Release. Review PhotoList.swift and PhotoStore.swift for identity churn, broad observation and image decoding on the main thread. Separate suspicions from measured findings. If traces are needed, specify exactly what to capture. After a focused fix, compare the same scroll scenario.

Worked example

If every row observes a large shared model, unrelated state changes may trigger broad updates. Narrowing dependencies is a possible remedy, but first confirm that update work explains the observed delay. If image decoding dominates the trace, changing state structure alone may produce little improvement. The audit should follow the evidence rather than apply every available optimization.

What you get

Prioritized findings, focused remediation and validation steps; before/after metrics when available.

How to evaluate the result

• Expect prioritized findings, code locations, proposed remediation and a repeatable validation scenario. Before/after numbers require actual measurements.
• Keep device, dataset, build mode and interaction consistent. Simulator behavior can differ from physical hardware.
• Verify correctness after optimization: stable list identity, updated content and expected animations must survive the change.

What you need

Relevant SwiftUI code, reproduction steps and device/build information. Instruments or trace captures may be needed.

Setup and activation

This skill is part of the build-ios-apps plugin in openai/plugins. Use the plugin workflow supported by your Codex client, then request the skill by name. Preserve companion references and required tool integrations. The repository describes plugin manifests and marketplace metadata; it does not establish one universal installation command for every Codex environment. This page installs nothing. Before local installation, review and security-scan the exact source/version; catalogue inclusion is not security approval.

Limits and considerations

Do not use code inspection to claim a percentage speedup. This is SwiftUI-specific guidance, not an Android or web profiler. Useful runtime analysis may require macOS, Xcode Instruments and access to the affected build/device.

Related workflows

• Use app-specific tests to protect behavior while changing state flow.
• Repeat profiling after the fix instead of treating fewer lines of code as evidence of speed.

License and reuse

Check the plugin and repository license terms.

Further reading

• Publisher setup and repository README