Automatic Reference Counting (ARC): Swift's Memory Manager

WHY IT EXISTS: Swift uses ARC to automate memory management for reference types (classes) without the performance unpredictability of a traditional garbage collector. Manual memory management, common in languages like C, is notoriously difficult and a frequent source of bugs like memory leaks and crashes. ARC provides a compile-time, deterministic solution.

THE MENTAL MODEL: Think of ARC as a landlord managing an apartment. The apartment is a class instance in memory. Every time a new tenant (a variable, constant, or property) gets a key to the apartment, the landlord increments a "tenant count" (the reference count). When a tenant moves out (the reference goes out of scope or is set to nil), the count is decremented. When the count hits zero, the landlord knows the apartment is empty and can clean it up (deallocate the memory).

HOW IT WORKS: The Swift compiler automatically inserts memory management calls (retain and release) into your app's compiled code. When you assign a class instance to a property, constant, or variable, a strong reference is created, and the instance's reference count is incremented. When that reference is no longer needed, its reference count is decremented. Once the count reaches zero, the instance is deallocated from memory. This process is deterministic and happens as soon as the last strong reference is removed.

WHEN TO USE IT: You don't choose to use ARC; it's the default and mandatory memory management system for classes in Swift. Your job is not to enable it, but to manage reference types correctly within its rules. This primarily involves deciding when to use strong, weak, or unowned references to define the ownership relationships between your objects. The default is strong.

WHEN NOT TO USE IT: The question isn't when not to use ARC, but when not to use a strong reference. You must avoid strong references when they would create a "strong reference cycle" (or retain cycle). This happens when two class instances hold strong references to each other, preventing either from ever being deallocated. To break these cycles, you declare one of the references as weak or unowned. A weak reference doesn't keep an instance alive and becomes nil if the instance is deallocated. An unowned reference also doesn't keep an instance alive but is assumed to always refer to a valid object; accessing it after deallocation will crash your app.

ONE CANONICAL EXAMPLE: A common retain cycle involves a Person and their Apartment. The Person has a strong reference to their Apartment, and the Apartment has a strong reference back to its tenant. Because both references are strong, their reference counts will never drop to zero, even when all external references are removed. This creates a memory leak. The solution is to make the Apartment's reference to its tenant a weak reference, breaking the cycle.