# IOS Ettrace Performance

Use when capturing or analyzing ETTrace profiles for a focused iOS launch or runtime...

- Repository: https://github.com/dpearson2699/swift-ios-skills (1266 stars)
- Category: Testing
- License: see repository
- Last updated: 2026-07-31
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add dpearson2699/swift-ios-skills --skill ios-ettrace-performance -g -a claude-code -y`
Codex: `npx skills add dpearson2699/swift-ios-skills --skill ios-ettrace-performance -g -a codex -y`
Cursor: `npx skills add dpearson2699/swift-ios-skills --skill ios-ettrace-performance -g -a cursor -y`
Gemini CLI: `npx skills add dpearson2699/swift-ios-skills --skill ios-ettrace-performance -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add dpearson2699/swift-ios-skills`

## Description

Use when capturing or analyzing ETTrace profiles for a focused iOS launch or runtime flow, including exact-build dSYM UUID matching, Simulator or device capture, processed per-thread flamegraph JSON, sampled inclusive/exclusive time, unresolved symbols, and comparable verification. Use debugging-instruments or swiftui-performance for generic profiling instead.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# iOS ETTrace Performance

Use ETTrace for a bounded, symbolicated sampling experiment. Treat capture
conditions and symbolication as part of the evidence, not as setup trivia.

## Contents

- [Boundary](#boundary)
- [Capture Contract](#capture-contract)
- [Workflow](#workflow)
- [Interpret the Report](#interpret-the-report)
- [Common Mistakes](#common-mistakes)
- [Review Checklist](#review-checklist)
- [References](#references)

## Boundary

This skill owns ETTrace framework/CLI capture, exact-build dSYMs, processed
flamegraph JSON, and like-for-like verification. Use Instruments for broad CPU,
hitch, energy, or concurrency triage. Use SwiftUI performance guidance for view
identity, invalidation, and layout remediation.

ETTrace periodically samples thread stacks. Its durations reconstruct sampled
attribution from those intervals; do not present them as wall-clock production
timings or compare them directly with a differently configured profiler.

## Capture Contract

Write these down before capturing:

- one exact user flow and its start/stop boundary;
- launch capture or already-running runtime capture;
- app commit, build configuration, optimization settings, and architecture;
- ETTrace runner and framework versions, plus single-thread or multi-thread mode;
- simulator/device model and OS build;
- launch method, data state, cache state, and repetition count.

Reject a before/after claim when any of these materially differ. Rebuild and
repeat under one contract instead.

## Workflow

### 1. Triage before instrumenting

Confirm that ETTrace's sampled flamechart is the right next tool. Prefer
Instruments first when the slow interval is unknown, spans many subsystems, or
needs system-level blocking, I/O, hitch, or concurrency context.

Choose one flow small enough to repeat. Launch, first screen construction,
opening one document, or applying one edit are useful boundaries; "use the app"
is not.

### 2. Record and hold ETTrace versions fixed

The rest: https://github.com/dpearson2699/swift-ios-skills/blob/HEAD/skills/ios-ettrace-performance/SKILL.md