Memory Management

Each class instance has a strong reference count in its header. The compiler inserts retains and releases around assignments, captures and scope exits. When a release takes the count to zero, deinit runs synchronously on that thread and the memory is freed.

The important properties are that it's deterministic — no pause, no collector, deallocation happens at a point you can reason about — and that it's *local*. The decision only ever looks at one object's count.

That locality is where it falls short. A group of objects that reference each other keeps every count above zero, so the whole island is leaked even though nothing outside can reach it. A tracing garbage collector would find that by walking from the roots and noticing the island is unreachable; ARC has no roots and does no walking, so it can't. Breaking the cycle with weak or unowned on one edge is the developer's responsibility.

The trade is deliberate: predictable, low-latency deallocation and no runtime pauses, in exchange for having to think about ownership at cycle-shaped relationships.

I ask one question: can I state an invariant that guarantees the referenced object outlives this reference, and is that invariant enforced by code I control?

If yes — the classic case being a child object created by its parent, stored only by that parent, and unreachable once the parent is gone — unowned is honest. It documents the guarantee in the type, avoids an optional that would always succeed, and if I've got the invariant wrong the trap tells me loudly and immediately rather than hiding.

If the answer is no, weak. And "no" covers more than people expect: anything whose lifetime the system controls, anything reachable from a collection someone else mutates, anything torn down asynchronously. A delegate is the standard example — the delegating object has no idea when its delegate goes away, so weak var delegate is the only defensible choice.

The asymmetry that decides ties: an unnecessary weak costs an optional unwrap and a small read overhead. An incorrect unowned costs a crash on a user's device, in a scenario you didn't reproduce. Those aren't comparable, so I default to weak under uncertainty and treat unowned as something I have to justify.

A retain cycle is a loop of strong references. Because ARC frees an object only when its own count hits zero, and every object in the loop is being retained by another member of the loop, the whole group stays alive after it becomes unreachable. It's a leak with no crash and no error.

For detection I'd work in three layers.

During development, a deinit log on view controllers and view models. Push a screen, pop it, watch for the line. It costs nothing and catches the majority of cycles the day they're introduced, which is when they're cheapest to fix.

When something's suspected, Xcode's memory graph debugger. It renders the actual object graph and marks cycles directly, so you see which reference to weaken rather than guessing. Instruments' Allocations with a repeated push/pop is the companion — if the persistent-object count for a type climbs by one per visit and never comes down, that's your leak, and the generation summary tells you what's accumulating.

In production, you don't see individual cycles — you see the aggregate. Memory-related terminations in MetricKit, and jetsam events in the organizer, tell you memory is the problem and which build regressed. Then you reproduce with the tools above. It's also worth logging peak footprint per session so a regression shows up as a trend rather than as user complaints.

Prevention beats detection though: ownership pointing one way, weak delegates, [weak self] in stored closures, and reviewing subscriptions for what they capture.

I read every stored or escaping closure as a lifetime statement and ask two things: what does this keep alive, and what happens if the thing it references is gone when it runs?

The first question finds cycles. If the closure is reachable from the object it captures — stored on it, held in a cancellable set on it, registered with something the object owns — that's a loop, and the capture needs weakening.

The second question is the one reviewers skip, and it finds the subtler bug. Once you weaken the capture, you've decided that if the object dies the work doesn't happen. For a UI update that's correct and desirable. For "flush the cache", "release the lock", "resume the continuation" or "call the completion handler" it's a silent failure with no crash and nothing in the logs, which is much harder to diagnose than the leak it replaced. A continuation that never resumes is the worst version — the awaiting task hangs forever.

So the review outcome isn't always "add [weak self]". Sometimes it's "this closure should capture strongly and this object should live until the work finishes, and the reason belongs in a comment". Sometimes the best answer is to capture the two values it actually needs instead of the whole object, which makes both questions disappear.

I also look for whether the closure needs self at all — a surprising number capture it for one property that could have been snapshotted.