Swift By Rahul
October 9, 2026 · 12 min read ·

Understanding Weak References in Swift

Memory management is a crucial aspect of writing robust and efficient applications. In Swift, Automatic Reference Counting (ARC) handles most of the heavy lifting for us, automatically deallocating objects when they are no longer needed. However, ARC isn't foolproof, and there are specific scenarios where we need to lend it a helping hand to prevent memory leaks. One of the most common and vital tools for this is the weak reference.

This article will dive deep into what weak references are, why they're essential, how they work, and when to use them effectively in your Swift and iOS projects.

The Problem: Retain Cycles

Before we can appreciate weak references, we must first understand the problem they solve: retain cycles.

In Swift, when you create an instance of a class, ARC allocates memory for it. As long as at least one strong reference to that instance exists, ARC will keep the instance alive. When the last strong reference is removed, ARC deallocates the instance and frees up its memory. This works perfectly in most cases.

A retain cycle occurs when two or more objects hold strong references to each other, creating a closed loop. Because each object has at least one strong reference pointing to it, ARC can never deallocate any of them, even if they are no longer reachable from the rest of your application. This leads to a memory leak: the memory occupied by these objects is never reclaimed.

Let's illustrate with a classic example: a Person and a Laptop class.

class Person {
    let name: String
    var laptop: Laptop?

    init(name: String) {
        self.name = name
        print("\(name) is being initialized.")
    }

    deinit {
        print("\(name) is being deinitialized.")
    }
}

class Laptop {
    let model: String
    var owner: Person?

    init(model: String) {
        self.model = model
        print("Laptop \(model) is being initialized.")
    }

    deinit {
        print("Laptop \(model) is being deinitialized.")
    }
}

Now, let's create instances and see what happens:

var rahul: Person?
var macbook: Laptop?

print("--- Setting up objects ---")
rahul = Person(name: "Rahul")
macbook = Laptop(model: "MacBook Pro")

rahul?.laptop = macbook
macbook?.owner = rahul

print("--- Releasing strong references ---")
rahul = nil
macbook = nil
print("--- Done releasing references ---")

If you run this code, you'll see the initialization messages, but you won't see the deinit messages for "Rahul" or "MacBook Pro". This indicates a memory leak.

Strong Retain Cycle Person (Rahul) laptop: Strong Reference Laptop (MacBook) owner: Strong Reference strong strong

The problem is that rahul has a strong reference to macbook, and macbook has a strong reference back to rahul. Even when we set rahul = nil and macbook = nil, their respective strong references to each other still exist, preventing ARC from deallocating them.

The Solution: Weak References

This is where the weak keyword comes to the rescue. A weak reference is a reference that does not keep a strong hold on the instance it refers to, and thus does not prevent ARC from deallocating that instance. If the instance it refers to is deallocated, a weak reference automatically becomes nil.

Because a weak reference can become nil at any point, it must always be declared as an optional type (var OptionalType). Furthermore, it must always be a variable (var), not a constant (let), because its value can change to nil.

Let's modify our Laptop class to use a weak reference for its owner:

class Person {
    let name: String
    var laptop: Laptop? // Strong reference to Laptop

    init(name: String) {
        self.name = name
        print("\(name) is being initialized.")
    }

    deinit {
        print("\(name) is being deinitialized.")
    }
}

class Laptop {
    let model: String
    weak var owner: Person? // WEAK reference to Person

    init(model: String) {
        self.model = model
        print("Laptop \(model) is being initialized.")
    }

    deinit {
        print("Laptop \(model) is being deinitialized.")
    }
}

Now, let's run the same setup code again:

var rahul: Person?
var macbook: Laptop?

print("--- Setting up objects ---")
rahul = Person(name: "Rahul")
macbook = Laptop(model: "MacBook Pro")

rahul?.laptop = macbook
macbook?.owner = rahul

print("--- Releasing strong references ---")
rahul = nil // Person (Rahul) loses its last strong reference.
            // Laptop's weak reference to Person becomes nil.
macbook = nil // Laptop (MacBook Pro) loses its last strong reference.
print("--- Done releasing references ---")

This time, the output will be:

--- Setting up objects ---
Rahul is being initialized.
Laptop MacBook Pro is being initialized.
--- Releasing strong references ---
Rahul is being deinitialized.
Laptop MacBook Pro is being deinitialized.
--- Done releasing references ---

Success! Both objects were deallocated correctly. When rahul = nil was executed, the Person instance lost its last strong reference and was deallocated. Consequently, macbook's weak var owner property automatically became nil. Then, when macbook = nil was executed, the Laptop instance also lost its last strong reference and was deallocated. The retain cycle is broken.

