Common Swift Interview Questions

Swift interviews rarely test syntax trivia in isolation — they probe whether you understand *why* Swift is designed the way it is. Interviewers use questions about optionals, value semantics, and memory management to see if you can reason about safety and performance trade-offs, not just recite definitions. This set of questions covers the topics that come up in almost every iOS or Swift engineering interview, from junior to senior level.

An optional is a type that can hold either a value or nil, written as Int? or String?. Swift introduced optionals to make the absence of a value an explicit, compiler-checked part of the type system, rather than allowing any reference to silently be null as in Objective-C or Java. This eliminates an entire class of null-pointer crashes at compile time: you cannot use an optional's value without first unwrapping it, so the compiler forces you to handle the 'no value' case.

Structs are value types: when you assign or pass one, you get an independent copy, and structs cannot be subclassed. Classes are reference types: assigning or passing a class instance shares the same underlying object, and classes support inheritance, deinitializers, and reference counting. Apple recommends structs by default for data models because value semantics prevent unexpected shared mutation, and reserving classes for cases that need identity, inheritance, or Objective-C interoperability.

Both weak and unowned create a non-owning reference so two objects don't keep each other alive forever (a retain cycle). weak references are always optional and automatically become nil when the referenced object is deallocated, making them safe for relationships where the other object's lifetime is independent, such as a delegate. unowned references are non-optional and assume the referenced object will always outlive the reference; accessing an unowned reference after its target has been deallocated causes a crash, so it's used only when you can guarantee that lifetime relationship, such as a child object referencing its owning parent.

Use guard let when a condition must be true for the rest of the function to make sense — it unwraps a value and requires an early exit (return, throw, continue, or break) in the else branch, and the unwrapped value stays in scope for the remainder of the function. Use if let when the unwrapped value is only needed inside a limited block and the rest of the function should still execute regardless of the outcome. guard reduces nesting and communicates preconditions up front, which is why many style guides prefer it for early validation.

Force unwrapping with ! tells the compiler 'trust me, this optional definitely has a value.' If that assumption is wrong, the app crashes immediately with a runtime trap rather than failing gracefully. It bypasses all of the compile-time safety optionals are meant to provide, so it should be reserved for cases where a nil value truly represents a programmer error (such as a force-cast on a value you constructed yourself), not for handling data that can legitimately be absent, like network responses or user input.

Protocol-oriented programming (POP) favors composing behavior through protocols and protocol extensions rather than building deep class inheritance hierarchies. Because protocols in Swift can provide default implementations via extensions, and because both structs and enums (not just classes) can conform to protocols, POP lets you share behavior across value types without forcing everything into a class-based 'is-a' relationship. Classical OOP relies on subclassing for code reuse, which can create rigid hierarchies and the fragile base class problem; POP favors 'has-a protocol conformance' composition, which tends to be more flexible.

These are higher-order functions on Swift's collection types. map transforms every element and returns a new collection of the transformed values. filter returns a new collection containing only the elements that satisfy a given predicate. reduce combines all elements into a single value by repeatedly applying a combining closure, starting from an initial value. All three return new collections or values rather than mutating the original, which fits Swift's preference for value semantics and predictable data flow.

ARC deallocates a class instance deterministically, the moment its reference count drops to zero, by inserting retain and release calls at compile time. Garbage collection, used by languages like Java and C#, instead runs periodically at runtime to trace and reclaim unreachable objects, which is less predictable in timing and can introduce pause overhead but doesn't require the programmer to reason about reference cycles. ARC's trade-off is that it requires developers to explicitly break strong reference cycles with weak or unowned, since ARC cannot detect and collect cycles on its own.

By default, a closure passed as a function parameter is non-escaping, meaning it's guaranteed to be called before the function returns, so the compiler can optimize its memory handling. An @escaping closure is one that may be called after the function it was passed to has already returned — typically because it's stored in a property or passed to an asynchronous API like a network callback. Because the closure can outlive the function call, it needs to be explicitly marked @escaping, and if it captures self, that usually requires deciding whether to capture it strongly or weakly to avoid a retain cycle.

A Swift enum case can carry additional data specific to that case, called an associated value — for example case success(Data) versus case failure(Error). This lets an enum model a set of mutually exclusive states while carrying exactly the data relevant to each state, which is a common way to represent things like network results, navigation destinations, or parsing outcomes. Combined with switch, associated values let the compiler enforce that every case, and its data, is handled explicitly.

Completion handler closures let asynchronous code run non-blocking, but chaining several of them leads to deep nesting ('callback pyramids'), makes error handling repetitive, and gives the compiler no way to enforce that the handler is called exactly once. async/await, introduced in Swift 5.5, lets you write asynchronous code in a linear, sequential style: you await a call and the compiler suspends execution until it completes, while try/catch handles errors the same way it does in synchronous code. Under the hood it still avoids blocking threads, but it reads like straight-line code and eliminates a whole category of completion-handler bugs.