Skip to content

Performance, memory, energy, launch, and device matrices

Performance work begins with a user-visible budget and a reproducible workload. “Feels fast” and one simulator number are observations, not durable evidence.

Define budgets around journeys

JourneyMeasureEvidence shape
cold launch to usable librarywall time and launch metricrelease build on supported devices
scroll 2,000 noteshitches, frame pacing, allocationsfixed fixture plus Instruments trace
open attachment editorpeak and retained memoryrepeated enter and exit cycle
sync 500 changesduration, bytes, CPU, energycontrolled network profile and signposts

Record device model, OS, app build, data fixture, network profile, thermal state, power state, run count, and variance. Compare like with like.

Use layers of evidence

XCTest performance measures repeatable code or journey metrics and produces result artifacts. Instruments explains CPU, allocation, leaks, hangs, signposts, disk, and network behavior. MetricKit can surface aggregated production diagnostics. Physical devices reveal thermal, energy, radio, storage, and hardware behavior that Simulator cannot prove.

Measure release behavior

Optimization level, diagnostics, logging, database contents, image sizes, and network conditions change results. Keep a small deterministic fixture for regression and a realistic large fixture for capacity. Warm and cold launch answer different questions, so label them separately.

Investigate before optimizing

A budget failure starts a trace and hypothesis. Fix the dominant measured cost, rerun the same matrix, and retain before and after artifacts. Avoid speculative caching that adds invalidation bugs without moving the target metric.

Validation boundary

No performance, memory, energy, launch, Simulator, or device measurements were run for this content-only batch.

Series navigation

References