Limits on closure capture semantics for preventing strong reference cycles

Direct answer

The three questions you posed each map to a distinct layer of Swift's ownership semantics. Below are confirmed facts, a likely explanation, and the minimal steps needed to evaluate your specific case.

Confirmed facts

• A strong reference cycle forms when an object retains an escaping closure that strongly captures self, preventing ARC from deallocating either the object or the closure's captured reference.
• [weak self] breaks the cycle by converting self to an optional inside the closure; the standard idiom is guard let self = self else { return } to obtain a strong local reference for the closure body.
• [unowned self] breaks the cycle without optional handling, but only when the closure's lifetime is strictly bounded by self's lifetime — if the closure can outlive self, accessing self traps at runtime.
• Non-escaping closures (the default for function parameters) are not retained beyond the call, so capture-list decisions are primarily relevant for @escaping closures stored as properties or passed to code that may retain them.
• The Swift compiler does not emit a default warning for implicit strong capture of self in escaping closures; it requires explicit self. usage as a syntactic reminder, but cycle detection is left to the developer, Memory Graph Debugger, or Instruments.

Likely explanation / decision rule

The community-standard rule is: default to [weak self] for any retained or escaping closure that captures self. Use [unowned self] only when you can structurally guarantee that the closure will never be invoked after self is deinitialized. Scenarios that satisfy this guarantee include closures owned by self that are cleared in deinit, or closures guaranteed non-escaping. In practice, the optional-handling overhead of weak is negligible; the guard-let pattern executes once per invocation and is used throughout Apple's frameworks (Combine sinks, URLSession completion handlers, delegate callbacks).

Steps to evaluate your case

1. Identify whether the closure is @escaping or could be stored as a property. If yes, a capture list is required to avoid a potential cycle.
2. If the closure captures self and may outlive self, write [weak self] with guard let self = self else { return }.
3. If you believe the closure cannot execute after self is deallocated (e.g., self owns the closure and invalidates it in deinit, or the closure is structurally non-escaping), you may write [unowned self] — but verify this assumption with a targeted test (see step 5).
4. Run your app in Xcode's Debug Memory Graph with the chosen capture list; a missing or incorrect list will show a retain-cycle edge.
5. To test the [unowned self] assumption, dispatch the closure to after self would normally be deinitialized (e.g., DispatchQueue.global().asyncAfter(deadline: .now() + 2) { /* use self */ }). If the app crashes, the lifetime guarantee was incorrect and [weak self] should be used instead.

To determine whether [unowned self] is appropriate without risking a crash, could you confirm whether the closure is @escaping and how its lifetime is scoped relative to self? This single detail directly changes the recommendation.