Swift By Rahul
October 8, 2026 · 10 min read ·

Understanding ARC in Swift

Memory management is a crucial aspect of writing efficient and stable applications. In the world of Swift and iOS development, Apple provides a robust system called Automatic Reference Counting (ARC) to handle memory management for you. While ARC largely works behind the scenes, a solid understanding of its principles is essential for intermediate developers to prevent memory leaks and write reliable code.

This article will demystify ARC, explain how it works, and most importantly, show you how to identify and resolve common pitfalls like retain cycles using weak and unowned references.

What is Automatic Reference Counting (ARC)?

Automatic Reference Counting (ARC) is Swift's mechanism for managing an app's memory usage. It automatically frees up memory used by class instances when they are no longer needed. Unlike garbage collection, which pauses execution to find and free unused memory, ARC performs memory management in real-time as your app runs, making it a predictable and efficient system.

The core idea behind ARC is simple: it keeps track of how many "strong" references currently point to an instance of a class. When the count of strong references for an instance drops to zero, ARC knows that no one is holding onto that instance anymore, and it can safely deallocate its memory.

ARC and Reference Types

It's important to remember that ARC only applies to reference types (classes) because instances of classes are stored on the heap and can have multiple owners. Value types (structs, enums, tuples) are copied when passed around and are typically stored on the stack or inline within their containing types, so ARC doesn't manage their memory directly.

Let's visualize the basic flow of ARC:

Basic ARC Flow Diagram Class Instance RC: X Variable A Strong Ref 1. Instance Created (RC=1) 2. Strong Ref Added/Removed 3. RC Decrements to 0 4. Instance Deallocated

How ARC Works Under the Hood

When you create a new instance of a class, ARC allocates a chunk of memory to store that instance, and its reference count is set to 1. Each time you assign that instance to another property, constant, or variable, ARC increments its reference count. When a strong reference is broken (e.g., a variable goes out of scope, or you set it to nil), ARC decrements the reference count.

A class instance is only deallocated when its reference count reaches zero. This deallocation process triggers the instance's deinit() method, if one is implemented, allowing you to perform any necessary cleanup before the memory is reclaimed.

class MyClass {
    let id: Int
    init(id: Int) {
        self.id = id
        print("MyClass instance \(id) initialized.")
    }

    deinit {
        print("MyClass instance \(id) deinitialized.")
    }
}

// Reference Count (RC) will be 1
var ref1: MyClass? = MyClass(id: 1)

// RC for instance with id 1 becomes 2
var ref2 = ref1

// RC for instance with id 1 becomes 3
let ref3 = ref1

// ref2 is set to nil, RC for id 1 becomes 2
ref2 = nil

// ref3 goes out of scope (e.g., end of function), RC for id 1 becomes 1
// For demonstration, let's explicitly set it to nil
var tempRef: MyClass? = ref3 // This would be the actual behavior
tempRef = nil // RC is 2 again, if ref3 was still strong

// Let's reset for clarity:
print("--- Demonstrating Deinitialization ---")
var instanceA: MyClass? = MyClass(id: 2) // RC = 1
var instanceB: MyClass? = instanceA      // RC = 2

instanceA = nil // RC = 1 (instanceB still points to it)
instanceB = nil // RC = 0, instance 2 deinitialized.

print("--- End of Deinitialization Demo ---")

In the example above, you can observe the deinit message printed only when the very last strong reference to an instance is removed.

Retain Cycles: The Pitfall of ARC

While ARC generally handles memory management flawlessly, it can run into trouble when two or more class instances hold strong references to each other. This creates a "retain cycle," where each instance prevents the other from being deallocated, even if they are no longer needed by the rest of your application. This leads to memory leaks, as the memory occupied by these instances is never reclaimed.

Consider a Person and an Apartment class. A person might rent an apartment, and an apartment might have a tenant. If both hold strong references to each other, a retain cycle occurs:

┌───────────┐     ┌───────────┐
│  Person   │────►│ Apartment │
│  (Strong) │◄────│ (Strong)  │
└───────────┘     └───────────┘

Let's see this in code:

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")
    }
}

var rahul: Person?
var unit4A: Apartment?

rahul = Person(name: "Rahul") // Person RC = 1
unit4A = Apartment(unit: "4A") // Apartment RC = 1

rahul?.apartment = unit4A // Person.apartment now has a strong ref to unit4A. Apartment RC = 2
unit4A?.tenant = rahul    // Apartment.tenant now has a strong ref to rahul. Person RC = 2

print("Setting references to nil...")
rahul = nil // Person RC = 1 (Apartment still holds a strong ref)
unit4A = nil // Apartment RC = 1 (Person still holds a strong ref)

// Notice: No "deinitialized" messages are printed for Rahul or unit4A.
// This indicates a memory leak due to a retain cycle.
print("Finished setting references to nil.")

Despite setting rahul and unit4A to nil, neither instance is deallocated. They are stuck in a cycle, forever holding onto each other.

Resolving Retain Cycles: weak and unowned References

To break retain cycles, Swift provides two special types of references: weak and unowned. These references do not increment an instance's reference count, allowing other strong references to be the sole determinant of an instance's lifetime.

weak References

A weak reference is a reference that doesn't keep a strong hold on the instance it refers to, and thus doesn't prevent ARC from deallocating that instance. If the instance it refers to is deallocated, a weak reference automatically becomes nil. Because of this, weak references must always be declared as optional types.

