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:
Enable Malloc stack logging for live allocations

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:
The memory graph debugging button
  • #3. The memory graph debugger pauses app execution and displays the following:
Xcode memory graph debugging mode

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:

Leaks displayed in the debug navigator


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

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

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

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