Explain ARC in depth: weak vs unowned, and how to detect leaks.

Question

IT Interview Practice · Accepted Answer

**ARC (Automatic Reference Counting)** manages memory for class instances by tracking strong references at compile time: the compiler inserts `retain`/`release` calls, and when an object's strong count reaches zero it is deallocated immediately — deterministically, not by a background garbage collector.

## How references affect the count

- **strong** (default) — increments the count; keeps the object alive.
- **weak** — does *not* increment; automatically set to `nil` on deallocation. Must be `var` and optional.
- **unowned** — does *not* increment; assumed to always be valid. Accessing after deallocation is a crash (or worse, undefined behavior with `unowned(unsafe)`).

```swift
final class Customer {
    var card: Card?                 // strong: customer owns card
}
final class Card {
    unowned let owner: Customer     // unowned: card never outlives its owner
    init(owner: Customer) { self.owner = owner }
}
```

## weak vs unowned — the decision

Choose by **lifetime relationship**, not by habit:

| | weak | unowned |
|--|------|---------|
| Optional | yes (becomes nil) | no |
| ARC cost | slightly higher (tracked) | lower |
| Safe if other object gone | yes | **crash** |
| Use when | the reference *can* legitimately become nil (delegates, parent that may deallocate first) | the reference is guaranteed to outlive self (child → mandatory parent) |

## Detecting leaks

1. **Xcode Memory Graph Debugger** — pause and look for objects that should be gone; purple `!` markers flag cycles.
2. **Instruments → Leaks / Allocations** — watch for monotonically growing memory as you repeat a flow.
3. **`deinit` logging** — the fastest sanity check: if `deinit` never prints when a screen closes, that object leaked.

```swift
deinit { print("released \(Self.self)") }  // silence on dismiss = leak
```

## Common leak sources

Escaping closures capturing `self`, two-way parent/child strong references, `Timer`/`DispatchSourceTimer` retaining their target, and Combine subscriptions not stored in a cancellable that deallocates.

## Why it matters

ARC is deterministic, so leaks are your responsibility, not a GC's — a single retained view controller can pin megabytes of images and its whole object graph. Senior interviews probe this because correctly choosing weak vs unowned and knowing how to *prove* a leak with the memory graph is what keeps long-running apps from ballooning.

	weak	unowned
Optional	yes (becomes nil)	no
ARC cost	slightly higher (tracked)	lower
Safe if other object gone	yes	crash
Use when	the reference can legitimately become nil (delegates, parent that may deallocate first)	the reference is guaranteed to outlive self (child → mandatory parent)

How references affect the count

weak vs unowned — the decision

Detecting leaks

Common leak sources

Why it matters

Related questions