ios-memgraph-analysis

Capture and analyze iOS Simulator .memgraph files to diagnose memory leaks and heap growth.

1.1k|51|Updated Mar 3, 2026
One-click install
npx skills add https://github.com/dpearson2699/swift-ios-skills --skill ios-memgraph-analysis
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ios-memgraph-analysis
Source: https://github.com/dpearson2699/swift-ios-skills/tree/main/skills/ios-memgraph-analysis
Command: npx skills add https://github.com/dpearson2699/swift-ios-skills --skill ios-memgraph-analysis

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

iOS memory bugs are hard to prove: leaks can report zero while memory keeps growing, and aggregate metrics like RSS or graph size do not identify the responsible ownership path. This Skill provides a rigorous workflow for capturing .memgraph files from a Simulator app, separating unreachable leaks from reachable-but-abandoned growth, and verifying that a fix actually removes the app-owned ownership path.

Core Features & Use Cases

  • Unambiguous Simulator Capture: A helper script resolves exactly one booted Simulator and one exact process by bundle ID, captures a .memgraph via leaks --outputGraph, and preserves raw stdout/stderr plus a JSON manifest.
  • Bounded Evidence Summaries: A second script runs leaks --list, optional --traceTree, --groupByType, and --referenceTree queries, preserving raw output while emitting a conservative JSON summary with app-image matching.
  • Reachable-Growth Workflow: A reference guide covers the empty-leak branch using matched baseline/post-flow graphs with vmmap, heap --diffFrom, heap --addresses, and malloc_history under Malloc Stack Logging.
  • Use Case: An EditorViewModel keeps surviving after the editor is dismissed. Capture baseline and post-dismissal graphs, trace the app-owned strong edge retaining it, apply one ownership fix, then repeat the identical flow to prove the same type and path disappear.

Quick Start

Ask the agent to capture a memgraph of your running Simulator app by bundle ID and analyze it for the ownership path retaining a specific object that should have been released.

Frequently Asked Questions about ios-memgraph-analysis

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I capture a .memgraph from an iOS Simulator app?

Run the capture script with the app's exact bundle ID and an output directory, passing --udid when more than one Simulator is booted. It resolves one exact process via launchctl, runs leaks --outputGraph, and writes the graph plus a JSON manifest and raw output.

What should I do when leaks reports zero but memory keeps growing?

Zero leaks means no unreachable cycles, but reachable abandoned objects can still grow the heap. Capture matched baseline and post-flow graphs, use vmmap -summary to locate the growing region, heap --diffFrom to find new object types, then trace a suspicious address to an app-owned edge.

When should I use this instead of Xcode Memory Graph Debugger or Instruments?

Use this Skill for command-line .memgraph capture and ownership/growth analysis with preserved raw evidence. Use the Memory Graph Debugger or Instruments when the interactive graph view or allocation timeline is the primary task.

Why is a smaller graph file or lower RSS not proof a leak is fixed?

Aggregate metrics like RSS, graph size, and total leak counts do not identify the responsible ownership path. A fix is supported only when the same app-owned type or path disappears, or its attributable pre/post growth is removed, across repeated identical flows.

Does memgraph analysis require Malloc Stack Logging?

Malloc Stack Logging is optional but adds allocation backtraces that help identify where objects were created. It must be set identically on both sides of any comparison, since it adds overhead and changes capture conditions.

What are the limitations of parsing Apple leaks output?

Apple does not publish leaks text output as a stable machine schema, so parsing is best-effort and conservative. Raw command output is always preserved as authoritative, and parse warnings should trigger inspection of the raw artifacts rather than looser parsing.