What is a closure capture list? Explain [weak self] versus [unowned self].

WHAT THIS TESTS: This question probes deep understanding of Automatic Reference Counting in Swift and whether you can prevent memory leaks without introducing crashes. Interviewers want to see that you know how closures extend object lifetimes and that you can choose between defensive and assertive capture strategies based on actual object graphs rather than habit.

A GOOD ANSWER COVERS: First, define a capture list as the bracketed section at the start of a closure that explicitly declares how each captured variable should be treated. Second, explain that [weak self] creates an optional weak reference to the instance; if the instance is deallocated before the closure runs, self becomes nil, so you must handle the nil case with guard let or optional chaining. Third, explain that [unowned self] creates a non-optional unsafe reference; it does not keep the instance alive, but if the instance is deallocated, accessing self inside the closure triggers a runtime crash because the pointer becomes dangling. Fourth, contrast safety and use cases: use [weak self] when the closure might outlive the captured instance, such as in network completion handlers, timers, or notification observers. Use [unowned self] only when the closure and the instance are guaranteed to have identical lifetimes, for example when the closure is owned by the instance and cannot execute after deallocation. Fifth, note that [unowned self] avoids the syntactic overhead of optionality but demands absolute certainty about lifetimes, while [weak self] is the safer default for escaping closures.

COMMON WRONG ANSWERS: Claiming that [unowned self] is simply a faster [weak self] without mentioning the crash risk. Stating that weak references are automatically set to nil at a deterministic instant rather than at the next ARC zeroing. Using [unowned self] in an escaping async closure where the user can navigate away and destroy the object before the callback fires. Forgetting that capturing value types copies them, while capturing reference types without a list creates a strong reference by default.

LIKELY FOLLOW-UPS: The interviewer might ask when you would ever prefer unowned over weak in production code, expecting an answer about contained animations or tightly coupled parent-child relationships. They might ask how to handle a completion handler that must execute exactly once and needs to call a method on self, which leads to patterns like guard let self else { return } or capturing an unowned reference to a specific sub-object. They might also ask about the difference between capturing [self] and [weak self], or how capture lists interact with value types.

ONE CONCRETE EXAMPLE: Imagine a view controller that initiates a network request. The URLSession completion handler should use [weak self] because the user can dismiss the view controller before the server responds; if self were unowned, the app would crash when the handler tries to update the UI on a deallocated object. Conversely, consider a custom UIControl subclass that creates an action closure in its own initializer and stores it in a private property. Because the control owns the closure and the closure never escapes, [unowned self] is acceptable here since the control cannot deallocate while the closure exists.