Exercise 3: Why Leaks Misses Retain Cycles, and Why Allocations' Growth Pattern Catches Them — Possible Solution ========================================================================================================================= The Leaks instrument's own real detection mechanism specifically looks for memory that has become completely UNREACHABLE - allocated blocks that nothing in the entire running program can reach through any real chain of references anymore, yet ARC hasn't deallocated because something (a bug) is still technically holding onto it. That's the real, narrow, technical definition of a "leak" the instrument is actually built to catch. A strong reference cycle - two objects each holding a real strong reference to the other - doesn't fit that specific definition. Both objects in the cycle ARE still reachable, just not from anywhere USEFUL outside the cycle itself - object A can be reached by starting from object B, and object B can be reached by starting from object A, so neither one is ever truly unreachable from the program's own point of view, even though nothing outside that pair actually needs or uses either of them anymore. Because Leaks is specifically checking for genuine unreachability, and a retain cycle's own two objects remain technically reachable from each other, Leaks simply never flags this real, common case at all. Allocations, by contrast, doesn't check reachability at all - it simply tracks every real allocation and how long it stays alive. A retain cycle's own real, practical symptom shows up differently here: each time a screen holding the cycled objects is created and then dismissed, a NEW pair of cycled objects gets allocated, but the OLD pair - still alive only because of the cycle, per the reasoning above - never actually gets deallocated and removed from the count. Watching Allocations' own real memory graph while repeatedly entering and leaving that screen reveals this directly: memory climbs with each visit and never drops back down to its own starting baseline, since old instances are silently piling up rather than being properly released. ANSWER: Leaks specifically detects genuinely unreachable memory, but a retain cycle's two objects remain technically reachable from each other, so Leaks never flags them. Allocations instead tracks every real allocation's own lifetime directly - repeatedly entering and leaving a screen with a retain cycle creates new cycled object pairs that never get released, so the real memory count climbs and never returns to its starting baseline, which is exactly the practical symptom Allocations makes visible and Leaks structurally cannot catch. WHY THIS WORKS AS AN ANSWER ------------------------------ This explains the real technical reason (reachability vs. allocation tracking) behind the distinction the chapter's own finding-box identified, rather than simply restating that the two tools differ.