iOS — Identifying Memory Leaks using the Xcode Memory Graph Debugger

Pete Smith
Apr 20, 2017 · 3 min read

Crossposted from

In this short post I describe,

  • What the Xcode memory graph debugger is
  • How to use it, and some tips
  • It’s pros/cons

What is it

TL;DR: In one sentence, the memory graph debugger helps to answer the following question: Why does an object exist in memory?

The Xcode memory graph debugger helps find and fix retain cycles and leaked memory. When activated, it pauses app execution, and displays objects currently on the heap, along with their relationships and what references are keeping them alive.

How to use it

3 quick steps to identifying retain cycles and memory leaks:

  • #1. Opt in to stack logging integration via the Xcode scheme editor, as follows:

Note that we only enable logging of ‘Live Allocations’. This has a lower overhead than ‘All Allocations’ when debugging, and is all we need to identify retain cycles and leaks.

  • #2. Perform whatever app actions you want to analyse (the actions you suspect are causing retain cycles and leaks), and enter memory graph debugging mode by selecting its debug bar button:
  • #3. The memory graph debugger pauses app execution and displays the following:

On the left, the debug navigator displays the app’s heap contents

Selecting a type/instance from the debug navigator shows the instances references in the centre pane

Selecting an instance in the centre reference pane displays general object memory information and the allocation backtrace in the right-hand inspector pane

Leaks are displayed in the debug navigator as follows:


  • #1. To help identify memory leaks, we can filter the heap contents to only show leaks using the following:
  • #2: The runtime issue navigator is also useful, displaying the total number of leaks identified:

The good and the bad

  • Good: We can get lucky and find some easy to identify leaks (simple retain cycles). For example — An object capturing itself in a closure property. This is easily fixed using a closure capture list to weakly capture the reference.
  • Bad: False positives (is it a leak?). For example — When creating a UIButton object and adding it to a UIToolBars items array, we have seen it identified as a memory leak but we fail to see why.

That’s it! 📱🚀👍🏽

Zendesk Engineering

Engineering @ Zendesk

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store