What is a retain cycle in ARC with closures?

WHAT THIS TESTS: The interviewer wants to see if you understand how Automatic Reference Counting manages object lifecycles and how closures capture references by default. Specifically they are looking for knowledge of strong reference cycles between an object and a closure and the ability to choose the correct capture list strategy.

A GOOD ANSWER COVERS: First define a retain cycle as a situation where two or more objects hold strong references to each other creating a memory leak because ARC cannot zero out their reference counts. Second explain that closures are reference types that capture variables from their surrounding scope by default with strong references. Third give the specific example of a class with a stored closure property that references self inside its body causing the class instance and the closure to keep each other alive forever. Fourth describe the fix by adding a capture list such as [weak self] or [unowned self] before the closure parameter list. Fifth distinguish between weak which creates an optional self that must be unwrapped and safely handles the case where self deallocates before the closure runs and unowned which assumes self will always exist and creates a non-optional reference but crashes if self is accessed after deallocation.

COMMON WRONG ANSWERS: A major red flag is claiming that Swift uses garbage collection instead of ARC. Another is saying you always use weak for every closure without explaining why unowned exists. Some candidates suggest manually setting the closure property to nil in deinit which misses the point because deinit will never run while the cycle exists. Confusing value types and reference types or forgetting that escaping closures capture self strongly by default also signals weak fundamentals.

LIKELY FOLLOW-UPS: The interviewer might ask when you would choose unowned over weak and the correct reasoning is that unowned is appropriate only when the closure and the captured object have identical lifetimes or when the object is guaranteed to outlive the closure. They might also ask what happens if you use unowned and self is deallocated which results in a runtime crash because unowned does not nil out. Another follow-up could be about the difference between escaping and non-escaping closures and whether non-escaping closures create retain cycles which they generally do not because they do not outlive the function call.

ONE CONCRETE EXAMPLE: Imagine a NetworkManager class with a var completionHandler optional closure property taking Data and returning Void. Inside fetchData you assign completionHandler equal to a closure that calls self dot process on the argument. Because the closure strongly captures self and the NetworkManager instance strongly holds the closure neither is ever deallocated. To fix this you write the closure with a capture list [weak self] then data in guard let self equals self else return then self dot process on data. This breaks the cycle because the closure now holds a weak reference to self allowing ARC to deallocate the NetworkManager when no other strong references remain.