A dismissed screen can keep its model, subscriptions, and image buffers alive long after its last visible frame.
iOS memory leak testing checks whether allocations outlive their intended owners and whether repeated use creates unexplained growth. A rising memory gauge starts an investigation. It does not identify a retain cycle, prove a leak, or establish that the app will survive device memory pressure.
This guide uses a fictional FieldNote app with photo previews, an editor, and live synchronization. Every scenario is a proposed synthetic test, not a report of hands-on results. Pair engineering diagnostics with an iOS beta testing plan that assigns specific journeys and records the distributed build.
Follow a repeatable memory leak testing workflow
Write a lifetime contract before profiling. The editor model should disappear after its route closes and pending work finishes. A shared image cache may remain, but it needs an intentional retention policy. Distinguish these owners before treating every surviving allocation as defective.
- Record build identity, Xcode version, device, OS, optimization settings, and enabled diagnostics.
- Seed synthetic notes and images, then establish the same starting screen.
- Warm the feature separately from the measured repetitions.
- Repeat opening, editing, previewing, dismissing, and returning to the starting screen.
- Observe settled object counts, allocation history, and footprint at equivalent checkpoints.
- Investigate unexpected survivors, change ownership or teardown, and repeat the original case.
Choose a repetition count that exposes the suspected pattern and document it. Wait for an observable completion or cancellation state rather than an unexplained sleep. Keep cold-launch and warmed comparisons separate so framework initialization does not obscure recurring retention.
Distinguish leaks from caches and allocation peaks
Classify the growth before changing code
Apple's Analyze heap memory session distinguishes useful reachable memory, abandoned reachable memory, and unreachable leaked memory. A singleton retaining obsolete editors can waste memory while remaining reachable. An unreachable ARC cycle can keep allocations alive without a useful owner.
Compare the pattern across equivalent journeys. First-use growth that settles can reflect initialization or a legitimate cache. Repeated surviving editor instances suggest an ownership problem. A preview spike that falls after decoding completes deserves a peak-memory investigation even if the objects eventually disappear.
Treat a high-water mark as evidence of a peak
The highest recorded allocation level is historical evidence, not the current live-object count. Record the peak and settled state independently. Allocator reuse and fragmentation can also complicate a footprint comparison, so do not demand that the gauge return to its exact launch value.
For the proposed cache case, repeat identical image keys, then introduce a bounded set of new fixtures. Specify eviction behavior and verify it separately. If every identical preview inserts a fresh key, investigate cache correctness even when Leaks reports nothing. A legitimate cache still needs a product-appropriate budget supported by measurements.
Inspect ARC ownership and safe reference choices
Trace the complete retain cycle
Swift's Automatic Reference Counting guide explains strong cycles between class instances and closures. In a proposed editor defect, the model owns a callback and that callback strongly captures the model. Neither side can release the other after external owners disappear.
Draw each ownership edge from the surviving object back to its root. Include coordinators, child controllers, stored callbacks, timers, and service registries. Fix the edge that violates the lifetime contract. Replacing arbitrary references can hide retention while losing work that the app intended to complete.
Choose weak and unowned from lifetime guarantees
Prefer weak when the owner may disappear
A weak reference does not keep its target alive and becomes nil after deallocation. Use it for a callback target that can disappear before delivery. Test dismissal before completion, then verify that optional handling safely ignores obsolete interface updates.
Require proof before choosing unowned
An unowned reference assumes the target remains alive when accessed. Access after deallocation causes a runtime error. Do not replace weak with unowned to silence optional handling in delayed callbacks. Exercise cancellation, navigation, and background transitions against the actual lifetime guarantee.
For delegates, inspect the declaration rather than trusting the property name. A custom parent that owns a child and receives its callbacks often needs a weak back-reference, supported by a class-bound protocol. Verify the protocol and implementation's ownership contract before changing an SDK or third-party relationship.
Test closures and Combine subscription teardown
Exercise callbacks after navigation
An escaping closure may retain captured objects until its owner releases it. Swift's closure documentation describes the capture behavior. Review stored completion handlers and nested closures, including an outer closure that captures self before constructing an inner weak capture.
Propose opening the editor, starting a delayed fixture request, and leaving before the response. Verify both model release and safe handling of the response. A finite request intentionally retaining its owner until completion differs from a stored callback that never releases it. State which behavior the feature requires.
Cancel subscriptions at the feature boundary
Apple documents that AnyCancellable calls cancel when deinitialized. That guarantee cannot solve a cycle that prevents the token's owner from deinitializing. A model storing a token for a sink closure that strongly captures the model deserves explicit ownership review.
In the proposed live-sync case, stop the subscription when the feature's lifetime ends and clear obsolete stored tokens. Choose weak captures where delivery should not own the model. Do not assume every assign overload has identical ownership semantics. Inspect the exact operator and storage arrangement used by the app.
Test repeated entry, publisher completion, cancellation, and sign-out. Confirm that old subscribers receive no further fixture events and that returning creates only the intended subscription. A missing deinit log is a clue, while the ownership graph and event behavior provide stronger evidence.
Verify Swift task cancellation and async lifetimes
Make cancellation observable
Swift cancellation is cooperative, as explained in Apple's structured concurrency session. Calling cancel requests termination. Work must respond through cancellation-aware operations or checks such as Task.checkCancellation(). Inspect error handling so a caught cancellation does not restart the operation indefinitely.
For a proposed preview task, start decoding, navigate away, request cancellation, and observe completion plus resource cleanup. Repeat with a deliberately delayed fixture. Verify that the task cannot publish into an obsolete editor and that replacement work does not inherit the canceled result.
Review unstructured tasks and retained captures
Apple's Task reference describes task lifetime and captured references. Dropping an unstructured Task handle does not cancel its work. Store a handle when the lifecycle owner needs cancellation, and define who stops a long-running sequence.
A weak capture can still become a strong local reference when promoted before an await. If that reference remains needed through a long-running operation, the model can stay alive. Treat this as a proposed ownership risk to inspect, not proof that every await leaks. Prefer capturing the required service or value when the whole model is unnecessary.
Do not rely exclusively on deinit to stop work that itself retains the object. Test cancellation from an explicit route or session boundary. Record whether child tasks are structured or unstructured, and verify propagation instead of assuming all spawned work stops with its caller.
Use Xcode Memory Graph Debugger to find leaks
Capture equivalent lifecycle checkpoints
Apple's memory-use investigation guide documents Debug Memory Graph and allocation stack traces enabled through the scheme's diagnostics. Capture after the proposed journey returns to its starting state, then search for the editor model and inspect incoming references.
Compare surviving instances before and after repetition. Trace a retained model through its closure context, token collection, or coordinator. Record the path and the allocation site separately. Creation explains where an object came from; incoming references explain why it remains.
Interpret graph warnings conservatively
Inspect strong edges and runtime type information. Some references are conservative or uncertain, so an apparent pointer is not always a proven ownership edge. Conversely, absence of a leak warning cannot establish that every retained object is useful. Apple's memory diagnostics session provides additional investigation context.
For the proposed report, attach the relevant ownership path and identify the expected teardown event. Avoid a screenshot containing only a warning triangle. Enable expensive diagnostics for investigation, record their presence, and repeat the performance comparison under equivalent settings.
Detect memory leaks using Instruments on physical devices
Separate allocation history from leak detection
Use Allocations to inspect creation and release over time, with generation marks around repeated journeys. Identify allocations that persist after teardown and trace their call stacks. Leaks supplies periodic detection of suspected unreachable allocations. These complementary views answer different questions about the same reproduction.
Compare the candidate and fixed build using the same physical device, OS, fixture size, journey, and build configuration. Inspect the scheme's Profile action and ensure the intended optimized configuration is selected. Keep symbols available for allocation stacks. A debug build with extra diagnostics is useful for explanation but needs its own comparison label.
Keep Simulator and pressure evidence separate
Apple's memory-use guide cautions that Simulator's green memory gauge does not demonstrate safe device usage. Simulator can help reproduce ownership and heap growth, while its host environment differs from iOS memory pressure and termination behavior.
Add supported physical devices relevant to your audience, especially where expensive media features run. Repeat foreground, background, and return journeys. Test the app's response to controlled memory-warning conditions separately from ordinary profiling. A simulated warning can exercise cleanup code without recreating the device's full pressure state.
Investigate jetsam and preserve release evidence
Classify termination before symbolication
Apple's jetsam report guide explains that pressure-driven termination may look like a crash. Jetsam reports contain device-wide memory information and lack application thread backtraces. Read the termination reason and process context before diagnosing a retain cycle.
A memory-heavy temporary peak can cause termination without a leak. A retained object can also accumulate without immediate termination. For ordinary crash reports, follow the iOS crash log symbolication guide. Matching symbols resolve crash addresses; they do not manufacture a missing jetsam call stack.
Turn the reproduction into a regression check
Apple's memory regression guidance supports XCTMemoryMetric with measure(metrics:) and recorded baselines. Add a focused journey test after diagnosing the defect. Keep functional assertions for teardown and cancellation alongside memory measurements, since one metric cannot prove every lifetime contract.
Set acceptance criteria from observed stable runs on documented configurations. Do not invent a universal megabyte limit or percentage increase. Review unexplained recurring survivors, peak changes, and baseline variability before approving a new baseline. Preserve comparable traces so a lower final gauge cannot conceal a larger transient peak.
Check object release separately from footprint
In a focused unit test, retain a weak probe to the feature model, release the test's strong references, and await the documented teardown completion before checking the probe. This verifies the chosen object's lifetime, not all memory leaks in an iOS app. Keep it separate from the memory metric so a passing footprint comparison cannot conceal an obsolete model. In CI, pin the test destination, fixture, build configuration, and diagnostic settings, and review changed baselines alongside the ownership fix.
Use synthetic photos, notes, accounts, and network responses. Memory graphs and traces may contain private object contents or identifiers, so restrict access and inspect artifacts before sharing. Follow the mobile bug report guide with build, context, exact actions, expected lifetime, actual retention, and redacted evidence.
Create a BetaRoast testing round for the supported devices and repeated journeys still needing confirmation. Give testers synthetic fixtures and precise actions, then let engineering reproduce reports under profiling. Archive the original failing case and the fixed-build retest together.
Frequently asked questions
Does a rising memory gauge prove an iOS memory leak?
No. Initialization, caches, temporary buffers, and allocator behavior can affect the gauge. Compare repeated equivalent journeys, investigate surviving allocations, and establish whether their owners still have a valid purpose.
Is a clean Instruments Leaks result enough to release?
No. Reachable abandoned objects and expensive transient peaks can remain problematic. Combine leak detection with allocation history, ownership inspection, cancellation checks, and representative physical-device journeys.
Should every asynchronous closure use weak self?
Choose captures from the required lifetime. Weak suits a target that may disappear, while intentional finite work may need ownership. Unowned requires a proven lifetime guarantee. Test late delivery and cancellation rather than applying one capture rule everywhere.
Can Simulator replace physical-device memory testing?
Simulator is useful for deterministic reproductions and ownership investigation. It does not establish physical-device pressure behavior. Confirm optimized-build comparisons on supported hardware and inspect real termination reports when investigating jetsam.
Establish a repeatable journey and an explicit lifetime contract, then compare surviving objects and memory patterns in equivalent builds. Use Memory Graph to investigate ownership, Allocations to explain growth, and Leaks as one diagnostic signal. Verify cancellation and teardown, distinguish jetsam from crashes, and confirm fixes on supported physical devices with synthetic data.