When to use weak:

  • When the referenced instance has a shorter or independent lifetime compared to the referencing instance.
  • Common in delegate patterns, where the delegate (e.g., a ViewController) might outlive the object it's delegating to (e.g., a CustomView).
  • Parent-child relationships where the child might exist without a parent, or the parent might be deallocated first.

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

class PersonFixed {
    let name: String
    var apartment: ApartmentFixed?

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

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

class ApartmentFixed {
    let unit: String
    weak var tenant: PersonFixed? // <--- Use 'weak' here

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

    deinit {
        print("Apartment \(unit) is being deinitialized")
    }
}

var rahulFixed: PersonFixed?
var unit4AFixed: ApartmentFixed?

rahulFixed = PersonFixed(name: "Rahul")
unit4AFixed = ApartmentFixed(unit: "4A")

rahulFixed?.apartment = unit4AFixed
unit4AFixed?.tenant = rahulFixed // This is now a weak reference. Apartment's RC for Person is not incremented.

print("Setting references to nil (weak fix)...")
rahulFixed = nil // Person RC becomes 0, Rahul deinitialized.
                // When Rahul is deinitialized, ApartmentFixed.tenant (weak ref) becomes nil.
unit4AFixed = nil // Apartment RC becomes 0, unit4A deinitialized.

// Expected: Both "deinitialized" messages are printed. Leak resolved!
print("Finished setting references to nil (weak fix).")

unowned References

An unowned reference, like a weak reference, does not keep a strong hold on the instance it refers to. However, unowned references are used when you know that the reference will always refer to an instance that has the same or a longer lifetime than the referencing instance. Because of this guarantee, unowned references are always non-optional. If you try to access an unowned reference after its instance has been deallocated, your app will crash at runtime.

When to use unowned:

  • When the referenced instance is guaranteed to exist as long as the referencing instance.
  • Common in parent-child relationships where the child always has a parent, and the parent's lifetime is equal to or longer than the child's.
  • In closure capture lists, when the closure and the instance it captures will always refer to each other and be deallocated at the same time.

Let's consider an HTMLElement example. An HTML element might have an asHTML closure that captures self to generate its HTML string. If this closure is a lazy property, it will be stored and could create a retain cycle. Using unowned self is appropriate here because the asHTML closure will never be called after the HTMLElement instance is deallocated.

class HTMLElement {
    let name: String
    let text: String?

    // The 'asHTML' closure captures 'self'.
    // If not marked 'unowned', it would create a strong reference cycle.
    lazy var asHTML: () -> String = { [unowned self] in // <--- Use 'unowned self' here
        if let text = self.text {
            return "<\(self.name)>\(text)</\(self.name)>"
        } else {
            return "<\(self.name) />"
        }
    }

    init(name: String, text: String? = nil) {
        self.name = name
        self.text = text
        print("\(name) initialized")
    }

    deinit {
        print("\(name) deinitialized")
    }
}

var paragraph: HTMLElement? = HTMLElement(name: "p", text: "Hello, world!")
print(paragraph!.asHTML())

print("Setting HTMLElement to nil (unowned fix)...")
paragraph = nil // Without 'unowned self', this would not deinitialize.
print("Finished setting HTMLElement to nil (unowned fix).")

weak vs. unowned in Closure Capture Lists

When a closure captures self, it typically creates a strong reference to self. To break a potential retain cycle, you can use [weak self] or [unowned self] in the closure's capture list.

  • Use [weak self] when self might become nil before the closure finishes executing. You'll need to use optional chaining (self?.property) or unwrap self safely (guard let self = self else { return }).
  • Use [unowned self] when self is guaranteed to be alive for the entire duration of the closure's execution. If self is deallocated before the closure finishes, your app will crash.

Here's a decision tree to help you choose between weak and unowned:

Weak vs Unowned Decision Flowchart Is there a strong reference cycle? Will the referenced object ever be nil? YES Use 'weak' NO Use 'unowned' "unowned" implies lifetimes are equal or longer. Crashing if 'nil' is a desired behavior.

When Not to Worry About ARC

While understanding ARC is crucial for classes, there are scenarios where you don't need to actively manage memory:

  • Value Types: Structs, enums, and tuples are value types. They are copied when assigned to a new variable or passed to a function. Their memory is typically managed on the stack or as part of a containing reference type, not by ARC.
  • Basic Data Types: Int, String, Bool, Array, Dictionary, Set (when they contain value types) are often optimized by Swift. Collections like Array and Dictionary use copy-on-write semantics, meaning they only perform a full copy when modified, sharing memory for reads.
  • Temporary Objects: Instances that are created and immediately go out of scope within a function (and are not captured by a stored closure or assigned to a long-lived property) are automatically deallocated when the function ends.

Summary

Automatic Reference Counting (ARC) is Swift's powerful and mostly hands-off approach to memory management for class instances. By tracking strong references, ARC ensures that memory is reclaimed efficiently when objects are no longer in use. However, a common pitfall is the retain cycle, where two or more objects hold strong references to each other, preventing their deallocation and leading to memory leaks.

To combat retain cycles, Swift offers weak and unowned references: Use weak when the referenced instance might become nil at some point, and the referencing instance doesn't need to keep it alive. weak references are always optional. Use unowned when you're certain that the referenced instance will always have the same or a longer lifetime than the referencing instance. unowned references are non-optional, and accessing them after the instance has been deallocated will cause a runtime crash.

Understanding these concepts is fundamental to writing robust, memory-efficient Swift applications. By correctly applying weak and unowned references, you can prevent memory leaks and ensure your app runs smoothly.

Happy Swifting!

Tagged: