(String: {%- set hs_blog_post_body -%} {%- set in_blog_post_body = true -%} <span id="hs_cos_wrapper_post_body" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_rich_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="rich_text"> <div class="blog-post__lead h2"> <p>Leaks and retain cycles are two of the biggest problems for <a href="/services/mobile-development/ios-app-development" rel="noopener">iOS developers</a> when it comes to performance management.&nbsp;</p> </div></span>)

What Are iOS Memory Leaks and How to Detect Them?

Photo of Krzysztof Ziółek

Krzysztof Ziółek

Updated Dec 4, 2023 • 9 min read
iOS Egypt

Leaks and retain cycles are two of the biggest problems for iOS developers when it comes to performance management.

What exactly do these issues look like and, more importantly, how can you detect iOS memory leaks?

iOS memory leaks and retain cycles have the potential to bring huge drawbacks to app optimization, including higher memory consumption, random crashes, and poor overall performance. This is made worse by the fact that memory leaks aren’t always simple issues. They can actually be difficult to track down and solve, especially if you’re working with a large and complex application.

By following our guide, you’ll be able to understand exactly what memory leaks are and how to detect them using Xcode tools.

What is a memory leak?

A memory leak is a piece of memory that was allocated at one point but never released, and is also no longer referenced by your app. This means the memory can’t be used again unless some intervention is applied. To fully understand memory leaks, we first need to explain how memory management works on iOS through the Automatic Reference Counting (ARC) mechanism.

What is memory management on iOS?

ARC works as memory management on iOS by keeping count of the times when an instance is referred to. These references can either be weak or strong, with the counter increasing by one when an instance of the latter is declared. When this instance is released, the counter decreases by one. Therefore, when the counter is at zero, ARC can deallocate it from the memory heap because it is currently not in use. In contrast to this, weak references don’t increase the counter and are automatically released once it is at zero.

Recognizing potential problems with weak and strong references is relatively easy to fix, but can be hard to spot. This is where retain cycles come in.

Retain cycles

Retain cycles occur in ARC when two objects hold strong reference to one another. This means that the first object reference count cannot be zero until the second object is released, but the second object count cannot be released whilst the first object is at zero. This leads to a cycle where each object is needlessly retained because of the inherent count of the other.

Here’s an example of a retain cycle:

Simple retain cycle example

Parent and Child have strong references to each other and can therefore never be deallocated from memory.

How can you detect these memory leaks in an iOS app?

As mentioned in the introduction, there are two main ways to detect memory leaks in iOS using the Instruments app in Xcode and the Analyze functionality.

Using the Xcode Memory Graph tool

To make memory leak detection easier, Apple introduced the Memory Graph debugger in Xcode 9, allowing developers to stop an app from running and gain a snapshot of the current memory state. From there, a list of all the objects being held in the memory heap can be accessed, and selecting an object reveals all of the objects that are referencing it as well as a backtrace of the object.

To be thorough when detecting memory leaks, you should run the app and navigate through all possible flows by opening the same view controllers several times and entering the memory graph debugger to look at the memory heap. From there, you’ll want to identify objects that shouldn’t be present in the memory heap at that time. For example:

  • A view controller that is no longer present in the loop
  • An unusual number of instances of the same object

The memory debugger itself should be able to detect potential memory leaks and show a purple exclamation point beside them, but you should always check whether this is a real memory leak or a false positive.

To activate this, you’ll need to enable a few settings within Xcode. It’s also important to note that you’ll need to disable these same settings once you’ve finished debugging, as they will have negative performance impacts if left enabled all the time.

To do this, first edit the scheme for your app in Xcode:

XCode – how to edit a scheme

Click on ‘Run’ scheme and then select the diagnostics section. There are two settings in this section that need to be enabled. The first is Malloc Scribble in the memory management group:

Enabling Malloc Scribble and Malloc Stack

Enabling Malloc Scribble will fill freed memory with a predefined value that makes it more obvious when memory is leaked. This increases Xcode’s accuracy of identifying leaks.

The second setting to enable is Malloc Stack in the Logging group. Enabling this will allow Xcode to build an allocation backtrace to help you understand where objects are being referenced from.

Click on the Debug Memory Graph button in Xcode’s variables view at the bottom left:

How to view a memory graph in XCode

This loads the application’s memory graph. Next, select the Debug tab in Xcode’s navigator pane on the left to bring up a list of all the objects in memory:

XCode Debug navigator

If you click on one of the instances in the debug navigator, it will present you with a relationship graph. This is extremely helpful in understanding which references are still being held, as well as for tracking down where references are created.

XCode relationship graph

Remember: Xcode is not always 100% accurate in identifying memory leaks. Once you’ve finished debugging, don’t forget to turn off the Malloc Scribble and MallocStackLogging settings in the run scheme for your app otherwise they will negatively affect performance.

Using the Instruments tool

The Instruments tool can be used to diagnose memory leaks during application runtimes. After launching the application, you can see a live preview of how many resources are being consumed on the Allocations line and whether or not any memory leaks have been detected on the Leaks line:

XCode – how to run the Instruments app

XCode Instruments Leaks app
XCode Instruments Leaks app
If leaks are detected, you’ll be provided with detailed information including a stack trace and sometimes (unfortunately not always) a memory graph that visually presents how the retain cycle was created. It should be noted that the app can be used to track the runtime on both the simulator and physical device.

Using the Analyze tool

The Analyze tool is a function in Xcode for statically analyzing code after potential memory leaks. Once the analysis has finished running, the developer is provided with a list of suspicious places in the code.

XCode Analyze tool

XCode Analyze tool

The Memory Graph, Instruments, and Analyze tools are complementary, meaning you can use each of them in conjunction with one another. Because these applications work relatively quickly, you can start debugging right away if you suspect that an application has a memory leak.

XCode Memory report

The image above is a classic example of a tell-tale memory leak sign. It shows entering and exiting an ARC view, whereupon exiting the memory should be released and on entering the resources should not be consumed at the same level as before. We can see from the image that the resources arrange themselves in a characteristic pyramid pattern and do not deallocate.

Prevent iOS leaks to improve app performance

Using Xcode and Analyze to locate memory leaks in iOS applications is incredibly useful. Although these tools aren’t always perfect at identifying iOS memory leaks, some skill on the developer’s side can more than make up for these small shortcomings. The consequences of memory leaks can range from a moderate reduction in app performance to a total application failure, meaning it is vital for developers to detect and deal with these issues if and when they arise.

Tech review made by Krzysztof Pacholak – iOS Developer

Photo of Krzysztof Ziółek

More posts by this author

Krzysztof Ziółek

Senior Quality Assurance Engineer at Netguru
Mobile app development   Enhance your business by creating a mobile app with powerful custom features  and outstanding UX Read the story

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency
Let's talk business!

Trusted by: