Why ARC matters for Swift developers - Challenge Your Understanding

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Swift code involving ARC?

Consider the following Swift code that uses classes and ARC. What will be printed when the code runs?

Swift

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

var person1: Person? = Person(name: "Alice")
var person2 = person1
person1 = nil
print("person1 is set to nil")
person2 = nil
print("person2 is set to nil")

A

Alice is initialized
person1 is set to nil
Alice is being deinitialized
person2 is set to nil

B

Alice is initialized
Alice is being deinitialized
person1 is set to nil
person2 is set to nil

C

person1 is set to nil
person2 is set to nil
Alice is initialized
Alice is being deinitialized

D

Alice is initialized
person1 is set to nil
person2 is set to nil
Alice is being deinitialized

💡 Hint

Think about when ARC releases the object based on strong references.

The Person instance is created and initialized first. Both person1 and person2 point to it, so ARC count is 2. Setting person1 to nil reduces count to 1, so the object stays alive. Setting person2 to nil reduces count to 0, so the object is deinitialized last.

🧠 Conceptual

intermediate

Why does ARC prevent memory leaks in Swift?

Which statement best explains why ARC helps prevent memory leaks in Swift?

A ARC automatically frees memory when there are no more strong references to an object.

B ARC requires manual calls to free memory after using an object.

C ARC duplicates objects to avoid memory leaks.

D ARC disables reference counting for value types.

💡 Hint

Think about how ARC tracks object usage.

ARC tracks how many strong references point to an object and frees it automatically when none remain, preventing memory leaks.

🔧 Debug

advanced

Identify the cause of the memory leak in this Swift code

This Swift code creates a memory leak. What causes the leak?

Swift

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

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

var person: Person? = Person(name: "Bob")
var apartment: Apartment? = Apartment(unit: "4A")
person!.apartment = apartment
apartment!.tenant = person

person = nil
apartment = nil

A Strong reference cycle between Person and Apartment causing neither to be deinitialized.

B The classes use value types instead of reference types.

C The variables person and apartment are not set to nil properly.

D The deinit methods are missing calls to free memory.

💡 Hint

Look at how the two classes reference each other.

Person and Apartment hold strong references to each other, creating a cycle. ARC cannot free either object because their reference counts never reach zero, causing a memory leak.

📝 Syntax

advanced

Which option correctly declares a weak reference in Swift?

You want to avoid a strong reference cycle by declaring a weak reference. Which of the following is the correct syntax?

A var delegate weak: SomeDelegate?

B var weak delegate: SomeDelegate?

C weak var delegate: SomeDelegate?

D var delegate: weak SomeDelegate?

💡 Hint

The weak keyword comes before var or let.

In Swift, weak references are declared by placing the 'weak' keyword before 'var' or 'let'. The other options have incorrect syntax.

🚀 Application

expert

How many times is the deinit method called in this Swift ARC example?

Given the following Swift code, how many times will the deinit method be called when the program finishes?

Swift

class Node {
    let value: Int
    var next: Node?
    init(value: Int) { self.value = value }
    deinit { print("Node \(value) is deinitialized") }
}

var first: Node? = Node(value: 1)
var second: Node? = Node(value: 2)
var third: Node? = Node(value: 3)

first!.next = second
second!.next = third
third!.next = first

first = nil
second = nil
third = nil

A 2 times

B 0 times

C 3 times

D 1 time

💡 Hint

Consider the strong reference cycle created by the next pointers.

The nodes form a strong reference cycle (each node points to the next, and the last points back to the first). Setting first, second, and third to nil does not break the cycle, so none of the nodes are deinitialized.