Swift Weak References

Introduction

Memory management is a crucial aspect of Swift programming that ensures your applications run efficiently without consuming excessive resources. One of the key tools in Swift's memory management arsenal is the concept of weak references. Understanding weak references is essential for preventing memory leaks and building robust iOS applications.

In this guide, we'll explore what weak references are, why they're important, and how to use them effectively in your Swift code.

Understanding Reference Counting

Before diving into weak references, let's quickly review how Swift manages memory using Automatic Reference Counting (ARC).

What is ARC?

Swift uses Automatic Reference Counting (ARC) to track and manage your app's memory usage. ARC automatically frees up memory used by class instances when those instances are no longer needed.

Every time you create an instance of a class, ARC allocates memory to store information about that instance. When an instance is no longer needed, ARC frees up the memory used by that instance.

Here's how reference counting works:

swift
class Person {
    let name: String
    
    init(name: String) {
        self.name = name
        print("\(name) is being initialized")
    }
    
    deinit {
        print("\(name) is being deinitialized")
    }
}

// Creating a reference increases the reference count to 1
var reference1: Person? = Person(name: "John")
// Output: John is being initialized

// Creating another reference increases the reference count to 2
var reference2 = reference1
var reference3 = reference1

// Setting references to nil decreases the reference count
reference1 = nil
reference2 = nil
reference3 = nil
// Output: John is being deinitialized (when the last reference is set to nil)

Strong Reference Cycles

A significant challenge with ARC is the strong reference cycle (also known as a retain cycle). This occurs when two class instances hold strong references to each other, preventing ARC from deallocating them even when they're no longer needed.

Let's see an example:

swift
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
    var tenant: Person?
    
    init(unit: String) {
        self.unit = unit
        print("Apartment \(unit) is being initialized")
    }
    
    deinit {
        print("Apartment \(unit) is being deinitialized")
    }
}

// Create instances
var john: Person? = Person(name: "John")
// Output: John is being initialized
var unit4A: Apartment? = Apartment(unit: "4A")
// Output: Apartment 4A is being initialized

// Create strong references between instances
john?.apartment = unit4A
unit4A?.tenant = john

// Attempt to break the references
john = nil
unit4A = nil

// No deinitialization messages appear!
// Memory leak occurred - instances are still in memory

In this example, even though we set both variables to nil, the Person and Apartment instances remain in memory because they hold strong references to each other.

Weak References to the Rescue

This is where weak references come in. A weak reference is a reference that doesn't increase the reference count of the object it points to.

Declaring Weak References

To create a weak reference in Swift, you use the weak keyword:

swift
weak var weakReference: ClassType?

Note that:

Weak references must be declared as variables (var), not constants (let)
Weak references must be optional types since they can automatically become nil
Weak references can only be applied to class types, not value types like structs or enums

Using Weak References to Break Reference Cycles

Let's fix our previous example using a weak reference:

swift
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? // Now using a weak reference
    
    init(unit: String) {
        self.unit = unit
        print("Apartment \(unit) is being initialized")
    }
    
    deinit {
        print("Apartment \(unit) is being deinitialized")
    }
}

// Create instances
var john: Person? = Person(name: "John")
// Output: John is being initialized
var unit4A: Apartment? = Apartment(unit: "4A")
// Output: Apartment 4A is being initialized

// Create references between instances
john?.apartment = unit4A
unit4A?.tenant = john

// Break the references
john = nil
// Output: John is being deinitialized
unit4A = nil
// Output: Apartment 4A is being deinitialized

Now when we set john to nil, the Person instance is deallocated because there are no strong references to it. The weak reference from unit4A?.tenant doesn't prevent deallocation.

When to Use Weak References

You should use weak references when:

Parent-Child Relationships: When a parent object needs to reference a child object, but the child should not keep the parent alive.
Delegates and Protocols: When implementing delegate patterns to avoid reference cycles.
Callbacks and Closures: When using closures that reference the object that created them.

Example: Weak References in Delegates

Delegate patterns are common in iOS development, and they often require weak references:

swift
protocol DataProviderDelegate: AnyObject {
    func didUpdateData()
}

class DataProvider {
    weak var delegate: DataProviderDelegate?
    
    func fetchData() {
        // Fetch data...
        delegate?.didUpdateData()
    }
}

