Answer to the question

History of the question

Before Swift introduced Automatic Reference Counting (ARC), developers manually managed memory with retain, release, and autorelease calls, leading to frequent leaks or dangling pointers. Swift's ARC automates this at compile time by inserting retain/release calls, but it introduced a subtle complexity with closures, which are reference types that capture surrounding variables. This created a new class of memory issues specific to Swift where two reference types could form an indestructible circular dependency, necessitating the capture list syntax introduced to provide explicit control over these capture semantics.

The Problem

When a class instance stores a closure as a property, and that closure references self or other instance properties, ARC increments the instance's reference count to keep it alive for the closure's lifetime. Because the closure is itself referenced by the instance, a retain cycle emerges: the instance holds the closure strongly, and the closure holds the instance strongly. Neither reference count reaches zero, preventing deinit from ever executing and causing the memory to leak for the application's lifetime.

The Solution

Swift provides capture lists—comma-delimited expressions within square brackets preceding the closure’s parameter list—to modify default capture behavior. Specifying [weak self] creates a weak reference (optional, becomes nil when deallocated), while [unowned self] creates a non-owning reference (assumes existence, crashes if accessed after deallocation). For values, [x = x] captures the current value rather than the reference. This explicitly breaks the strong reference cycle, allowing ARC to deallocate the instance when external references are removed.

Code Example:

class DataManager {
    var completionHandler: ((Data) -> Void)?
    var data: Data = Data()
    
    func fetchData() {
        // Retain cycle: self holds closure, closure holds self
        completionHandler = { newData in
            self.data = newData // Strong capture of self
        }
    }
    
    func fetchDataFixed() {
        // Solution: weak capture
        completionHandler = { [weak self] newData in
            guard let self = self else { return }
            self.data = newData
        }
    }
    
    deinit {
        print("DataManager deallocated")
    }
}

Situation from life

In a production iOS application, we implemented a ProfileViewController that relied on a UserService class to fetch profile data asynchronously. The service exposed an API using closure-based completion handlers stored as properties to support cancellable requests. We observed that navigating away from the profile screen never triggered the ViewController's deinit, and Instruments reported a persistent memory graph object graph retaining the view hierarchy.

We considered several architectural approaches to resolve this leakage.

We attempted to explicitly set the completion handler to nil in viewWillDisappear. While this technically breaks the cycle when the user navigates back, it proved unreliable for abrupt terminations or unexpected state transitions. It also leaked if the closure was never invoked and the view controller was deallocated by the system under memory pressure before the disappear event. This approach required excessive defensive programming and violated the single responsibility principle by forcing the view controller to manage the service's internal state.

We evaluated using [unowned self] in the closure to avoid the overhead of optional unwrapping. This offered syntactic cleanliness and zero-cost abstraction benefits. However, during testing, we discovered race conditions where rapid navigation could deallocate the ViewController while the network request was still in flight, leading to crashes when the callback attempted to access the deallocated instance. The risk of undefined behavior in production outweighed the performance benefits.

We implemented [weak self] combined with a guard let self = self else { return } check at the closure's entry point. This safely handled all lifecycle scenarios: if the view controller was deallocated before the callback fired, the weak reference became nil, the guard failed silently, and ARC cleaned up the closure afterwards. While it required slightly more boilerplate code and introduced a small amount of optional handling overhead, it guaranteed memory safety and crash-free operation.

We adopted the weak capture approach universally across the codebase. After refactoring the UserService integration to use [weak self], memory graph debugging confirmed that ProfileViewController instances deallocated immediately upon dismissal. Xcode's memory graph debugger showed no remaining strong references from the closure, and Instruments leak detection reported zero leaks in the feature. This pattern became our standard for all closure-based asynchronous APIs.

What candidates often miss

How does capturing a struct instance in a closure differ from capturing a class instance, and why can't structs create retain cycles?

Many candidates incorrectly assume that capturing self in a closure always risks retain cycles regardless of context. Structs are value types in Swift, meaning they are copied rather than referenced. When a struct is captured by a closure, ARC copies the struct's value into the closure's capture list (or captures a reference to the immutable copy depending on optimization), but crucially, the struct does not have a reference count. Because the closure holds the value, not a pointer to a heap-allocated object, there is no possibility of a circular reference between the closure and the original struct instance.

The danger exists exclusively when self refers to a class (reference type), where the closure stores a pointer to the heap object, incrementing its reference count. Understanding this distinction is crucial for deciding whether to apply capture list modifiers when working with SwiftUI view structs versus UIKit view controllers.

What is the precise difference between [weak self] and [unowned self] regarding object lifetime assumptions, and when does [unowned self] cause a crash?

Candidates often treat these interchangeably. [weak self] converts the capture to an optional WeakReference, which ARC automatically sets to nil when the object deallocates. Accessing it requires optional binding and is safe even if the object dies. [unowned self] creates a non-owning reference that assumes the object will exist for the closure's entire lifetime; it behaves like an implicitly unwrapped optional that is never set to nil.

If the closure outlives the object (e.g., a stored completion handler called after the view controller pops), accessing self dereferences a dangling pointer, causing a EXC_BAD_ACCESS crash. Use [unowned self] only when the closure and object have identical lifetimes, such as non-escaping closures or specific delegate patterns where the closure cannot outlive the capturer.

How do capture lists interact with variables declared outside the closure scope, and does [x] create a copy or a reference for value types?

A common misconception is that capture lists only affect self. When you write { [x] in ... }, you explicitly capture the current value of x at the closure's creation point, effectively creating a shadow copy immutable within the closure. Without the capture list, the closure captures a reference to the original variable storage location, allowing it to see mutations made after the closure's creation and potentially participate in circular logic if x is a reference type.

For value types like Int or String, [x] captures a copy, preventing the closure from observing external changes to x and ensuring the closure's behavior is deterministic based on the state at capture time. This distinction becomes critical when closures escape their defining scope and execute asynchronously long after the original context has mutated.