Strong reference cycles between classes in Swift - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of code with strong reference cycle

What will be printed when this Swift code runs?

Swift

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

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

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

john = nil
unit4A = nil

A

Person John Appleseed is initialized
Apartment 4A is initialized
Person John Appleseed is being deinitialized

B

Person John Appleseed is initialized
Apartment 4A is initialized
Person John Appleseed is being deinitialized
Apartment 4A is being deinitialized

C

Person John Appleseed is initialized
Apartment 4A is initialized

D No output, program crashes

💡 Hint

Think about what happens when two objects hold strong references to each other.

Because Person and Apartment hold strong references to each other, neither is deinitialized when john and unit4A are set to nil. This causes a strong reference cycle, so the deinit methods are not called.

❓ Predict Output

intermediate

Breaking strong reference cycle with weak reference

What will be printed when this Swift code runs?

Swift

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

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

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

john = nil
unit4A = nil

A

Person John Appleseed is initialized
Apartment 4A is initialized
Person John Appleseed is being deinitialized
Apartment 4A is being deinitialized

B

Person John Appleseed is initialized
Apartment 4A is initialized

C

Person John Appleseed is initialized
Apartment 4A is initialized
Apartment 4A is being deinitialized

D

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

💡 Hint

Look at the keyword used for the tenant property.

Using weak for tenant breaks the strong reference cycle. When john and unit4A are set to nil, both objects are deinitialized and their deinit messages print.

🔧 Debug

advanced

Identify the cause of memory leak

Why does this Swift code cause a memory leak?

Swift

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: 1234_5678_9012_3456)
alice!.card = card
card!.customer = alice

alice = nil
card = nil

A Because the CreditCard number is too large and causes overflow.

B Because both Customer and CreditCard hold strong references to each other, causing a strong reference cycle.

C Because the Customer class does not implement deinit properly.

D Because the variables alice and card are declared as optional.

💡 Hint

Check how the references between Customer and CreditCard are declared.

Both Customer and CreditCard hold strong references to each other through their properties. This creates a strong reference cycle, preventing deinitialization and causing a memory leak.

❓ Predict Output

advanced

Output with unowned reference to break cycle

What will be printed when this Swift code runs?

Swift

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

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

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

A

Customer Alice is initialized
CreditCard 1234567890123456 is initialized
Customer Alice is being deinitialized
CreditCard 1234567890123456 is being deinitialized

B

Customer Alice is initialized
CreditCard 1234567890123456 is initialized
Customer Alice is being deinitialized

C

Customer Alice is initialized
CreditCard 1234567890123456 is initialized
CreditCard 1234567890123456 is being deinitialized

D Runtime error due to unowned reference being nil

💡 Hint

Unowned references do not increase reference count but assume the referenced object exists.

Using unowned for customer breaks the strong reference cycle. When alice is set to nil, both Customer and CreditCard are deinitialized and their messages print.

🧠 Conceptual

expert

Choosing between weak and unowned references

Which statement best describes when to use weak versus unowned references in Swift to avoid strong reference cycles?

A Use weak when the reference is optional; use unowned when the reference is always nil.

B Use weak only for classes and unowned only for structs.

C Use unowned when you want the reference to increase the reference count; use weak when you want to decrease it.

D Use weak when the reference can become nil during its lifetime; use unowned when the reference is expected to always have a value after initialization.

💡 Hint

Think about whether the reference might become nil or not during the object's lifetime.

Weak references are optional and can become nil, so they are used when the referenced object might be deallocated first. Unowned references are non-optional and used when the referenced object is expected to always exist during the lifetime of the referencing object.