Strong, Weak, and Retain Cycles

Analogy categoryAnalogies

Strong vs. Weak References

A strong reference contributes to an object's retain count and guarantees the object stays alive at least as long as that reference exists; a weak reference observes the object without contributing to its retain count, and the runtime automatically clears the weak pointer to nil the instant the object's retain count hits zero and dealloc runs. This zeroing behavior is implemented via a side table the Objective-C runtime maintains internally, mapping objects to the weak pointer slots that reference them — it's not free, which is why weak reads are measurably slower than strong reads and why iterating heavily over weak properties in hot loops can show up in profiling. The default for object properties and local variables is always strong unless explicitly marked otherwise.

🏏

Cricket analogy: A strong reference is like being named in the playing XI — the team roster (retain count) literally includes you; a weak reference is like a TV commentator's guest list of 'players to watch,' which the broadcast automatically updates to remove a player the instant they're ruled out injured, without affecting the actual team sheet.

How Retain Cycles Form

A retain cycle occurs when two or more objects hold strong references to each other, directly or through a chain, so their retain counts can never drop to zero even after all external references are gone. The classic example is a parent-child relationship: a UIViewController holding a strong property to a custom view, and that view holding a strong 'delegate' or 'owner' back-reference to the controller — if both are strong, releasing the controller from its presenting context still leaves the cycle intact because each object is still keeping the other alive. Blocks are an especially common source of accidental cycles: a block captures self strongly by default if you reference any instance variable or property inside it, so storing that block as a property on self (e.g., a completion handler) creates self -> block -> self, a cycle that silently leaks the entire object graph.

🏏

Cricket analogy: A retain cycle is like two batters who have crossed mid-pitch on a risky run and each refuses to complete unless the other commits first — neither can be 'run out safely' (deallocated) because each is waiting on the other, just as two objects with mutual strong references never reach a retain count of zero.

objectivec

@interface DataLoader : NSObject
@property (nonatomic, copy) void (^completionHandler)(NSData *data);
- (void)loadWithCompletion:(void (^)(NSData *data))completion;
@end

@implementation DataLoader
- (void)loadWithCompletion:(void (^)(NSData *data))completion {
    self.completionHandler = completion; // retains the block
    // ... perform async work ...
}
@end

// LEAK: self is captured strongly inside the block, and self holds the block
DataLoader *loader = [[DataLoader alloc] init];
[loader loadWithCompletion:^(NSData *data) {
    [self processData:data]; // implicitly retains self strongly
}];

// FIX: capture a weak reference to self
__weak typeof(self) weakSelf = self;
[loader loadWithCompletion:^(NSData *data) {
    __strong typeof(self) strongSelf = weakSelf; // promote for safe use inside the block
    if (strongSelf) {
        [strongSelf processData:data];
    }
}];

Breaking Cycles: weak, unowned patterns, and NSTimer

The standard fix for a parent-owns-child relationship where the child needs to reference its owner is to mark the back-reference weak — this is exactly why UIKit's delegate properties (and Objective-C delegate conventions generally) are declared weak by convention: the child never needs to keep the parent alive, only to talk to it while it happens to exist. NSTimer is a notorious exception that catches developers off guard: a repeating timer created with scheduledTimerWithTimeInterval:target: retains its target strongly, so if a view controller schedules a timer targeting self and stores that timer in a strong property, you get self -> timer -> self, and because the timer is also strongly retained by the run loop until invalidated, the view controller cannot be deallocated even after it's dismissed — you must call [timer invalidate] explicitly, typically in viewWillDisappear or dealloc-adjacent lifecycle methods, or use the block-based scheduledTimerWithTimeInterval:repeats:block: with a weak self capture.

🏏

Cricket analogy: Declaring a delegate weak is like a non-playing team analyst who observes and reports to the captain without being on the strict 11-player roster — the team doesn't need to 'retain' the analyst's presence for the match to be valid, just like a view doesn't need to retain its delegate.

Xcode's Memory Graph Debugger (Debug Navigator > Memory Graph, or the 'Debug Memory Graph' toolbar button) will flag purple exclamation marks next to objects it detects are part of a retain cycle, letting you visually trace the strong reference chain — this is usually faster than manually auditing every strong property when hunting a suspected leak.

Strong references increment retain count and keep objects alive; weak references observe without incrementing and auto-nil on deallocation.
Retain cycles occur when two or more objects hold strong references to each other, directly or transitively, so none can ever reach a retain count of zero.
Blocks capture referenced objects (including self) strongly by default, making stored completion-handler blocks a common source of cycles.
The idiomatic fix inside a block is to capture __weak typeof(self) weakSelf and promote it to a strong local inside the block body when used.
Delegate properties are conventionally declared weak so the delegate does not need to be kept alive by the object it services.
NSTimer strongly retains its target and must be explicitly invalidated, or it (and its target) will never be deallocated.
Xcode's Memory Graph Debugger visually highlights retain cycles, making it the fastest tool for diagnosing suspected leaks.