Why Weak self and unowned self patterns in Swift? - Purpose & Use Cases

The Big Idea

What if your app could clean up after itself perfectly without you lifting a finger?

The Scenario

Imagine you write a Swift app where two objects keep strong references to each other, like two friends holding hands tightly. When you try to clean up one friend, they both stay stuck together forever, causing your app to use more memory and slow down.

The Problem

Without using weak or unowned references, your objects create a strong cycle. This means they never get released from memory, leading to memory leaks. Your app becomes slow and crashes eventually because it runs out of memory.

The Solution

Using weak and unowned references breaks this strong hold between objects. It lets one object hold a lighter grip, so when no one else needs it, it can be cleaned up safely. This keeps your app fast and healthy.

Before vs After

✗ Before

class A {
  var b: B?
}
class B {
  var a: A?
}
// Both hold strong references causing a cycle

✓ After

class A {
  var b: B?
}
class B {
  weak var a: A?
}
// Weak reference breaks the cycle

What It Enables

This pattern enables your app to manage memory smartly, preventing leaks and crashes by avoiding strong reference cycles.

Real Life Example

Think of a parent and child relationship in your app. The parent owns the child strongly, but the child only holds a weak reference back to the parent. When the parent is gone, the child can be cleaned up too, keeping memory tidy.

Key Takeaways

Strong reference cycles cause memory leaks.

Weak and unowned references break these cycles.

Using them keeps your app efficient and crash-free.