When to Use Weak References

Weak references are typically used in scenarios where one object "owns" another, but the owned object also needs to refer back to its owner without creating a retain cycle.

Common use cases include:

  • Delegate Patterns: In Cocoa/Cocoa Touch, the delegate pattern is ubiquitous. A ViewController might be the delegate for a UITableView, for instance. The table view typically holds a weak reference to its delegate to prevent a retain cycle, as the view controller already strongly owns the table view.
    ┌───────────────┐     ┌─────────────────┐
    │  ViewController ├───► │   TableView     │
    │ (Strong owner) │     │ (Strongly held) │
    └───────────────┘     └─────────────────┘
           ▲                     │
           └─────────────────────┘
              Weak Reference
              (delegate)
    ```

*   **Parent-Child Relationships**: As seen in our `Person` and `Laptop` example, if a parent object strongly holds a child object, and the child needs to reference its parent, the child's reference to the parent should be `weak`.
*   **Closures**: This is one of the most frequent places you'll encounter `weak` references. When a closure captures `self`, it creates a strong reference to `self`. If `self` also holds a strong reference to the closure (e.g., a network request completion handler stored as a property or a timer), a retain cycle can form. Using `[weak self]` in the closure's capture list breaks this cycle.

    ```swift
    class DataFetcher {
        var completionHandler: (() -> Void)?

        func fetchData() {
            // Simulate an async operation
            DispatchQueue.main.asyncAfter(deadline: .now() + 1) { [weak self] in
                guard let self = self else { return } // Safely unwrap weak self
                print("Data fetched for \(self.description)")
                self.completionHandler?()
            }
        }

        init() { print("DataFetcher initialized") }
        deinit { print("DataFetcher deinitialized") }
    }

    class ViewController: CustomStringConvertible {
        var fetcher: DataFetcher?
        var description: String { "ViewController" }

        init() {
            fetcher = DataFetcher()
            fetcher?.completionHandler = { [weak self] in // Use weak self here
                guard let self = self else {
                    print("ViewController was deallocated before completion.")
                    return
                }
                print("Completion handler executed for \(self.description)")
                self.fetcher = nil // Clean up
            }
            print("ViewController initialized")
        }

        deinit {
            print("ViewController deinitialized")
        }
    }

    var vc: ViewController? = ViewController()
    vc?.fetcher?.fetchData()

    // Simulate navigation away from the ViewController
    DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) {
        vc = nil // ViewController should deallocate now, even if fetcher is still running
    }

    // Output will show ViewController deinit before "Data fetched" if vc becomes nil
    // If [weak self] wasn't used, ViewController would leak until fetcher is released.
    ```

    In this example, without `[weak self]` in the completion handler, `ViewController` would strongly hold `fetcher`, and `fetcher`'s `completionHandler` closure would strongly capture `self` (the `ViewController`), leading to a retain cycle. By making `self` weak in the closure, the `ViewController` can be deallocated when `vc = nil`, even if the closure hasn't completed yet.

## Weak vs. Unowned References

Swift offers another non-strong reference type: `unowned`. While both `weak` and `unowned` references don't create strong holds, they have a crucial difference:

*   **`weak`**: Can be `nil`. Use when the other instance might have a shorter lifetime or might be deallocated *before* the current instance.
*   **`unowned`**: Is *never* `nil`. Use when the other instance has the same lifetime or a longer lifetime than the current instance. If you try to access an `unowned` reference after its instance has been deallocated, your app will crash at runtime.

Consider the `CreditCard` and `Customer` relationship. A `Customer` might own multiple `CreditCard`s, and a `CreditCard` will *always* have an `owner`. In this scenario, the `CreditCard`'s reference to its `Customer` owner can be `unowned`, because the `CreditCard` will never exist without an owner.

swift class Customer { let name: String var card: CreditCard?

init(name: String) { self.name = name } deinit { print("(name) is being deinitialized.") } }

class CreditCard { let number: UInt64 unowned let owner: Customer // Unowned reference

init(number: UInt64, owner: Customer) { self.number = number self.owner = owner } deinit { print("Card #(number) is being deinitialized.") } }

var john: Customer? john = Customer(name: "John Appleseed") john?.card = CreditCard(number: 123456789012_3456, owner: john!)

john = nil // Both Customer and CreditCard deallocate correctly.


If `john` were to become `nil` while `john.card` still existed, the `CreditCard`'s `unowned owner` reference would immediately become invalid, but it wouldn't be `nil`. Accessing it would cause a runtime crash. This is why `unowned` is best used when you are absolutely certain the referenced object will outlive or have the same lifetime as the object holding the `unowned` reference.

<div style="text-align: center; margin: 2em 0;">
<svg viewBox="0 0 700 250" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="Comparison of strong, weak, and unowned references in Swift">
  <title>Strong, Weak, and Unowned References</title>

  <!-- Strong Reference -->
  <rect x="20" y="20" width="200" height="80" rx="10" fill="#1565c0" stroke="#0d47a1" stroke-width="2"/>
  <text x="120" y="50" font-family="Arial, sans-serif" font-size="18" fill="white" text-anchor="middle">Object A</text>
  <text x="120" y="75" font-family="Arial, sans-serif" font-size="14" fill="white" text-anchor="middle">Holds strong ref</text>

  <rect x="20" y="140" width="200" height="80" rx="10" fill="#F04B3E" stroke="#d32f2f" stroke-width="2"/>
  <text x="120" y="170" font-family="Arial, sans-serif" font-size="18" fill="white" text-anchor="middle">Object B</text>
  <text x="120" y="195" font-family="Arial, sans-serif" font-size="14" fill="white" text-anchor="middle">Holds strong ref</text>

  <path d="M220 60 H280 M280 60 L270 50 M280 60 L270 70" stroke="#2A8367" stroke-width="3" fill="none" marker-end="url(#arrowhead-strong)"/>
  <text x="250" y="45" font-family="Arial, sans-serif" font-size="12" fill="#2A8367" text-anchor="middle">strong</text>
  <path d="M220 180 H280 M280 180 L270 170 M280 180 L270 190" stroke="#F04B3E" stroke-width="3" fill="none" marker-end="url(#arrowhead-strong-red)"/>
  <text x="250" y="165" font-family="Arial, sans-serif" font-size="12" fill="#F04B3E" text-anchor="middle">strong</text>

  <text x="120" y="120" font-family="Arial, sans-serif" font-size="16" fill="black" text-anchor="middle">Retain Cycle!</text>


  <!-- Weak Reference -->
  <rect x="300" y="20" width="180" height="80" rx="10" fill="#1565c0" stroke="#0d47a1" stroke-width="2"/>
  <text x="390" y="50" font-family="Arial, sans-serif" font-size="18" fill="white" text-anchor="middle">Object C</text>
  <text x="390" y="75" font-family="Arial, sans-serif" font-size="14" fill="white" text-anchor="middle">Strong ref</text>

  <rect x="500" y="20" width="180" height="80" rx="10" fill="#2A8367" stroke="#1c6b54" stroke-width="2"/>
  <text x="590" y="50" font-family="Arial, sans-serif" font-size="18" fill="white" text-anchor="middle">Object D?</text>
  <text x="590" y="75" font-family="Arial, sans-serif" font-size="14" fill="white" text-anchor="middle">Weak ref (Optional)</text>

  <path d="M480 60 H540 M540 60 L530 50 M540 60 L530 70" stroke="#2A8367" stroke-width="3" fill="none" marker-end="url(#arrowhead-strong)"/>
  <text x="510" y="45" font-family="Arial, sans-serif" font-size="12" fill="#2A8367" text-anchor="middle">strong</text>
  <path d="M500 60 H440 M440 60 L450 50 M440 60 L450 70" stroke="#F04B3E" stroke-width="3" fill="none" marker-end="url(#arrowhead-weak)" stroke-dasharray="5,5"/>
  <text x="470" y="75" font-family="Arial, sans-serif" font-size="12" fill="#F04B3E" text-anchor="middle">weak</text>

  <text x="490" y="120" font-family="Arial, sans-serif" font-size="16" fill="black" text-anchor="middle">No Retain Cycle</text>


  <!-- Unowned Reference -->
  <rect x="300" y="140" width="180" height="80" rx="10" fill="#1565c0" stroke="#0d47a1" stroke-width="2"/>
  <text x="390" y="170" font-family="Arial, sans-serif" font-size="18" fill="white" text-anchor="middle">Object E</text>
  <text x="390" y="195" font-family="Arial, sans-serif" font-size="14" fill="white" text-anchor="middle">Strong ref</text>

  <rect x="500" y="140" width="180" height="80" rx="10" fill="#2A8367" stroke="#1c6b54" stroke-width="2"/>
  <text x="590" y="170" font-family="Arial, sans-serif" font-size="18" fill="white" text-anchor="middle">Object F</text>
  <text x="590" y="195" font-family="Arial, sans-serif" font-size="14" fill="white" text-anchor="middle">Unowned ref (Non-optional)</text>

  <path d="M480 180 H540 M540 180 L530 170 M540 180 L530 190" stroke="#2A8367" stroke-width="3" fill="none" marker-end="url(#arrowhead-strong)"/>
  <text x="510" y="165" font-family="Arial, sans-serif" font-size="12" fill="#2A8367" text-anchor="middle">strong</text>
  <path d="M500 180 H440 M440 180 L450 170 M440 180 L450 190" stroke="#F04B3E" stroke-width="3" fill="none" marker-end="url(#arrowhead-unowned)" stroke-dasharray="2,2"/>
  <text x="470" y="195" font-family="Arial, sans-serif" font-size="12" fill="#F04B3E" text-anchor="middle">unowned</text>

  <text x="490" y="230" font-family="Arial, sans-serif" font-size="16" fill="black" text-anchor="middle">No Retain Cycle (but unsafe if F outlives E)</text>

  <!-- Define arrowheads -->
  <defs>
    <marker id="arrowhead-strong" markerWidth="10" markerHeight="7" refX="10" refY="3.5" orient="auto">
      <polygon points="0 0, 10 3.5, 0 7" fill="#2A8367" />
    </marker>
    <marker id="arrowhead-strong-red" markerWidth="10" markerHeight="7" refX="10" refY="3.5" orient="auto">
      <polygon points="0 0, 10 3.5, 0 7" fill="#F04B3E" />
    </marker>
    <marker id="arrowhead-weak" markerWidth="10" markerHeight="7" refX="10" refY="3.5" orient="auto">
      <polygon points="0 0, 10 3.5, 0 7" fill="#F04B3E" />
    </marker>
    <marker id="arrowhead-unowned" markerWidth="10" markerHeight="7" refX="10" refY="3.5" orient="auto">
      <polygon points="0 0, 10 3.5, 0 7" fill="#F04B3E" />
    </marker>
  </defs>
</svg>
</div>

## Practical Advice: Safely Using `weak self` in Closures

When using `[weak self]` in a closure, `self` becomes an optional (`self?`). It's good practice to safely unwrap it if you need to access its properties or methods within the closure. The `guard let self = self else { return }` pattern is ideal for this:

swift class MyService { func performAsyncOperation(completion: @escaping (String) -> Void) { DispatchQueue.global().asyncAfter(deadline: .now() + 2) { completion("Data from service") } } }

class ViewModel { let service = MyService() var data: String = ""

init() { print("ViewModel initialized") // Simulate a long-running operation service.performAsyncOperation { [weak self] fetchedData in // Safely unwrap self guard let self = self else { print("ViewModel was deallocated before data arrived.") return } self.data = fetchedData print("ViewModel received data: (self.data)") } }

deinit { print("ViewModel deinitialized") } }

var viewModel: ViewModel? = ViewModel()

// Let's release the strong reference to viewModel after a short delay // to see if the deinit is called correctly. DispatchQueue.main.asyncAfter(deadline: .now() + 1) { print("Releasing viewModel reference...") viewModel = nil }

// Keep the program alive long enough for the async operation to potentially complete DispatchQueue.main.asyncAfter(deadline: .now() + 3) { print("Program finished.") }


In this example:
1.  `ViewModel` is initialized, which starts an async operation in `MyService`.
2.  The `completion` closure for `MyService` captures `[weak self]`.
3.  After 1 second, `viewModel = nil` is executed. Since `MyService` does not hold a strong reference back to `ViewModel`, and the closure's capture of `self` is `weak`, `ViewModel`'s `deinit` is called.
4.  When the `MyService` operation completes after 2 seconds, the closure is executed. `guard let self = self else { ... }` correctly identifies that `self` is now `nil` and returns, preventing a crash or access to a deallocated instance.

This pattern is fundamental for preventing memory leaks in asynchronous operations and UI event handling in iOS development.

## Summary

Weak references are a cornerstone of proper memory management in Swift, particularly for preventing retain cycles. By understanding when and how to use the `weak` keyword, you can ensure your objects are deallocated correctly by ARC, leading to more stable and efficient applications. Remember to use `weak` when an object might outlive the object it refers to, and always declare it as an optional `var`. For situations where you're certain the referenced object will always be alive, `unowned` can be used, but with caution due to its crash-on-nil behavior. Mastering these concepts is essential for any intermediate Swift developer.

Happy Swifting!
Tagged: