A practical walkthrough for using the Leaks and Allocations templates in Instruments to track down leaks and runaway memory growth in your iOS app.
Two related but distinct problems hurt iOS memory health. A leak is memory that is allocated and then becomes unreachable, so it can never be freed.
Unbounded growth is different. Here memory is still reachable, but your app keeps holding onto more of it than it should, often through caches, retained view controllers, or accumulating data.
Both can eventually cause the system to terminate your app for excessive memory use. Both are worth catching early.
Instruments addresses these with two complementary templates. Leaks finds the truly unreachable memory, while Allocations helps you understand overall growth and what objects are alive.
In Xcode choose Product, then Profile, to build a profiling version of your app. Pick a real device when you can, since memory behavior can differ from the simulator.
When Instruments opens, select the Leaks template. This template combines an allocations track with a dedicated leak-detection track.
Confirm your app is the target at the top of the window. Then you are ready to record.
Leaks works by periodically scanning the heap for blocks that are no longer referenced. It reports these as discrete leak events on the timeline.
Press record and then drive your app through a repeatable cycle. A good pattern is to push a screen, use it, and pop back, repeated several times.
This push-and-pop loop is powerful because a healthy app should return to roughly the same memory level each cycle. If memory ratchets upward every loop, you have a strong signal.
Do the same navigation the same number of times so your trace is easy to interpret. Consistency makes the spikes and steps meaningful.
Watch the Leaks track as you go. Markers indicate detected leaks at that moment in the timeline.
Stop the recording once you have run your cycle. Select the Leaks instrument to see the list of leaked objects.
For each leak, Instruments shows the type and the allocation backtrace. The backtrace tells you where the leaked object was created.
Double-click a stack frame to jump into your source. This is usually enough to recognize the object and reason about why it was never released.
Not every reported leak is equally urgent, but repeated leaks of your own types during a normal user flow deserve immediate attention.
In Swift, a common cause of leaks is a retain cycle from strong references that point at each other. A frequent offender is a closure that strongly captures self.
When Instruments points you at a leaked object that should have been deallocated, look at what holds a strong reference to it. Closures, delegates, and parent-child object relationships are prime suspects.
The usual remedy is to break the cycle with a weak or unowned reference, such as capturing self weakly in a closure. Delegate properties are also commonly declared weak.
After making the change, re-run the same cycle in Instruments. The leak should no longer appear, which confirms you broke the cycle rather than merely moving it.
Switch to the Allocations template when the issue is growth rather than discrete leaks. Allocations tracks live objects and total memory over time.
Record while you repeat a navigation cycle, then look at whether the live byte count returns to baseline after each loop. A staircase that only climbs indicates objects that are accumulating.
Use the statistics and the live allocations view to see which types are growing. Sort by size or count to find the biggest contributors.
The mark-and-compare technique is invaluable here. By marking the heap at two points, such as before and after a cycle, you can isolate what was created and kept between them.
After you adjust ownership, clear caches appropriately, or release retained controllers, profile again. Use the identical navigation cycle you used before.
For a leak, success means the Leaks track stays clean through the whole run. For growth, success means live memory returns to a stable baseline after each cycle.
Keep both the before and after traces. They make a clear, honest record that the problem is genuinely resolved.
Memory work rewards patience. One confirmed fix at a time is far more reliable than several speculative changes you cannot verify.
Instruments is excellent for spotting that memory is leaking or growing, but Xcode has a complementary feature worth knowing: the memory graph debugger.
While your app runs under the debugger, you can capture a memory graph that shows live objects and the references between them. It is particularly good at making a retain cycle visible as an actual loop of arrows.
A common workflow is to use Instruments to learn that an object type is leaking or accumulating, then capture a memory graph to see exactly which references are keeping a specific instance alive.
The two tools reinforce each other. Instruments gives you the timeline and the aggregate picture across a session, and the memory graph gives you a precise snapshot of who owns what at a single moment. Reaching for both turns a vague suspicion into a concrete reference you can break.
A practical sequence is to navigate the app the way that grows memory, capture a memory graph at the suspicious moment, and then trace the chain of strong references back from the object that should have been freed. The reference that does not belong is usually the cycle, and once you weaken it, both the graph and a fresh Instruments run will confirm the object now deallocates as expected.
Do not assume every flagged leak is your code. Some allocations belong to frameworks and may have benign explanations, so focus first on repeated leaks of your own types.
Do not profile a debug build and trust the absolute numbers. Profile with Product then Profile for release-style conditions.
Do not confuse expected caching with a leak. Some memory growth is intentional, and the question is whether it is bounded and released under pressure.
Finally, remember that Instruments analyzes compiled native apps. If your codebase is web output from an app builder rather than native Swift, you would first need to compile a real native build in Xcode before these memory templates apply.
Leaks finds memory that has become unreachable and can never be freed. Allocations tracks live memory and helps you understand growth, even when nothing is technically leaked.
Retain cycles are a common cause, often from closures that strongly capture self or from delegates that are not declared weak. Breaking the cycle with a weak or unowned reference typically fixes it.
That pattern points to unbounded growth rather than leaks, such as caches or retained controllers that accumulate. Use the Allocations template and the mark-and-compare technique to find what is being kept alive.
Prefer a real device for realistic memory behavior and pressure. The simulator can behave differently from actual hardware.