ios-memgraph-analysis

# iOS Memgraph Analysis

Use memory graphs to prove why memory survives a defined lifetime boundary.
Separate unreachable leaks from reachable growth, preserve raw tool output, and
verify the same app-owned type and ownership path after a fix.

## Contents

- [Boundary](#boundary)
- [Evidence Model](#evidence-model)
- [Workflow](#workflow)
- [Ownership Decisions](#ownership-decisions)
- [Common Mistakes](#common-mistakes)
- [Review Checklist](#review-checklist)
- [References](#references)

## Boundary

This skill owns `.memgraph` capture and command-line ownership/growth analysis.
Use the Memory Graph Debugger or Instruments when their interactive graph and
allocation timeline are the primary task. Use source review for a suspected
closure capture only after runtime evidence identifies the lifetime or path.

## Evidence Model

Do not collapse these conditions:

- **Unreachable leak:** allocated memory no longer has a path from a live root.
  An isolated strong cycle can be unreachable and still consume memory.
- **Reachable but abandoned state:** a live root still retains objects the user
  flow no longer needs. `leaks` may correctly report zero.
- **Expected cache or pool:** memory survives intentionally and must be judged by
  its bound, eviction behavior, and pressure response.
- **Heap regression or fragmentation:** footprint grows because more/larger
  allocations persist or dirty pages are poorly utilized, without a leak.

Apple's leak scanner uses conservative pointer discovery and incomplete type
metadata. Counts can fluctuate, and a zero result does not prove the absence of
an ownership bug. Strong evidence identifies the expected lifetime, an
app-owned type or allocation, and a credible path or isolated reproduction.

## Workflow

### 1. Define the lifetime before capturing

Name the object that should disappear and the event that ends its useful life.
For example: `EditorViewModel` should deinitialize after dismissing the editor
and completing pending save work.

Record one deterministic sequence:

1. launch or restore a known state;
2. take an optional baseline graph;
3. perform the feature flow;
4. cross the expected release boundary;
5. wait for legitimate asynchronous cleanup;
6. take the post-flow graph.

Keep build, simulator/device, data, Malloc Stack Logging setting, and repetition
count stable. Malloc Stack Logging adds valuable allocation backtraces but also
overhead; compare only runs with the same setting.

### 2. Capture a graph without guessing the process

Xcode can export a graph from the Memory Graph Debugger. For a running Simulator
app, use the helper from this skill:

```bash
mkdir -p /tmp/myapp-memory
mkdir /tmp/myapp-memory/run-01
python3 scripts/capture_sim_memgraph.py \
  --bundle-id com.example.MyApp \
  --output-dir /tmp/myapp-memory/run-01 \
  --pretty > /tmp/myapp-memory/run-01/capture.json
```

The per-run `mkdir` must fail if the capture directory already exists. Use a
new run name rather than mixing stale evidence with a retry.

Pass `--udid` when more than one Simulator is booted. The helper accepts only
one exact launchd label and PID; zero or multiple matches are errors. It runs the
host `leaks --outputGraph` command, retains stdout/stderr, and writes a manifest.
Do not replace this with `pgrep | head -1` or a substring match.

Capturing suspends the process. Do not use capture latency as performance data.

### 3. Preserve raw output and build a bounded summary

```bash
MEMGRAPH=$(jq -er \
  'select(.status == "captured") | .memgraph | select(type == "string" and length > 0)' \
  /tmp/myapp-memory/run-01/capture.json)
test -s "$MEMGRAPH"
python3 scripts/summarize_memgraph.py \
  "$MEMGRAPH" \
  --artifact-dir /tmp/myapp-memory/run-01/analysis-raw \
  --app-image 'MyApp|MyFeatureKit' \
  --trace-limit 3 --group-by-type --pretty \
  > /tmp/myapp-memory/run-01/analysis.json
```

Read the exact graph path from the preserved capture report; do not guess a
timestamped filename. The helper creates a dedicated raw-artifact directory,
refuses to reuse it, runs `leaks --list`, and parses only a conservative subset
of its text. `--app-image` marks candidate rows; it does not prove ownership.
`--trace-limit` runs bounded
`leaks --traceTree=<address>` queries. Add `--reference-tree` when aggregate
root paths are more useful than individual leaked addresses. With
`--group-by-type`, that reference-tree query is grouped in the same invocation.
Exit statuses 0 and 1 from `leaks` remain analyzable; a primary status above 1
fails the summary, while optional-query failures are preserved and warned as
unusable without discarding a valid primary summary.

Apple does not publish these text formats as stable machine schemas. Treat
parse warnings as a reason to inspect the raw artifacts, not to loosen the
parser until it emits a desired answer.

### 4. Find the first actionable app-owned edge

Start with an app-owned leaked type or allocation stack. Inspect:

- the leak's object graph and Malloc Stack Logging backtrace, when present;
- a bounded `--traceTree=<address>` for objects that reference one address;
- `--groupByType` to compress repeated types and reveal a retained payload;
- `--referenceTree` for a top-down view when the responsible address is unclear;
- source code for the first strong edge controlled by the app.

An unreachable self-cycle may have no live root in `traceTree`. Use the grouped
leak graph plus source verification or reduce the behavior to an isolated
reproduction. Never invent a root path that the graph does not contain.

### 5. Investigate growth when `leaks` is empty

Use matching baseline and post-flow graphs, locate the growing region, compare
object types, then trace a suspicious address back to an app-owned edge. The
evidence goal is persistent reachable growth across the same lifetime—not a
lower RSS value or a single large snapshot. Load
[reachable-growth.md](references/reachable-growth.md) only for this empty-leak
branch; it contain