Swift Performance Optimization Skill

Swift Performance Optimization Skill

Optimize from evidence. Preserve behavior, accessibility, data correctness, and lifecycle safety while changing performance characteristics.

Baseline

The copy-ready examples use Xcode 16, Swift 6 language mode with strict concurrency, and iOS 17. Most principles apply to older targets; verify each API against the app's actual minimum. Material from the OS 27 development cycle is beta relative to stable Xcode 26.6 and requires an explicit request, beta labeling, stable fallback, and availability gate.

Measurement workflow

1. Define a user-visible symptom and a reproducible scenario.
2. Record device, OS, build configuration, dataset, thermal state, and network conditions.
3. Measure an optimized Release build on representative hardware. Simulator-only timing is not release evidence.
4. Select the instrument that answers the hypothesis.
5. Save a baseline trace or metric, change one variable, then repeat the same scenario.
6. Confirm that the bottleneck moved and no memory, energy, correctness, or accessibility regression appeared.
7. Add a regression threshold where the workload is stable enough to automate.

Useful tools include:

Symptom	First evidence source
CPU-bound work	Time Profiler; inspect heavy stacks and self time
SwiftUI update cost	SwiftUI instrument plus Time Profiler
Scroll or animation stalls	Animation Hitches, Core Animation, signposts
Growth or leaks	Allocations, Leaks, Memory Graph, memgraphs
Slow launch	App Launch template and launch signposts
Battery or thermal issues	Energy Log and device testing
Field regressions	MetricKit payloads and app-specific telemetry

Use os_signpost or signposter intervals around important operations so traces answer product questions rather than only showing raw symbols.

Lifetime and memory safety

• A capture is a cycle only when the closure is retained along a path back to its owner. Do not add [weak self] mechanically to every closure.
• Use weak when the owner may legitimately disappear before the callback. Use unowned only when the lifetime invariant is proven and documented; a wrong assumption traps.
• Prefer structured async functions over storing completion closures.
• Cancel owned tasks and invalidate repeating timers when the owner stops needing them and during teardown.
• Never use [unowned self] in a repeating timer merely to silence a cycle.