Answer.

Background:

With the development of Objective-C and the emergence of Swift, Apple faced the challenge of automatic and safe memory management in applications without requiring explicit programmer interaction with retain/release commands. Swift uses Automatic Reference Counting (ARC), which tracks the number of references to class objects and automatically frees memory when the last owner disappears.

Problem:

Since Swift is a multi-paradigm language, it operates with both value types (struct, enum) and reference types (class). For the latter, it is crucial that memory is cleared in a timely manner; otherwise, memory leaks may occur. A complex scenario arises with retain cycles, where two objects reference each other, preventing ARC from freeing memory.

Solution:

Swift applies ARC only to class objects. When the number of references becomes 0, memory is released. To solve the problem of retain cycles, the keywords weak/unowned are used.

Example code:

class Person {
    var name: String
    var pet: Pet?
    init(name: String) {
        self.name = name
    }
    deinit {
        print("\(name) is being deinitialized")
    }
}

class Pet {
    var owner: Person?
    init() {}
    deinit {
        print("Pet is being deinitialized")
    }
}

var tom: Person? = Person(name: "Tom")
var cat: Pet? = Pet()
tom!.pet = cat
cat!.owner = tom

tom = nil
cat = nil // Both objects are NOT released due to retain cycle

Key features:

• Memory management is transparent to the developer.
• Only classes are supported; structs and enums are not tracked by references.
• weak and unowned are used to solve retain cycles.

Tricky questions.

Can ARC be applied to value types?

No, ARC only tracks references to class objects. Structs and enums are passed by value, and Swift automatically frees their memory (usually when going out of scope).

What will happen if weak/unowned is not used in the properties of two mutually referencing objects?

A retain cycle will occur, which means ARC will never free the memory for these objects. Such code will lead to a memory leak — always use weak (or unowned) for at least one side of such a connection.

What is the purpose of unowned if weak exists?

unowned is needed in cases where the reference must always exist during the lifespan of another object and should never become nil. weak is a nil-able reference, while unowned is non-nil-able but does not increase the retain count.

Example code:

class A {
    var b: B?
}
class B {
    unowned var a: A // never nil during B's life
}

Common mistakes and anti-patterns

• Using strong references where weak/unowned are needed.
• Forgetting about ARC when working with classes and arrays/dictionaries containing objects.
• Attempting to manually free memory for value types or using weak for structs/enums.

Real-life example

Negative case

Two controllers hold strong references to each other: one through a delegate property, and the other through an array of child controllers. The creator does not use weak for the delegate.

Pros: Errors are not immediately visible; everything "works" at first glance.

Cons: As the application scales, memory is not freed, leaks occur; with limited memory, crashes may happen.

Positive case

The delegate and event observer are set up as weak, and the array of controllers is cleaned up as controllers disappear. Everything is well documented.

Pros: No leaks, all objects are released in a timely manner, no performance loss.

Cons: The delegate may be lost unexpectedly (if a strong reference is forgotten somewhere above); requires attention during application architecture.