Unowned references for guaranteed lifetime in Swift - Step-by-Step Execution

Concept Flow - Unowned references for guaranteed lifetime

Create Object A

↓

Create Object B

↓

Assign unowned reference from B to A

↓

Use unowned reference

↓

Objects deallocate safely

↓

No strong reference cycle

This flow shows creating two objects where one holds an unowned reference to the other, ensuring no strong cycle and safe deallocation.

Execution Sample

Swift

class Owner {
    var pet: Pet?
}

class Pet {
    unowned let owner: Owner
    init(owner: Owner) { self.owner = owner }
}

let owner = Owner()
owner.pet = Pet(owner: owner)

This code creates an Owner and a Pet where Pet holds an unowned reference to Owner, avoiding strong reference cycles.

Execution Table

Step	Action	Variable States	Reference Types	Notes
1	Create Owner instance	owner: Owner instance	Strong reference to Owner	Owner object created in memory
2	Create Pet instance with unowned owner	pet: Pet instance, pet.owner unowned reference to owner	Strong reference to Pet, unowned reference from Pet to Owner	Pet holds unowned reference to Owner
3	Assign pet to owner.pet	owner.pet points to pet	Strong reference from owner to pet	Owner strongly owns Pet
4	Use pet.owner	Access pet.owner	Unowned reference access	Safe access because owner exists
5	Deallocate owner and pet	owner and pet deallocated	No strong reference cycle	Objects deallocate safely

💡 Execution stops after objects deallocate safely with no memory leaks due to unowned reference.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5
owner	nil	Owner instance	Owner instance	Owner instance	nil (deallocated)
pet	nil	nil	Pet instance	Pet instance	nil (deallocated)
pet.owner (unowned)	nil	nil	Points to owner	Points to owner	nil (deallocated)

Key Moments - 3 Insights

Why is pet.owner declared as unowned instead of strong?

Because owner already strongly owns pet, making pet.owner unowned avoids a strong reference cycle, as shown in execution_table step 2 and 3.

What happens if owner is deallocated before pet?

Accessing pet.owner would cause a runtime error because unowned references assume the referenced object exists, so owner must outlive pet (see execution_table step 5).

Why is it safe to access pet.owner without optional unwrapping?

Because unowned references guarantee the referenced object exists during pet's lifetime, so no need for optional checks (see execution_table step 4).

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the unowned reference from pet to owner established?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check the 'Reference Types' column in execution_table rows to see when pet.owner is assigned.

According to variable_tracker, what is the state of 'owner' after step 5?

A Owner is unowned

B Owner instance still exists

C Owner is nil (deallocated)

D Owner is strongly referenced by pet

💡 Hint

Look at the 'owner' row in variable_tracker under 'After Step 5'.

If pet.owner was a strong reference instead of unowned, what would happen?

A Strong reference cycle causing memory leak

B Pet would deallocate before owner

C No change in memory management

D Owner would be nil immediately

💡 Hint

Refer to key_moments about strong reference cycles and execution_table steps 2 and 3.

Concept Snapshot

Unowned references hold a non-owning link to another object.
They avoid strong reference cycles when one object must outlive the other.
Use unowned when the referenced object is guaranteed to exist.
Accessing unowned references is safe without optionals.
If the referenced object is deallocated first, accessing unowned causes a crash.

Full Transcript

This visual execution traces how unowned references work in Swift to avoid strong reference cycles. First, an Owner object is created with a strong reference. Then a Pet object is created with an unowned reference back to the Owner. The Owner strongly owns the Pet, but the Pet only holds an unowned reference to the Owner. This setup prevents a memory leak. The execution table shows each step: creation, assignment, usage, and deallocation. The variable tracker shows how variables change over time. Key moments clarify why unowned is used and the importance of object lifetimes. The quiz tests understanding of when references are set and the consequences of using strong instead of unowned references. The snapshot summarizes the key points about unowned references and their safe use in Swift.

Practice

1. What is the main purpose of using unowned references in Swift?

easy

A. To automatically nil out the reference when the object is deallocated

B. To create a strong reference that keeps the object alive

C. To make a copy of the referenced object

D. To refer to another object without increasing its lifetime

Solution

1. Step 1: Understand what unowned means

   unowned references do not increase the lifetime of the object they point to.

2. Step 2: Compare with other reference types

   Unlike strong references, unowned does not keep the object alive, and unlike weak references, it assumes the object will always exist during use.

3. Final Answer:

   To refer to another object without increasing its lifetime -> Option D

4. Quick Check:

   Unowned references = no lifetime increase [OK]

