Understanding iOS Property Modifiers and Common Retain Cycle Scenarios

In the previous article the low‑level principles of iOS memory management were introduced, noting that ARC simplifies most developers' work but memory leaks can still occur.

The discussion then focuses on two main sources of memory problems: property modifiers and retain cycles.

Property modifiers are divided into three groups: read/write (readwrite, readonly), memory‑related (assign, weak, strong, copy, plus the obsolete retain/release/unsafe_unretained), and thread‑safety (atomic, nonatomic). The article concentrates on the memory‑related modifiers.

assign can be applied to objects or primitive types, but using it on objects may produce dangling pointers because the pointer is not nil‑ed after the object is deallocated.

weak can only be applied to objects; it automatically nils the pointer when the referenced object is deallocated, preventing crashes and avoiding retain cycles, making it ideal for delegates and blocks.

strong creates a strong reference to an object, increasing its retain count.

copy is used for immutable collection types such as NSString, NSArray and NSDictionary to ensure that a mutable version cannot modify the stored value; mutable counterparts should be kept as strong.

The article then answers three common questions: why assign on objects leads to dangling pointers while weak does not, why NSString/NSArray/NSDictionary are usually declared with copy instead of strong, and why mutable collections should be declared strong rather than copy.

Next, common retain‑cycle scenarios are examined:

Improper use of blocks that capture self , forming a strong reference chain: self → request method → success block → self.

NSTimer retaining its target ( self ) when created with a selector, creating a cycle that is not broken by simply marking self as weak .

Incorrect delegate property attributes that cause strong references.

Solutions are provided:

Use __weak references inside blocks to break the cycle.

For NSTimer, either create a custom weak‑timer wrapper or, from iOS 10 onward, use the block‑based timer API which avoids selector‑based retain cycles.

Declare delegate properties as weak to prevent cycles.

The article concludes with reference links and a citation of the book “Objective‑C Advanced Programming: iOS and OS X Multithreading and Memory Management.”