Swift By Rahul
June 25, 2026 · 13 min read ·

Memory Management in Swift: ARC and Weak References

As iOS developers, we spend a lot of time crafting beautiful UIs and writing robust logic. But behind the scenes, there's a crucial aspect of app performance and stability that often goes unnoticed until things start to go wrong: memory management. In Swift, Apple provides a sophisticated system called Automatic Reference Counting (ARC) to handle memory for us. While ARC generally "just works," understanding its principles is vital for preventing memory leaks and building high-performance applications.

This article will dive deep into ARC, explore the dreaded strong reference cycles, and show you how to effectively use weak and unowned references to keep your app's memory footprint lean and clean.

Understanding Automatic Reference Counting (ARC)

At its core, memory management is about allocating memory for new objects when they're needed and deallocating that memory when they're no longer in use. If you fail to deallocate memory, you end up with memory leaks, which can degrade app performance over time and eventually lead to crashes.

Swift uses Automatic Reference Counting (ARC) to manage memory for class instances. When you create a new instance of a class, ARC allocates a chunk of memory to store that instance. ARC then tracks the number of "strong" references pointing to that instance.

Here's how it works:

  1. Initialization: When you create a new instance of a class, ARC sets its reference count to 1.
  2. Strong References: Whenever you assign an instance to a property, constant, or variable that holds a strong reference, ARC increments the instance's reference count by 1.
  3. Dereferencing: When a strong reference is broken (e.g., a variable goes out of scope, is set to nil, or a property is assigned a new value), ARC decrements the instance's reference count by 1.
  4. Deallocation: When an instance's reference count drops to zero, ARC knows that no strong references are pointing to it anymore. At this point, ARC deallocates the instance, freeing up the memory it occupied.

This system largely automates memory management, freeing us from the manual retain and release calls found in Objective-C's manual memory management era.

Let's illustrate ARC's basic flow:

Automatic Reference Counting (ARC) Process Instance A Instance A Instance A RC: 1 RC: 2 RC: 0 `ref1` = Instance A `ref1` = Instance A `ref2` = Instance A `ref1` = nil `ref2` = nil Instance created New strong reference Deallocated! No strong references

Let's see this in action with a simple class:

class Person {
    let name: String

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

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

var reference1: Person?
var reference2: Person?
var reference3: Person?

print("Creating new Person instance...")
reference1 = Person(name: "Alice") // RC: 1 ("Alice is being initialized.")

print("Assigning to reference2...")
reference2 = reference1 // RC: 2

print("Assigning to reference3...")
reference3 = reference1 // RC: 3

print("Setting reference1 to nil...")
reference1 = nil // RC: 2

print("Setting reference2 to nil...")
reference2 = nil // RC: 1

print("Setting reference3 to nil...")
reference3 = nil // RC: 0 ("Alice is being deinitialized.")

// Output:
// Creating new Person instance...
// Alice is being initialized.
// Assigning to reference2...
// Assigning to reference3...
// Setting reference1 to nil...
// Setting reference2 to nil...
// Setting reference3 to nil...
// Alice is being deinitialized.

As you can see, the deinit method is called only when the last strong reference to the Person instance is removed, and its reference count drops to zero. This is ARC working exactly as intended.

The Problem: Strong Reference Cycles

While ARC is powerful, it has a blind spot: strong reference cycles. A strong reference cycle occurs when two or more instances hold strong references to each other, creating a closed loop. Because each instance still has a strong reference pointing to it, their reference counts never drop to zero, and ARC never deallocates them. This leads to a memory leak.

Consider a scenario where a Person might have an Apartment, and an Apartment has a tenant (a Person):

class Person {
    let name: String
    var apartment: Apartment? // Strong reference to Apartment

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

class Apartment {
    let unit: String
    var tenant: Person? // Strong reference to Person

