Why ARC matters for Swift developers - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a strong reference to an instance.

Swift

class Person {
    var name: String
    init(name: String) {
        self.name = name
    }
}

var person1: Person? = Person(name: "Alice")
var person2 = [1]

Drag options to blanks, or click blank then click option'

Aperson1

Bnil

Cself

DPerson()

Attempts:

3 left

💡 Hint

Common Mistakes

Assigning nil instead of the existing instance.

Creating a new instance instead of referencing the existing one.

Assigning person1 to person2 creates a strong reference to the same instance.

2fill in blank

medium

Complete the code to declare a weak reference to avoid a strong reference cycle.

Swift

class Person {
    var name: String
    weak var friend: Person? // Avoid strong reference cycle
    init(name: String) {
        self.name = name
    }
}

var alice: Person? = Person(name: "Alice")
var bob: Person? = Person(name: "Bob")
alice?.friend = [1]

Drag options to blanks, or click blank then click option'

Abob

Balice

Cnil

DPerson(name: "Bob")

Attempts:

3 left

💡 Hint

Common Mistakes

Assigning nil instead of the other instance.

Assigning a new instance instead of the existing one.

Assigning bob to alice?.friend as a weak reference prevents a strong reference cycle.

3fill in blank

hard

Fix the error in the code to prevent a strong reference cycle using unowned reference.

Swift

class Customer {
    let name: String
    var card: CreditCard?
    init(name: String) {
        self.name = name
    }
}

class CreditCard {
    let number: UInt64
    unowned let customer: [1]
    init(number: UInt64, customer: Customer) {
        self.number = number
        self.customer = customer
    }
}

var john: Customer? = Customer(name: "John Appleseed")
john?.card = CreditCard(number: 1234_5678_9012_3456, customer: john!)

Drag options to blanks, or click blank then click option'

AString

BCreditCard

CCustomer

DAnyObject

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong class type for the unowned reference.

Using a value type like String instead of a class.

The unowned reference must be of the class type Customer to avoid a strong reference cycle.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that stores word lengths only for words longer than 3 characters.

Swift

let words = ["apple", "bat", "car", "dolphin"]
let lengths = words.reduce(into: [:]) { dict, word in
    if word.count [1] 3 {
        dict[word] = [2]
    }
}

Drag options to blanks, or click blank then click option'

A>

Bword.count

C<

Dword

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong comparison operator.

Assigning the word itself instead of its length.

The condition word.count > 3 filters words longer than 3 characters, and word.count stores their lengths.

5fill in blank

hard

Fill all three blanks to create a dictionary of uppercase keys and values for words longer than 4 characters.

Swift

let words = ["swift", "code", "apple", "bug"]
let result = words.reduce(into: [:]) { dict, word in
    if word.count [1] 4 {
        dict[[2]] = [3]
    }
}

Drag options to blanks, or click blank then click option'

A>

Bword.uppercased()

Cword

D<

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong comparison operator.

Swapping keys and values.

The condition word.count > 4 filters words longer than 4 characters. The dictionary keys are uppercase words, and values are the original words.

Practice

1. What is the main purpose of Automatic Reference Counting (ARC) in Swift?

easy

A. To automatically manage memory by tracking object references

B. To optimize the speed of Swift code execution

C. To handle user interface layout automatically

D. To compile Swift code into machine language

Solution

1. Step 1: Understand ARC's role in memory management

   ARC tracks how many references point to an object to manage its memory automatically.

2. Step 2: Differentiate ARC from other tasks

   ARC does not optimize speed, handle UI layout, or compile code; it focuses on memory.

3. Final Answer:

   To automatically manage memory by tracking object references -> Option A

4. Quick Check:

   ARC = memory management [OK]

Hint: ARC counts references to manage memory automatically [OK]

Common Mistakes:

• Confusing ARC with code compilation
• Thinking ARC manages UI layout
• Assuming ARC improves execution speed

