Swift Fundamentals

ARC and Memory Management

Understand object lifetime, strong reference cycles, and the careful use of weak and unowned references.

Beginner4 min read2 guided activities

Before you begin

What you will understand

Explain how ARC manages class instances.
Identify a strong reference cycle.
Use weak references for optional non-owning relationships.
Apply weak self thoughtfully in closures.

Learning stage

Concept Explanation

Automatic Reference Counting, or ARC, tracks strong references to class instances. An instance remains alive while at least one strong reference owns it, and its deinitializer runs after the final strong reference is removed. Value types do not use identity-based reference counting in the same way.

A memory leak can occur when objects or closures strongly retain one another. Use weak when a reference may become nil and should not own the target. Use unowned only when the target is guaranteed to outlive the reference; a wrong guarantee can crash. Capture lists let closures express these ownership choices.

strong: owns and keeps an instance alive.
weak: non-owning, optional, and automatically becomes nil.
unowned: non-owning and non-optional, based on a lifetime guarantee.
capture list: controls how a closure captures surrounding references.

Learning stage

Syntax & Examples

The coordinator owns the screen, but the screen does not own its coordinator.

Coordinator.swiftswift

final class Coordinator {
  var screen: Screen?
  deinit { print("Coordinator released") }
}

final class Screen {
  weak var coordinator: Coordinator?
  deinit { print("Screen released") }
}

var coordinator: Coordinator? = Coordinator()
let screen = Screen()
coordinator?.screen = screen
screen.coordinator = coordinator
coordinator = nil

The weak back-reference prevents a cycle, so the coordinator can be released when its owner sets it to nil.

Learning stage

Real-World Usage

These concepts appear throughout production iOS code. Focus on the requirement each technique communicates.

Create delegate and coordinator relationships without cycles.
Avoid retaining a view controller or view model in a long-lived callback.
Use Instruments and deinit logging to investigate objects that remain alive.
Cancel tasks, observations, or subscriptions when an owner ends.

Learning stage

Common Mistakes

Notice these mistakes early so the compiler and type system can help instead of becoming obstacles.

Adding [weak self] to every closure without considering its lifetime.
Using unowned when the referenced object may be released first.
Assuming setting one property to nil breaks every ownership path.
Debugging leaks without checking tasks, timers, observers, and stored closures.

Learning stage

Practice Exercises

Work through these activities in a small Xcode project. No embedded playground is required on this site.

Activity 1

Break a reference cycle

Create Parent and Child classes that strongly reference each other. Observe deinit, then change the back-reference to weak and compare.

Hint: A weak property must be declared with var and an optional type.

Activity 2

Choose a closure capture

For an immediately executed closure and a stored asynchronous callback, decide whether strong, weak, or unowned capture is appropriate and explain why.

Hint: Base the choice on ownership and lifetime, not habit.

Learning stage

Knowledge Check

Answer each question before revealing the explanation.

QUESTION 1

What happens to a weak reference when its object is deallocated?

A.It becomes nil
B.It keeps the object alive
C.It becomes a new object
D.It always crashes

Reveal answer

It becomes nil

Weak references are optional non-owning references that ARC clears automatically.

QUESTION 2

What causes a strong reference cycle?

Reveal answer

Two or more ownership paths keep one another strongly referenced so their counts never reach zero.

ARC cannot infer which strong ownership link should be broken.

Learning stage

Interview Preparation

Explain the idea in terms of its purpose, behavior, and tradeoffs rather than reciting syntax.

Should every escaping closure capture self weakly?

Short answer: No. Choose capture semantics from the intended ownership and lifetime relationship.

Explore the detailed answer

Weak self is appropriate when the closure may outlive its owner and should not keep that owner alive. A closure owned by a short operation may need a strong capture to complete useful work. Blindly using weak can make required work disappear or spread optional handling without solving a real cycle.

Possible follow-ups

• When is unowned appropriate?
• How would you investigate a suspected leak?

Learning stage

Key Takeaways

ARC automates reference counting, not ownership design. Model which object owns which lifetime, break cycles with justified non-owning references, and verify behavior rather than applying weak mechanically.

Strong references keep class instances alive.
Cycles prevent reference counts from reaching zero.
weak is optional and becomes nil automatically.
Capture lists should express the intended lifetime relationship.