    init(unit: String) { self.unit = unit; print("Apartment \(unit) is being initialized.") }
    deinit { print("Apartment \(unit) is being deinitialized.") }
}

var john: Person?
var unit4A: Apartment?

print("Setting up John and Apartment 4A...")
john = Person(name: "John Appleseed")
unit4A = Apartment(unit: "4A")

print("Establishing strong references...")
john?.apartment = unit4A
unit4A?.tenant = john

print("Releasing initial strong references...")
john = nil
unit4A = nil

// Output:
// Setting up John and Apartment 4A...
// John Appleseed is being initialized.
// Apartment 4A is being initialized.
// Establishing strong references...
// Releasing initial strong references...
// (No deinitialization messages for John or Apartment 4A)

Notice that neither "John Appleseed is being deinitialized" nor "Apartment 4A is being deinitialized" is printed. This is because john has a strong reference to unit4A, and unit4A has a strong reference back to john. Even when we set john and unit4A to nil, their internal reference counts remain at 1, preventing deallocation. This is a classic strong reference cycle.

Here's an ASCII diagram illustrating this cycle:

┌───────────────────┐     ┌─────────────────────┐
│    Person         │     │    Apartment        │
│    name: "John"   │◄───►│    unit: "4A"       │
│    apartment: ───────►  │    tenant: ───────────►
└───────────────────┘     └─────────────────────┘
     (strong)                   (strong)

Solving Strong Reference Cycles: Weak and Unowned References

Swift provides two keywords to resolve strong reference cycles: weak and unowned. Both prevent a reference from incrementing an instance's reference count. The choice between them depends on the relationship between the two instances.

Weak References (weak var)

A weak reference 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. For this reason, weak references are always declared as optional types (Type?).

You should use a weak reference when: The referenced instance has a shorter or equal lifespan. It's acceptable for the reference to become nil at some point. * A common scenario is a delegate pattern, where the delegate might be deallocated before the delegating object.

Let's fix our Person and Apartment example using weak:

class Person {
    let name: String
    var apartment: Apartment?

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

class Apartment {
    let unit: String
    weak var tenant: Person? // Changed to weak reference

    init(unit: String) { self.unit = unit; print("Apartment \(unit) is being initialized.") }
    deinit { print("Apartment \(unit) is being deinitialized.") }
}

var john: Person?
var unit4A: Apartment?

print("Setting up John and Apartment 4A (with weak reference)...")
john = Person(name: "John Appleseed")
unit4A = Apartment(unit: "4A")

print("Establishing references...")
john?.apartment = unit4A
unit4A?.tenant = john // This is now a weak reference

print("Releasing initial strong references...")
john = nil // Person's RC becomes 0, so John is deallocated.
           // unit4A.tenant automatically becomes nil.

unit4A = nil // Apartment's RC becomes 0, so unit4A is deallocated.

// Output:
// Setting up John and Apartment 4A (with weak reference)...
// John Appleseed is being initialized.
// Apartment 4A is being initialized.
// Establishing references...
// Releasing initial strong references...
// John Appleseed is being deinitialized.
// Apartment 4A is being deinitialized.

Now, when john is set to nil, the Person instance's reference count drops to zero, and it's deallocated. Because unit4A.tenant was a weak reference, it doesn't prevent this deallocation and automatically becomes nil. Subsequently, when unit4A is set to nil, the Apartment instance's reference count also drops to zero, and it's deallocated. Problem solved!

Unowned References (unowned var / unowned let)

An unowned reference, like a weak reference, does not keep a strong hold on the instance it refers to. However, an unowned reference is used when you are certain that the reference will always refer to an instance that has the same or a longer lifespan. This means an unowned reference is expected to always have a value. Therefore, it's not declared as an optional type.

You should use an unowned reference when: The referenced instance has the same or a longer lifespan. You are guaranteed that the reference will never be nil once it has been set. * Attempting to access an unowned reference that no longer points to an instance will result in a runtime error.

A common scenario for unowned references is a parent-child relationship where the child always has a parent, and the parent is expected to exist for at least as long as the child.

Consider a Customer and CreditCard relationship. A CreditCard always belongs to a Customer, and a Customer might or might not have a CreditCard.

class Customer {
    let name: String
    var card: CreditCard? // A customer may or may not have a credit card

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

class CreditCard {
    let number: UInt64
    unowned let customer: Customer // A credit card always has a customer

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

var rahul: Customer?

print("Creating Customer and CreditCard...")
rahul = Customer(name: "Rahul")
rahul!.card = CreditCard(number: 1234_5678_9012_3456, customer: rahul!)

print("Releasing customer...")
rahul = nil

// Output:
// Creating Customer and CreditCard...
// Rahul is being initialized.
// Card #1234567890123456 is being initialized.
// Releasing customer...
// Rahul is being deinitialized.
// Card #1234567890123456 is being deinitialized.

Here, the CreditCard has an unowned reference to its Customer. When rahul is set to nil, the Customer instance is deallocated. Since customer in CreditCard is unowned, it doesn't prevent this. The CreditCard is then also deallocated shortly after because its strong reference from rahul.card is also gone.

Here's a comparison of strong, weak, and unowned references:

Comparison of Strong, Weak, and Unowned References Strong Reference Weak Reference Unowned Reference `var` or `let` Increments RC Prevents deallocation Causes strong cycles Always has a value Default behavior Use when ownership is clear `weak var` Does NOT increment RC Allows deallocation Breaks strong cycles Optional (`Type?`), becomes `nil` For objects with shorter lifespan Use for delegates, closures with `self` `unowned var` or `unowned let` Does NOT increment RC Allows deallocation Breaks strong cycles Non-optional (`Type`), crashes if `nil` For objects with same/longer lifespan Use for definite parent-child

Closures and Strong Reference Cycles

It's not just two class instances that can form a strong reference cycle. Closures, which are reference types, can also capture self strongly and lead to cycles, especially common in UIViewController subclasses, network requests, or long-running tasks.

Consider a ViewController that performs a network request and updates its UI:

class MyViewController: UIViewController {
    var data: String?

