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
• Evidence Model
• Workflow
• Ownership Decisions
• Common Mistakes
• Review Checklist
• 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