Performance Profiling

Use this skill to diagnose Apple app performance issues systematically, pick the right profiling workflow, apply targeted fixes, and verify the change with real measurements.

When to use this skill

• App hangs, stutters, dropped frames, or high CPU usage on an Apple platform app that needs a Time Profiler pass
• Memory leaks, unbounded memory growth, or OOM crashes that need Leaks, Allocations, or the Memory Graph debugger
• Slow cold/warm launch or slow time to first frame that needs App Launch instrument analysis
• Battery drain, thermal throttling, or excess background/network energy use that needs an Energy Log pass
• Pre-release performance audits that need the full Xcode Diagnostics + MetricKit review checklist, or adding os_signpost measurement hooks
• Not for general (non-Apple) web/service performance tuning such as bundle size, API latency, or database query plans — use performance-optimization; not for Unity/Unreal engine frame-capture interpretation — use game-performance-profiler

Decision Tree

Choose the reference file before changing code:

What performance problem are you investigating?

+ App hangs, stutters, dropped frames, slow UI, high CPU
  -> Read references/time-profiler.md

+ High memory, leaks, OOM crashes, growing footprint
  -> Read references/memory-profiling.md

+ Slow cold launch, warm launch, resume, or time to first frame
  -> Read references/launch-optimization.md

+ Battery drain, thermal throttling, background energy, network waste
  -> Read references/energy-diagnostics.md

+ General "app feels slow"
  -> Start with references/time-profiler.md, then references/memory-profiling.md

+ Pre-release performance audit
  -> Read all reference files and use the review checklist below

Quick Reference

Workflow

1. Identify the performance category from the user report, traces, logs, or code path.
2. Read only the matching reference file unless the issue is broad or unclear.
3. Prefer real device profiling with a Release build and representative data.
4. Inspect the code path named by the profile before proposing a fix.
5. Apply the smallest targeted fix that addresses the measured bottleneck.
6. Re-profile or add a repeatable measurement to confirm the improvement.

Profiling Ground Rules

• Profile on device when possible; Simulator uses host CPU and memory.
• Use Release configuration because optimizations can change hot paths.
• Reproduce with representative data, not empty databases or toy assets.
• Close unrelated apps to reduce noise during profiling.
• Keep measurements before and after the fix so the outcome is concrete.
• Add os_signpost markers when a workflow needs ongoing timing visibility.

Xcode Diagnostics

Recommend relevant Scheme > Run > Diagnostics settings when they match the suspected issue:

MetricKit Hook

Suggest MetricKit for production monitoring of launch, responsiveness, memory, and diagnostics:

import MetricKit

final class PerformanceReporter: NSObject, MXMetricManagerSubscriber {
    func startCollecting() {
        MXMetricManager.shared.add(self)
    }

    func didReceive(_ payloads: [MXMetricPayload]) {
        for payload in payloads {
            if let launch = payload.applicationLaunchMetrics {
                log("Resume time: \(launch.histogrammedResumeTime)")
            }
            if let responsiveness = payload.applicationResponsivenessMetrics {
                log("Hang time: \(responsiveness.histogrammedApplicationHangTime)")
            }
            if let memory = payload.memoryMetrics {
                log("Peak memory: \(memory.peakMemoryUsage)")
            }
        }
    }

    func didReceive(_ payloads: [MXDiagnosticPayload]) {
        for payload in payloads {
            if let hangs = payload.hangDiagnostics {
                for hang in hangs {
                    log("Hang: \(hang.callStackTree)")
                }
            }
        }
    }
}

Review Checklist

Responsiveness:

• No synchronous work on the main thread over 100 ms.
• No file I/O or network calls on the main thread.
• Large Core Data or SwiftData fetches use background contexts.
• Images decode off the main thread.
• @MainActor is limited to code that truly needs UI access.

Memory:

• No retain cycles in delegates, closures, observers, or async tasks.
• Large resources are released when no longer visible.
• Collections and caches are bounded.
• autoreleasepool is used in tight loops that create Objective-C objects.

Launch:

• No heavy work in init() of the @main App struct.
• Non-essential initialization is deferred.
• Dynamic frameworks are minimized where practical.
• No synchronous network calls occur during launch.

Energy:

• Background tasks use the appropriate BGTaskScheduler request type.
• Location accuracy matches the product need.
• Timers use tolerance so the system can coalesce wakeups.
• Network requests are batched and cached where possible.

References

• Upstream source: MengTo/Skills — performance-profiling
• references/time-profiler.md: CPU profiling, hang detection, signpost API.
• references/memory-profiling.md: Allocations, Leaks, Memory Graph debugger.
• references/launch-optimization.md: Launch phases and cold/warm start optimization.
• references/energy-diagnostics.md: Battery, thermal state, and network efficiency.
• agents/openai.yaml: OpenAI agent interface metadata (display name, short description, default prompt).