Strong reference cycles between classes in Swift - Step-by-Step Execution

Concept Flow - Strong reference cycles between classes

Create instance A

↓

Create instance B

↓

A holds strong reference to B

↓

B holds strong reference to A

↓

Reference count of A and B > 0

↓

Neither deinit called -> Memory leak

↓

Strong reference cycle detected

Two class instances hold strong references to each other, preventing deallocation and causing a memory leak.

Execution Sample

Swift

class Person {
  var apartment: Apartment?
  deinit { print("Person deinitialized") }
}

class Apartment {
  var tenant: Person?
  deinit { print("Apartment deinitialized") }
}

var john: Person? = Person()
var unit4A: Apartment? = Apartment()
john!.apartment = unit4A
unit4A!.tenant = john

john = nil
unit4A = nil

Creates two classes referencing each other strongly, then sets variables to nil but instances are not deinitialized due to strong reference cycle.

Execution Table

Step	Action	Person instance count	Apartment instance count	Output
1	Create Person instance 'john'	1	0
2	Create Apartment instance 'unit4A'	1	1
3	Set john.apartment = unit4A	1	1
4	Set unit4A.tenant = john	1	1
5	Set john = nil	1 (still referenced by unit4A.tenant)	1
6	Set unit4A = nil	1	1 (still referenced by john.apartment)
7	End of scope, no deinit called	1	1	No deinitialization - memory leak

💡 Both instances remain because they strongly reference each other, preventing deallocation.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
john	nil	Person instance	Person instance	Person instance	Person instance	nil	nil	nil
unit4A	nil	nil	Apartment instance	Apartment instance	Apartment instance	Apartment instance	nil	nil
john.apartment	nil	nil	nil	Apartment instance	Apartment instance	Apartment instance	Apartment instance	Apartment instance
unit4A.tenant	nil	nil	nil	nil	Person instance	Person instance	Person instance	Person instance

Key Moments - 3 Insights

Why does setting 'john = nil' not deinitialize the Person instance?

Because 'unit4A.tenant' still holds a strong reference to the Person instance, keeping its reference count above zero (see execution_table step 5).

Why does setting 'unit4A = nil' not deinitialize the Apartment instance?

Because 'john.apartment' still holds a strong reference to the Apartment instance, so its reference count remains above zero (see execution_table step 6).

What causes the memory leak in this example?

The strong reference cycle where Person and Apartment instances hold strong references to each other prevents both from being deallocated (see execution_table step 7).

Visual Quiz - 3 Questions

Look at the execution table, what is the Person instance count after setting 'john = nil'?

A 1 (still referenced)

B 0 (deinitialized)

C 2 (duplicated)

D nil (no instance)

💡 Hint

Check execution_table row 5 under 'Person instance count'

At which step does the Apartment instance remain alive despite setting 'unit4A = nil'?

A Step 4

B Step 6

C Step 5

D Step 7

💡 Hint

Look at execution_table row 6 for 'Apartment instance count'

If we remove the strong reference from 'unit4A.tenant' to 'john', what would happen?

A Both instances would leak

B Apartment instance would leak

C Person instance would deinitialize when 'john = nil'

D Nothing changes

💡 Hint

Removing one strong reference breaks the cycle, allowing deinit (see key_moments about strong references)

Concept Snapshot

Strong reference cycles happen when two class instances hold strong references to each other.
This keeps their reference counts above zero, so neither is deallocated.
In Swift, this causes memory leaks.
Use weak or unowned references to break cycles.
Always check for cycles when classes reference each other.

Full Transcript

This example shows two Swift classes, Person and Apartment, each holding a strong reference to the other. When we create instances and link them, their reference counts increase. Setting the variables 'john' and 'unit4A' to nil does not deinitialize the instances because they still strongly reference each other. This creates a strong reference cycle, causing a memory leak. The execution table tracks the reference counts and shows no deinitialization occurs. To fix this, one reference should be weak or unowned to allow proper deallocation.

Practice

1.

What causes a strong reference cycle between two Swift classes?

Consider two classes holding references to each other.

easy

A. Neither class holds any reference to the other.

B. One class holds a weak reference and the other a strong reference.

C. Both classes hold strong references to each other, preventing deallocation.

D. Both classes hold weak references to each other.

Solution

1. Step 1: Understand strong references

   Strong references keep objects alive by increasing their reference count.

2. Step 2: Identify cycle condition

   If two objects hold strong references to each other, neither can be deallocated, causing a cycle.

3. Final Answer:

   Both classes hold strong references to each other, preventing deallocation. -> Option C

4. Quick Check:

   Strong references + mutual hold = cycle [OK]

Hint: Strong references both ways cause cycles; use weak/unowned [OK]

Common Mistakes:

• Thinking weak references cause cycles
• Assuming one strong and one weak causes cycle
• Confusing unowned with strong references