Hint: Unowned means no lifetime increase, but object must exist [OK]

Common Mistakes:

• Confusing unowned with strong references
• Thinking unowned automatically nils out
• Assuming unowned copies the object

2. Which of the following is the correct syntax to declare an unowned reference to an instance of class Person named friend?

easy

A. unowned var friend: Person

B. var friend: unowned Person

C. var friend: Person unowned

D. var unowned friend: Person

Solution

1. Step 1: Recall Swift syntax for unowned references

   The correct syntax places unowned before the variable declaration: unowned var variableName: Type.

2. Step 2: Match the options

   unowned var friend: Person matches this syntax exactly: unowned var friend: Person.

3. Final Answer:

   unowned var friend: Person -> Option A

4. Quick Check:

   Unowned keyword before var = correct syntax [OK]

Hint: Put 'unowned' before 'var' for correct syntax [OK]

Common Mistakes:

• Placing 'unowned' after the variable name
• Using 'var' after 'unowned' incorrectly
• Writing 'unowned' after the type

3. Consider the following Swift code snippet:

class Owner {
    var pet: Pet?
}

class Pet {
    unowned var owner: Owner
    init(owner: Owner) {
        self.owner = owner
    }
}

let owner = Owner()
owner.pet = Pet(owner: owner)
print(owner.pet?.owner === owner)

What will be the output?

medium

A. true

B. false

C. nil

D. Runtime error

Solution

1. Step 1: Understand the relationship between Owner and Pet

   Owner has an optional Pet, and Pet has an unowned reference back to Owner, meaning Pet expects Owner to exist while Pet exists.

2. Step 2: Analyze the print statement

   The print checks if the owner property of pet is the same instance as owner using identity operator ===. Since pet.owner was set to owner, this is true.

3. Final Answer:

   true -> Option A

4. Quick Check:

   Unowned reference points to existing object = true [OK]

Hint: Unowned references assume object exists, so identity check is true [OK]

Common Mistakes:

• Thinking unowned makes owner nil
• Confusing identity operator with equality
• Expecting runtime error due to unowned

4. Given the code below, what is the main issue causing a runtime crash?

class A {
    unowned var b: B
    init(b: B) {
        self.b = b
    }
}

class B {
    var a: A?
}

var bInstance: B? = B()
var aInstance: A? = A(b: bInstance!)
bInstance?.a = aInstance

bInstance = nil
print(aInstance!.b)
aInstance = nil

medium

A. Optional unwrapping failure

B. Unowned reference b is accessed after B is deallocated

C. Syntax error in unowned declaration

D. Strong reference cycle causing memory leak

Solution

1. Step 1: Understand the unowned reference lifetime

   The unowned reference b in class A assumes B instance exists as long as A exists.

2. Step 2: Analyze object deallocation order

   When bInstance is set to nil, B is deallocated, but A remains alive (held by aInstance). Thus b in A points to deallocated B, and print(aInstance!.b) accesses it, causing crash.

3. Final Answer:

   Unowned reference b is accessed after B is deallocated -> Option B

4. Quick Check:

   Unowned must not outlive referenced object [OK]

Hint: Unowned crashes if referenced object is gone first [OK]

Common Mistakes:

• Confusing unowned with weak references
• Ignoring object deallocation order
• Assuming unowned prevents crashes automatically

5. You have two classes, Teacher and Student, where each Student has an unowned reference to their Teacher, and each Teacher has a strong array of Student instances. Which of the following best explains why using unowned for the Student to Teacher reference is appropriate?

hard

A. Because unowned references automatically nil out when the Teacher is deallocated

B. Because the Student might outlive the Teacher, so unowned avoids nil references

C. Because the Teacher always exists as long as the Student exists, preventing strong reference cycles

D. Because unowned references increase the lifetime of the Teacher to match the Student

Solution

1. Step 1: Understand the lifetime relationship

   The Teacher owns the Student strongly, so the Teacher will exist as long as the Student does.

2. Step 2: Why use unowned here?

   Using unowned for the Student to Teacher reference avoids a strong reference cycle because Student does not keep Teacher alive.

3. Final Answer:

   Because the Teacher always exists as long as the Student exists, preventing strong reference cycles -> Option C

4. Quick Check:

   Unowned = guaranteed lifetime, no cycle [OK]

Hint: Use unowned when referenced object lifetime is guaranteed [OK]

Common Mistakes:

• Thinking unowned nils out automatically
• Assuming unowned increases lifetime
• Using unowned when referenced object may be nil