    override func viewDidLoad() {
        super.viewDidLoad()
        print("MyViewController initialized.")
        fetchData()
    }

    func fetchData() {
        // Simulate a network request
        DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
            // This closure captures 'self' strongly
            self.data = "Fetched Data"
            print("Data fetched: \(self.data!)")
            // If self (MyViewController) is deallocated, this closure might still be held
            // by some external queue, preventing self from deallocating.
        }
    }

    deinit {
        print("MyViewController deinitialized.")
    }
}

var vc: MyViewController? = MyViewController()
// After 3 seconds, we expect vc to be deinitialized if no cycle exists
DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
    print("Setting vc to nil...")
    vc = nil
}
// Output:
// MyViewController initialized.
// Setting vc to nil...
// Data fetched: Fetched Data
// (No deinitialization message for MyViewController)

In this example, the DispatchQueue.main.asyncAfter closure captures self strongly. If vc is set to nil before the closure finishes executing, the closure itself still holds a strong reference to self (the MyViewController instance). This prevents MyViewController from being deallocated, causing a memory leak.

To fix this, we use a capture list within the closure to declare a weak or unowned reference to self.

class MyViewController: UIViewController {
    var data: String?

    override func viewDidLoad() {
        super.viewDidLoad()
        print("MyViewController initialized.")
        fetchData()
    }

    func fetchData() {
        // Use a capture list to capture self weakly
        DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in
            guard let self = self else {
                print("ViewController was deinitialized before data fetched.")
                return
            }
            self.data = "Fetched Data"
            print("Data fetched: \(self.data!)")
        }
    }

    deinit {
        print("MyViewController deinitialized.")
    }
}

var vc: MyViewController? = MyViewController()
DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
    print("Setting vc to nil...")
    vc = nil
}
// Output:
// MyViewController initialized.
// Setting vc to nil...
// MyViewController deinitialized.
// Data fetched: Fetched Data

Now, when vc is set to nil, the MyViewController instance can be deallocated. The weak self in the capture list ensures the closure doesn't keep self alive. Inside the closure, we use guard let self = self else { ... } because weak self is an optional, and the ViewController might have been deallocated by the time the closure executes.

You can also use [unowned self] if you are absolutely certain that self will never be nil by the time the closure executes. This is often the case for short-lived closures where the closure's lifespan is strictly nested within the lifespan of self.

// Example for unowned self (use with caution!)
class Calculator {
    var result: Int = 0
    func add(_ value: Int, completion: (Int) -> Void) {
        // If Calculator is guaranteed to exist when completion is called:
        // This is a simple example, often unowned is used in very specific cases
        // like a child object always having a parent.
        DispatchQueue.main.async { [unowned self] in
            self.result += value
            completion(self.result)
        }
    }
    deinit { print("Calculator deinitialized.") }
}

Practical Considerations and Best Practices

  • Delegates: Always declare delegate properties as weak to prevent strong reference cycles. The delegate (e.g., a ViewController) typically creates and owns the delegating object (e.g., a custom UIView), so the delegating object should not hold a strong reference back to its delegate.
  • Closures: Be mindful of self capture in closures. If a closure is stored as a property of a class instance and also captures that instance, you likely need [weak self] or [unowned self].
  • Parent-Child Relationships:
    • If a child can exist without a parent, and the parent owns the child: parent has strong reference to child, child has weak reference to parent (e.g., Apartment and Person).
    • If a child always has a parent, and the parent owns the child: parent has strong reference to child, child has unowned reference to parent (e.g., Customer and CreditCard).
    • Debugging Memory Leaks: Xcode's Instruments tool, specifically the "Allocations" and "Leaks" templates, are invaluable for identifying and debugging memory leaks. Look for objects that are allocated but never deallocated, especially if their reference counts don't drop to zero as expected.

Summary

Automatic Reference Counting (ARC) is Swift's powerful mechanism for managing memory, automatically deallocating class instances when no strong references point to them. However, strong reference cycles can prevent ARC from doing its job, leading to memory leaks. By understanding when and how to use weak and unowned references, particularly in object relationships and closures, you can effectively break these cycles and ensure your applications are performant and stable. Always consider the ownership pattern and relative lifespans of your objects when deciding between weak and unowned.

Happy Swifting!

Tagged: