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.