objc-block-retain-cycles

Block retain cycles occur when a block captures `self` and is retained by a property or assignment on that same object, creating a circular reference. Use Instruments' Allocations template to confirm memory isn't returning to baseline after dismissing a screen, then trace the cycle using the Memory Debugger to locate retained blocks.

The weak-strong pattern breaks cycles by capturing a weak reference to `self` before the block executes. Declare `__weak typeof(self) weakSelf = self;` outside the block, then inside use `typeof(self) strongSelf = weakSelf;` with an `if (strongSelf)` guard to safely access self without creating a retain cycle.

A UIViewController fails to deallocate when blocks assigned to properties or used in network callbacks capture `self` without the weak-strong pattern, creating a retain cycle. Systematically check for `self` references in all blocks—including hidden captures in macros like `NSAssert` or `NSLog`—and apply weak-strong guarding to break the cycle.

Yes. Hidden `self` captures occur within macros like `NSAssert` and `NSLog` inside blocks. Use Instruments' Memory Debugger to trace retained instances and review macro expansions, then apply the weak-strong pattern to guard all block code, including macro invocations.

Yes. Real-device testing is mandatory for block retain cycle diagnosis because simulator memory behavior differs from production. Use Instruments on a physical device to confirm memory behavior after screen dismissals and validate that the weak-strong pattern actually breaks the cycle.

Use Instruments when you observe memory not returning to baseline after dismissing screens, encounter "sending message to deallocated instance" crashes, or suspect silent memory accumulation from network callbacks or asynchronous operations. Start with Allocations to confirm the leak, then use Memory Debugger to trace and identify retained blocks.