Weak self vs unowned self in Swift closures: choosing the right capture

Developers need to decide whether to capture self as weak or unowned in a Swift closure to break retain cycles while avoiding crashes. The choice hinges on the lifetime relationship between the closure and the object it captures, a detail that is not always obvious in complex view‑controller or networking code.

Because [unowned self] assumes that self will never be nil during the closure’s execution, using it incorrectly leads to a runtime crash, whereas [weak self] always yields an optional that must be handled. The documentation provides the rule, but applying it to asynchronous callbacks, timers, or Combine publishers can be unclear, leaving teams uncertain about which capture is safe without introducing performance overhead or extra optional handling. When is it safe to rely on [unowned self]? What testing strategies can confirm the lifetime guarantee? How should a fallback to [weak self] be structured when the guarantee cannot be proven?