ios-performance-profiling

iOS Performance Profiling

Purpose

Use this skill to choose the right profiling workflow, gather evidence, interpret performance signals, and recommend validation before claiming that an optimization worked.

This skill is a profiling router and evidence workflow. It should not replace more specific skills for launch performance, SwiftUI performance, Swift Concurrency performance, perceived performance, or Swift runtime costs.

When to use this skill

Use this skill when the task involves:

• choosing an Instruments template or profiling workflow;
• interpreting traces, screenshots, XCTest metrics, MetricKit payloads, Organizer data, logs, or signposts;
• diagnosing hangs, animation hitches, CPU spikes, memory growth, leaks, disk I/O, network latency, power usage, or production regressions;
• designing a before/after measurement plan;
• adding signposts or performance tests;
• checking whether a proposed optimization is supported by evidence.

When not to use this skill

Do not use this skill as the primary skill for:

• app startup architecture or launch-critical work unless the task asks how to profile, measure, or verify launch performance;
• SwiftUI invalidation, identity, layout, or scrolling fixes unless the task asks which profiling evidence to collect;
• Swift Concurrency design or actor isolation unless the task asks how to profile task behavior, actor hopping, or executor-related latency;
• perceived performance, loading states, skeletons, optimistic UI, or feedback design unless the task asks how to validate perceived latency;
• Swift runtime, ARC, allocation, existential, generic, dispatch, or linking costs unless the task asks how to measure them.

Prefer the more specific skill when the user already knows the domain and needs a fix rather than a measurement workflow.

Core principle

Evidence before optimization.

Use this loop:

Symptom -> reproducible scenario -> correct tool -> trace or metric -> hypothesis -> focused fix -> re-measure