ios-ettrace-performance
Skill2 starsChanged 6 months agoMITView on GitHub
Capture and interpret ETTrace profiles for iOS simulator apps, including symbolicated launch and runtime flamegraphs. Use when asked to profile an iOS app flow, gather simulator performance traces, identify CPU-heavy stacks, compare before/after traces, or produce flamegraph evidence for startup, scrolling, navigation, rendering, or other user-visible latency.
- Deletes or force-pushes
- Installs packages
6 other projects use a version of this, 5 of them edited.
Adopted by
Most recently taken up by
- MMACABRE/SKILLSedited, first seen Nov 8, 2026
- openai/pluginsedited, first seen Oct 13, 2026
- thienqo/ios-skillstheir own version, first seen Oct 11, 2026
- tarunyadav1/ios-app-lifecycleedited, first seen Oct 8, 2026
- omarshahine/HomeClawedited, first seen Sep 29, 2026
- robinebers/skillsedited, first seen Jun 25, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 5
- openai/plugins★ 7.8k95% same
- omarshahine/HomeClaw★ 19197% same
- robinebers/skills★ 4896% same
- MMACABRE/SKILLS★ 195% same
- tarunyadav1/ios-app-lifecycle★ 195% same
Wrote their own version · 1
- thienqo/ios-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- ios-app-intentsSkill
- ios-debugger-agentSkill
- ios-memgraph-leaksSkill
- swiftui-liquid-glassSkill
- swiftui-performance-auditSkill
- swiftui-ui-patternsSkill
- swiftui-view-refactorSkill
The file
We split this skill into the rules it gives an agent
11 rules. 7 are common, 0 are distinctive, and 4 are very specific to this project.
7
Common
Most of the 6 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use this skill to capture a focused, symbolicated ETTrace profile from an iOS simulator app.
- Common: line 20
Avoid broad "use the app for a while" captures.
- Common: line 24
Use a writable run folder for each profiling session:
- Very specific: line 49
If none exists, build a simulator-only copy into RUN_DIR from the upstream ETTrace package.
- Common: line 98
Do not draw conclusions from an unsymbolicated flamegraph.
- Common: line 117
Verify important UUIDs before tracing when the report looks suspicious:
- Common: line 124
After ETTrace exits, read its symbolication summary.
- Very specific: line 150
Start from a stable screen, start ETTrace, perform exactly one focused flow, wait until visible work is complete, then stop the runner.
- Very specific: line 183
Start from run-*/summary.txt, then inspect processed JSON directly if needed.
- Common: line 192
before/after deltas only when the same flow was captured with comparable setup
- Common: line 197
Remove temporary ETTrace app wiring when profiling is complete unless the user asked to keep it.
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
iOS ETTrace Performance
Use this skill to capture a focused, symbolicated ETTrace profile from an iOS simulator app. Pair it with ../ios-debugger-agent/SKILL.md when the task also needs simulator build, install, launch, UI driving, logs, or screenshots.
Core Workflow
- Pick one focused flow and write down the expected start and stop points.
- Build the exact simulator app that will be installed and profiled.
- Temporarily link ETTrace into that app target for simulator/debug profiling.
- Collect UUID-matched dSYMs for the app executable and embedded dynamic frameworks.
- Capture one launch or runtime trace.
- Preserve the processed flamegraph JSON immediately after the run.
- Analyze only the processed JSON and report the flow, artifacts, hotspots, and caveats.
Avoid broad "use the app for a while" captures. One trace should correspond to one user-visible flow.
Setup
Use a writable run folder for each profiling session:
if [ -z "${RUN_DIR:-}" ]; then
RUN_DIR="$(mktemp -d "${TMPDIR:-/tmp}/claude-ios-ettrace.XXXXXX")"
fi
mkdir -p "$RUN_DIR"Install the ETTrace runner CLI if it is not already available:
brew install emergetools/homebrew-tap/ettraceettrace is the host-side macOS runner. The app must also link an ETTrace.xcframework for the iOS Simulator architecture.
This workflow is validated for ETTrace v1.1.0 processed output_<thread>.json files with top-level nodes.
Link ETTrace Into The App
Wire ETTrace into the exact app target being profiled. Keep the integration in a clearly temporary patch and remove it when the profiling task is done unless the user explicitly asks to keep it.
Preferred options:
- Reuse an existing simulator-compatible
ETTrace.xcframeworkif the repo already vendors one. - If none exists, build a simulator-only copy into
RUN_DIRfrom the upstream ETTrace package. - Link the framework directly into the app target, not only into tests, resources, data files, or a nested launcher target.
- Confirm launch logs print
Starting ETTrace. - Profile only one ETTrace-instrumented simulator app at a time because simulator mode listens on a fixed localhost port.
Build a simulator framework when needed:
ETTRACE_TAG="${ETTRACE_TAG:-v1.1.0}" # Override to match the installed runner when Homebrew updates.
ETTRACE_SRC="$RUN_DIR/ETTrace-src"
if [ ! -d "$ETTRACE_SRC" ]; then
git clone --depth 1 --branch "$ETTRACE_TAG" https://github.com/EmergeTools/ETTrace "$ETTRACE_SRC"
fi
rm -rf "$RUN_DIR/ETTrace-iphonesimulator.xcarchive" "$RUN_DIR/ETTrace.xcframework"
pushd "$ETTRACE_SRC" >/dev/null
xcodebuild archive \
-scheme ETTrace \
-archivePath "$RUN_DIR/ETTrace-iphonesimulator.xcarchive" \
-sdk iphonesimulator \
-destination 'generic/platform=iOS Simulator' \
BUILD_LIBRARY_FOR_DISTRIBUTION=YES \
INSTALL_PATH='Library/Frameworks' \
SKIP_INSTALL=NO \
CLANG_CXX_LANGUAGE_STANDARD=c++17
xcodebuild -create-xcframework \
-framework "$RUN_DIR/ETTrace-iphonesimulator.xcarchive/Products/Library/Frameworks/ETTrace.framework" \
-output "$RUN_DIR/ETTrace.xcframework"
popd >/dev/nullFor Bazel apps, a temporary import usually looks like:
load("@rules_apple//apple:apple.bzl", "apple_dynamic_xcframework_import")
package(default_visibility = ["//visibility:public"])
apple_dynamic_xcframework_import(
name = "ETTrace",
xcframework_imports = glob(["ETTrace.xcframework/**"]),
)For Xcode projects, temporarily add the simulator ETTrace.xcframework to the app target's Link Binary With Libraries / Embed Frameworks phases for the debug simulator build you are profiling, then remove that wiring after profiling.
Symbolication Gate
Do not draw conclusions from an unsymbolicated flamegraph. Before every capture, prepare a dSYM folder that includes the app dSYM and any embedded first-party dynamic framework dSYMs.
Collect dSYMs after the final build that produced the installed app:
SKILL_DIR="${CLAUDE_PLUGIN_ROOT}/skills/ios-ettrace-performance"
APP="<path-to-built-simulator-App.app>"
DSYMS="$RUN_DIR/dsyms"
"$SKILL_DIR/scripts/collect_ios_dsyms.sh" \
--app "$APP" \
--out-dir "$DSYMS" \
--search-root "$(dirname "$APP")" \
--search-root "$PWD" \
--extra-dsym "$RUN_DIR/ETTrace-iphonesimulator.xcarchive/dSYMs/ETTrace.framework.dSYM"Add --require-framework <FrameworkName> for app-owned dynamic frameworks that must symbolicate; use --require-all-frameworks only when every embedded framework is app-owned or expected to have symbols. If the helper reports a missing required app or framework dSYM, rebuild the exact simulator app with dSYM generation before tracing, or add the build output directory that contains those dSYMs as another --search-root.
Verify important UUIDs before tracing when the report looks suspicious:
dwarfdump --uuid "$APP/$(/usr/libexec/PlistBuddy -c 'Print :CFBundleExecutable' "$APP/Info.plist")"
find "$DSYMS" -maxdepth 1 -type d -name '*.dSYM' -print -exec dwarfdump --uuid {} \;After ETTrace exits, read its symbolication summary. Treat meaningful first-party "have library but no symbol" lines as a failed trace unless they are tiny noise. Unsymbolicated system-framework or ETTrace internal buckets are usually acceptable.
Capture
For launch traces:
cd "$RUN_DIR"
CAPTURE_MARKER="$RUN_DIR/.ettrace-capture-start"
: > "$CAPTURE_MARKER"
find "$RUN_DIR" -maxdepth 1 \( -name 'output.json' -o -name 'output_*.json' \) -delete
ettrace --simulator --launch --verbose --dsyms "$DSYMS"Use --launch only when measuring startup or first render. The first launch connection can force quit the app; relaunch from the simulator home screen rather than Xcode if prompted. For first-launch-after-install traces, temporarily set ETTraceRunAtStartup=YES in the app Info.plist, then run ettrace --simulator and launch from the home screen.
For runtime flow traces:
cd "$RUN_DIR"
CAPTURE_MARKER="$RUN_DIR/.ettrace-capture-start"
: > "$CAPTURE_MARKER"
find "$RUN_DIR" -maxdepth 1 \( -name 'output.json' -o -name 'output_*.json' \) -delete
ettrace --simulator --verbose --dsyms "$DSYMS"Start from a stable screen, start ETTrace, perform exactly one focused flow, wait until visible work is complete, then stop the runner. For wider attribution, add --multi-thread; otherwise start with the main thread.
ettrace is interactive and needs an attached TTY: it records until you stop it from its controlling terminal. Run the capture where you can stop it after the flow — for example, run the ettrace … command yourself in a terminal (in Claude Code, prefix it with ! so its output lands in the session), or start it as a background Bash process and send the stop key to its stdin once the flow is done. Without a TTY the runner can exit before writing a useful trace.
Preserve Outputs
The next ETTrace run can overwrite processed flamegraph files, so preserve fresh output_<thread-id>.json files immediately. Do not analyze a saved output.json; ETTrace also serves a viewer route with that name, and raw emerge-output/output.json files are not the processed flamegraph artifacts this workflow expects.
PRESERVED_DIR="$(mktemp -d "$RUN_DIR/run-$(date +%Y%m%d-%H%M%S).XXXXXX")"
: > "$PRESERVED_DIR/summary.txt"
if [ ! -e "$CAPTURE_MARKER" ]; then
echo "error: capture marker missing; start a fresh ETTrace capture before preserving outputs" >&2
exit 1
fi
find "$RUN_DIR" -maxdepth 1 -name 'output_*.json' -newer "$CAPTURE_MARKER" -print | while IFS= read -r json; do
preserved="$PRESERVED_DIR/${json##*/}"
cp "$json" "$preserved"
{
echo "## ${preserved##*/}"
python3 "$SKILL_DIR/scripts/analyze_flamegraph_json.py" "$preserved"
} >> "$PRESERVED_DIR/summary.txt"
done
if [ ! -s "$PRESERVED_DIR/summary.txt" ]; then
echo "error: no fresh processed ETTrace output JSON found in $RUN_DIR" >&2
exit 1
fiAnalyze only processed output_*.json files in RUN_DIR. Ignore output.json and raw emerge-output/output.json files unless debugging ETTrace itself. If the analyzer rejects the JSON shape, capture again with the Homebrew ETTrace runner and matching app-side ETTrace.xcframework tag instead of trying to interpret the rejected file.
Read The Profile
Start from run-*/summary.txt, then inspect processed JSON directly if needed.
Report:
- exact flow, app build, simulator model/runtime, and run count
- processed flamegraph JSON paths
- top active leaves and inclusive first-party stacks with sample weights or percentages
- whether symbols were complete for app-owned binaries
- caveats such as first-run setup, simulator-only cost, network variance, or low sample count
- before/after deltas only when the same flow was captured with comparable setup
Cleanup
Remove temporary ETTrace app wiring when profiling is complete unless the user asked to keep it. Keep or discard run artifacts based on the active task.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