2. Which of the following is the correct way to declare a weak reference in Swift?

easy

A. var delegate: weak MyDelegate?

B. weak var delegate: MyDelegate?

C. var weak delegate: MyDelegate?

D. var delegate: MyDelegate weak?

Solution

1. Step 1: Recall Swift syntax for weak references

   In Swift, the keyword weak comes before the variable declaration type.

2. Step 2: Check each option's syntax

   weak var delegate: MyDelegate? correctly places weak before var and the type, matching Swift syntax.

3. Final Answer:

   weak var delegate: MyDelegate? -> Option B

4. Quick Check:

   Weak reference syntax = "weak var" [OK]

Hint: Use 'weak var' before the variable name for weak references [OK]

Common Mistakes:

• Placing 'weak' after the variable name
• Using 'var weak' instead of 'weak var'
• Omitting the optional '?' for weak references

3. Consider the following Swift code:

class Person {
    var name: String
    init(name: String) {
        self.name = name
    }
}

var person1: Person? = Person(name: "Alice")
var person2 = person1
person1 = nil
print(person2?.name ?? "No name")

What will be printed?

medium

A. Runtime error

B. "No name"

C. nil

D. "Alice"

Solution

1. Step 1: Understand reference counting in the code

   Both person1 and person2 point to the same Person object initially, so reference count is 2.

2. Step 2: Analyze effect of setting person1 to nil

   Setting person1 to nil reduces reference count to 1, but person2 still holds the object.

3. Step 3: Determine print output

   Since person2 still references the object, person2?.name is "Alice".

4. Final Answer:

   "Alice" -> Option D

5. Quick Check:

   Reference count > 0 means object exists [OK]

Hint: Object stays alive if any strong reference exists [OK]

Common Mistakes:

• Assuming object is deallocated when one reference is nil
• Confusing optional chaining output
• Expecting runtime error due to nil assignment

4. Given this Swift code snippet, what is the main problem?

class Node {
    var value: Int
    var next: Node?
    init(value: Int) {
        self.value = value
    }
}

var first: Node? = Node(value: 1)
var second: Node? = Node(value: 2)
first?.next = second
second?.next = first

medium

A. Syntax error in class definition

B. Runtime crash due to nil unwrapping

C. Strong reference cycle causing memory leak

D. No problem, code runs fine

Solution

1. Step 1: Identify references between nodes

   first points to second, and second points back to first, creating a cycle.

2. Step 2: Understand ARC impact of strong cycles

   Both nodes hold strong references to each other, so ARC cannot deallocate them, causing a memory leak.

3. Final Answer:

   Strong reference cycle causing memory leak -> Option C

4. Quick Check:

   Strong cycles = memory leaks [OK]

Hint: Check for mutual strong references causing leaks [OK]

Common Mistakes:

• Thinking this causes syntax errors
• Assuming ARC handles cycles automatically
• Ignoring possibility of memory leaks

5. You have two classes, Teacher and Student, where each Teacher has a list of Student objects, and each Student has a reference to their Teacher. How should you declare these references to avoid memory leaks caused by ARC?

hard

A. Declare Teacher's students as strong and Student's teacher as weak

B. Declare both references as strong

C. Declare Teacher's students as weak and Student's teacher as strong

D. Declare both references as weak

Solution

1. Step 1: Identify ownership direction

   The Teacher owns the list of Student objects, so this should be a strong reference.

2. Step 2: Avoid strong cycle by making reverse reference weak

   The Student references back to Teacher should be weak to prevent a strong reference cycle.

3. Final Answer:

   Declare Teacher's students as strong and Student's teacher as weak -> Option A

4. Quick Check:

   Strong ownership one way, weak back reference [OK]

Hint: Make back references weak to break strong cycles [OK]

Common Mistakes:

• Making both references strong causing leaks
• Making both references weak causing premature deallocation
• Confusing which side should be weak