debugging-instruments
Debug iOS apps and profile performance using LLDB, the interactive Memory Graph Debugger, and Instruments. Use for crashes, retain-cycle inspection, hangs, build failures, and generic CPU, memory, energy, or network profiling. Use ios-memgraph-analysis for .memgraph capture, leaks CLI ownership paths, or persistent heap growth; use ios-ettrace-performance for ETTrace capture and JSON.
Profile →npx skills add dpearson2699/swift-ios-skills --skill debugging-instruments --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Debugging and Instruments Keep interactive graph and Instruments triage here. Route detailed `.memgraph` command-line ownership/growth analysis and ETTrace work to their focused skills. ## Contents - [LLDB Debugging](#lldb-debugging) - [Memory Debugging](#memory-debugging) - [Hang Diagnostics](#hang-diagnostics) - [Build Failure Triage](#build-failure-triage) - [Instruments Overview](#instruments-overview) - [Common Mistakes](#common-mistakes) - [Review Checklist](#review-checklist) - [References](#references) ## LLDB Debugging Start with a small, repeatable workflow: 1. Reproduce in a Debug build and stop at the narrowest useful breakpoint. 2. Inspect locals without executing code, then capture the current stack. 3. Move to the relevant frame or thread and verify the failing state. 4. Add a condition or watchpoint only when the bad transition is still unclear. ```text (lldb) br set -f ViewModel.swift -l 42 # Stop at file and line (lldb) v myLocal # Inspect without executing code (lldb) po myObject # Use debugDescription when needed (lldb) bt all # Capture every thread's backtrace (lldb) frame select 3 # Inspect a relevant frame (lldb) br modify 1 -c "count > 10" # Narrow a noisy
- Contents
- LLDB Debugging
- Memory Debugging
- Memory Graph Debugger Workflow
- Common Retain Cycle Patterns
- Instruments: Allocations and Leaks
- Malloc Stack Logging
- Hang Diagnostics
- Identifying Main Thread Hangs
- Using the Time Profiler
- Common Hang Causes
- Build Failure Triage
- Reading Compiler Diagnostics
- SPM Dependency Resolution
Inspect an exported memory graph from Xcode or Instruments leaks MyApp.memgraph Record a trace from the command line xcrun xctrace record --device "My iPhone" \ Export trace data as XML for automated analysis xcrun xctrace export --input profile.trace --xpath '/trace-toc/run/data/table' List available templates xcrun xctrace list templates List connected devices xcrun xctrace list devices
What does the debugging-instruments skill do?
Debug iOS apps and profile performance using LLDB, the interactive Memory Graph Debugger, and Instruments. Use for crashes, retain-cycle inspection, hangs, build failures, and generic CPU, memory, energy, or network profiling. Use ios-memgraph-analysis for .memgraph capture, leaks CLI ownership paths, or persistent heap growth; use ios-ettrace-performance for ETTrace capture and JSON.
How do I install it?
Run `npx skills add dpearson2699/swift-ios-skills --skill debugging-instruments --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From dpearson2699/swift-ios-skills, a repository with 963 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.