class ViewController: UIViewController, DataProviderDelegate {
    let dataProvider = DataProvider()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        dataProvider.delegate = self // Without 'weak', this would create a reference cycle
    }
    
    func didUpdateData() {
        // Handle updated data
        print("Data was updated!")
    }
}

In this example, the DataProvider holds a weak reference to its delegate to prevent a reference cycle.

Example: Weak References in Closures

Closures can easily create reference cycles. Using weak references can help avoid this:

swift
class NetworkManager {
    var onCompletion: (() -> Void)?
    
    func fetchData() {
        // Simulate network request
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            self.onCompletion?() // This creates a strong reference to self
        }
    }
}

class DataViewController: UIViewController {
    let networkManager = NetworkManager()
    
    func loadData() {
        // Using 'weak self' to avoid a reference cycle
        networkManager.onCompletion = { [weak self] in
            guard let self = self else { return }
            self.updateUI()
        }
        networkManager.fetchData()
    }
    
    func updateUI() {
        print("Updating UI...")
    }
    
    deinit {
        print("DataViewController deallocated")
    }
}

Weak vs. Unowned References

Swift also provides unowned references which are similar to weak references but with some key differences:

Aspect	Weak	Unowned
Nullability	Can become `nil`	Cannot become `nil`
Safety	Safe - automatically becomes `nil`	Can cause crashes if the referenced object is deallocated
Use case	When reference might be `nil` at some point	When reference will never be `nil` during its lifetime

Example of unowned reference:

swift
class Customer {
    let name: String
    var card: CreditCard?
    
    init(name: String) {
        self.name = name
    }
    
    deinit { print("\(name) is deinitialized") }
}

class CreditCard {
    let number: UInt64
    unowned let customer: Customer
    
    init(number: UInt64, customer: Customer) {
        self.number = number
        self.customer = customer
    }
    
    deinit { print("Card #\(number) is deinitialized") }
}

var john: Customer? = Customer(name: "John")
john!.card = CreditCard(number: 1234_5678_9012_3456, customer: john!)

john = nil
// Outputs:
// John is deinitialized
// Card #1234567890123456 is deinitialized

Real-World Application: View Controllers and Timers

A common scenario where weak references are crucial is when using timers in view controllers:

swift
class TimerViewController: UIViewController {
    var timer: Timer?
    var counter = 0
    
    override func viewDidLoad() {
        super.viewDidLoad()
        startTimer()
    }
    
    func startTimer() {
        // Using weak self to prevent the timer from keeping the view controller alive
        timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { [weak self] _ in
            guard let self = self else { return }
            self.counter += 1
            print("Counter: \(self.counter)")
        }
    }
    
    deinit {
        timer?.invalidate()
        print("TimerViewController deallocated")
    }
}

// Usage
var viewController: TimerViewController? = TimerViewController()
// After some time
viewController = nil
// "TimerViewController deallocated" will be printed

Without [weak self], the timer would create a strong reference cycle, preventing the view controller from being deallocated even after it's no longer needed.

Summary

Weak references are a powerful tool in Swift's memory management system that help prevent memory leaks caused by strong reference cycles. By using weak references:

You allow ARC to deallocate objects when they're no longer strongly referenced
You can establish relationships between objects without creating reference cycles
You can implement common patterns like delegates and callbacks safely

Remember these key points:

Use weak for references that can become nil during their lifetime
Use unowned for references that will never be nil once initialized
Always use weak or unowned for delegate relationships
Use [weak self] in closures that reference the object creating them

Additional Resources

Exercises

Create a Teacher and Student class where they reference each other (a teacher has students and a student has teachers). Implement proper memory management to avoid reference cycles.
Build a simple notification system with a NotificationCenter class and a Subscriber protocol. Ensure that subscribers can be deallocated properly when they're no longer needed.
Implement a caching system that uses weak references to automatically remove entries when they're no longer referenced elsewhere in your code.

If you spot any mistakes on this website, please let me know at [email protected]. I’d greatly appreciate your feedback! :)

Introduction​

Understanding Reference Counting​

What is ARC?​

Strong Reference Cycles​

Weak References to the Rescue​

Declaring Weak References​

Using Weak References to Break Reference Cycles​

When to Use Weak References​

Example: Weak References in Delegates​

Example: Weak References in Closures​

Weak vs. Unowned References​

Real-World Application: View Controllers and Timers​

Summary​

Additional Resources​

Exercises​