weak vs unowned Swift interview question

This is the classic ARC follow-up. The answer hinges on object lifetime, and being precise about it is a strong senior signal.

The rule and the reasoning

Both weak and unowned break retain cycles by not incrementing the reference count. Use weak when the referenced object can become nil during the reference's lifetime, which makes it optional and safe. Use unowned when the object is guaranteed to outlive the reference, avoiding the optional but crashing if that assumption is ever violated.

Applying it in code

In escaping closures that capture self, a weak self capture list is the safe default, unwrapped with guard let self. Delegates are typically weak so a child does not retain its parent. Reach for unowned only when the lifetime guarantee is genuinely certain, such as a value that cannot exist without its owner, and be ready to justify that certainty.

Go deeper than a summary

Share Your Screen works topics like this through in full: 75 solved Swift problems with tests, 9 real case studies, and 7 annotated mock interviews, so you rehearse the live round instead of just reading about it.

Get the book

Frequently asked

Which is safer, weak or unowned?

weak is safer because it becomes nil instead of crashing. unowned avoids optionality but will crash if the object is deallocated first, so use it only when lifetime is guaranteed.

Why capture weak self in closures?

To avoid a retain cycle where the closure keeps self alive and self keeps the closure alive. weak self lets self deallocate normally.