2.

Which of the following is the correct way to declare a weak reference in Swift to avoid a strong reference cycle?

class Person {
    var apartment: Apartment?
}

class Apartment {
    // What should go here?
    var tenant: ???
}

easy

A. var tenant: Person

B. weak var tenant: Person?

C. unowned var tenant: Person

D. var tenant: Person?

Solution

1. Step 1: Identify weak reference syntax

   In Swift, weak references are declared with the keyword weak and must be optional.

2. Step 2: Apply to property

   So, weak var tenant: Person? is correct to avoid strong cycles.

3. Final Answer:

   weak var tenant: Person? -> Option B

4. Quick Check:

   Weak + optional = correct syntax [OK]

Hint: Weak references must be optional and use 'weak' keyword [OK]

Common Mistakes:

• Declaring weak without optional type
• Using unowned when weak is needed
• Forgetting 'weak' keyword

3.

What will be the output of the following Swift code?

class Person {
    let name: String
    var apartment: Apartment?
    init(name: String) { self.name = name }
    deinit { print("Person \(name) is being deinitialized") }
}

class Apartment {
    let unit: String
    weak var tenant: Person?
    init(unit: String) { self.unit = unit }
    deinit { print("Apartment \(unit) is being deinitialized") }
}

var john: Person? = Person(name: "John")
var apt: Apartment? = Apartment(unit: "4A")
john!.apartment = apt
apt!.tenant = john
john = nil
apt = nil

medium

A. Person John is being deinitialized
Apartment 4A is being deinitialized

B. No output, memory leak occurs

C. Only Person John is being deinitialized

D. Only Apartment 4A is being deinitialized

Solution

1. Step 1: Analyze references

   Person holds strong reference to Apartment; Apartment holds weak reference to Person.

2. Step 2: Check deallocation

   Setting both variables to nil breaks strong references, so both objects deinit and print messages.

3. Final Answer:

   Person John is being deinitialized Apartment 4A is being deinitialized -> Option A

4. Quick Check:

   Weak reference avoids cycle, both deinit [OK]

Hint: Weak reference breaks cycle; both objects deinit when nil [OK]

Common Mistakes:

• Expecting memory leak output
• Thinking only one object deinitializes
• Ignoring weak reference effect

4.

Identify the error in the following Swift code that causes a strong reference cycle:

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

class CreditCard {
    let number: UInt64
    var customer: Customer?
    init(number: UInt64) { self.number = number }
    deinit { print("CreditCard \(number) is being deinitialized") }
}

var alice: Customer? = Customer(name: "Alice")
var card: CreditCard? = CreditCard(number: 1234567890123456)
alice!.card = card
card!.customer = alice
alice = nil
card = nil

medium

A. CreditCard's customer property should be declared weak to avoid cycle.

B. Customer's card property should be declared weak to avoid cycle.

C. Both properties should be unowned to avoid cycle.

D. No error; code works fine without changes.

Solution

1. Step 1: Identify reference types

   Both Customer.card and CreditCard.customer are strong references by default.

2. Step 2: Find cycle cause

   Since both hold strong references, they create a cycle preventing deallocation.

3. Step 3: Fix cycle

   Declaring CreditCard.customer as weak var customer: Customer? breaks the cycle.

4. Final Answer:

   CreditCard's customer property should be declared weak to avoid cycle. -> Option A

5. Quick Check:

   Weak reference breaks cycle [OK]

Hint: Make one side weak to break cycle, usually the back reference [OK]

Common Mistakes:

• Making both references weak
• Making the wrong property weak
• Ignoring the cycle causing deallocation failure

5.

You have two classes, Owner and Car. The Owner has a strong reference to Car, and Car has a strong reference to Owner. You want to avoid a strong reference cycle but also ensure that Car always has an Owner during its lifetime. How should you declare the reference from Car to Owner?

hard

A. Declare the reference as weak var owner: Owner (non-optional)

B. Declare the reference as unowned var owner: Owner

C. Declare the reference as var owner: Owner (strong reference)

D. Declare the reference as weak var owner: Owner?

Solution

1. Step 1: Understand ownership requirements

   Since Car must always have an Owner during its lifetime, the reference cannot be optional.

2. Step 2: Choose reference type

   unowned references are non-optional and do not increase reference count, avoiding cycles.

3. Step 3: Apply declaration

   Declare unowned var owner: Owner in Car to avoid cycle and ensure non-optional reference.

4. Final Answer:

   Declare the reference as unowned var owner: Owner -> Option D

5. Quick Check:

   Unowned + non-optional = correct for guaranteed lifetime [OK]

Hint: Use unowned for non-optional back references to avoid cycles [OK]

Common Mistakes:

• Using weak with non-optional type (invalid)
• Using strong reference causing cycle
• Using weak optional when non-optional needed