A Different Way to Think About Data

Most developers learn to transform data with loops. Iterate, check a condition, append to a result array, return it. It works. It is also verbose, stateful, and harder to test than it needs to be.

Functional programming offers a different mental model. Instead of describing how to transform data step by step, you describe what the transformation is. The result is code that is shorter, more readable, and easier to combine into pipelines.

Swift has first-class support for this style. You have been using the pieces since Article 7 (closures). Now they come together.

map: Transform Every Element

map applies a transformation to every element and returns a new collection.

let prices = [10.0, 25.0, 8.5, 42.0]

// Loop style
var discounted: [Double] = []
for price in prices {
    discounted.append(price * 0.9)
}

// Functional style
let discounted = prices.map { $0 * 0.9 }
// [9.0, 22.5, 7.65, 37.8]

Same result. The functional version says exactly what it is: a 10% discount applied to every price. No accumulator variable, no loop management, no mutation.

let usernames = ["aryan", "riya", "dev"]
let displayNames = usernames.map { $0.capitalized }
// ["Aryan", "Riya", "Dev"]

struct User { let id: Int; let name: String }
let users = [User(id: 1, name: "Aryan"), User(id: 2, name: "Riya")]
let names = users.map { $0.name }
// ["Aryan", "Riya"]

map works on any Sequence and always returns an array of the same length.

filter: Keep What Passes

filter returns only the elements that satisfy a condition.

let scores = [45, 78, 92, 61, 88, 34, 95]

let passing = scores.filter { $0 >= 60 }
// [78, 92, 61, 88, 95]
let products = [
    Product(name: "Swift Book", inStock: true),
    Product(name: "Keyboard", inStock: false),
    Product(name: "Monitor", inStock: true)
]
let available = products.filter { $0.inStock }
// [Swift Book, Monitor]

The closure returns Bool. Elements that return true are kept. Elements that return false are dropped.

reduce: Collapse to a Single Value

reduce takes a collection and produces a single result by combining elements one at a time.

let numbers = [1, 2, 3, 4, 5]
let sum = numbers.reduce(0) { result, next in result + next }

// 15
// Shorthand with operator function
let sum = numbers.reduce(0, +)

// 15
let words = ["Swift", "is", "great"]
let sentence = words.reduce("") { $0 + ($0.isEmpty ? "" : " ") + $1 }
// "Swift is great"

The first argument is the initial value. The closure takes the accumulated result and the next element, and returns the new accumulated value.

// Real-world: total cart price with discount
struct CartItem { let price: Double; let quantity: Int }

let cart = [CartItem(price: 9.99, quantity: 2), CartItem(price: 24.99, quantity: 1)]
let total = cart.reduce(0.0) { $0 + ($1.price * Double($1.quantity)) }
// 44.97

Chaining: Build Pipelines

The real power comes from chaining transformations.

let orders = [
    Order(amount: 120.0, isPaid: true),
    Order(amount: 45.0, isPaid: false),
    Order(amount: 300.0, isPaid: true),
    Order(amount: 15.0, isPaid: false),
    Order(amount: 89.0, isPaid: true)
]

let totalPaidRevenue = orders
    .filter { $0.isPaid }         // keep paid orders
    .map { $0.amount }            // extract amounts
    .reduce(0, +)                 // sum them
// 509.0

Each step is a single, focused transformation. Read it top to bottom like a sentence. No intermediate variables, no mutation, no mental overhead tracking state.

flatMap: Transform and Flatten

flatMap is map followed by flattening one level of nesting.

let sentences = ["Swift is great", "Generics are powerful"]

let words = sentences.map { $0.split(separator: " ").map(String.init) }
// [["Swift", "is", "great"], ["Generics", "are", "powerful"]]
// Nested array - probably not what you want
let words = sentences.flatMap { $0.split(separator: " ").map(String.init) }
// ["Swift", "is", "great", "Generics", "are", "powerful"]
// Flat array - much more useful

// Flattening optional results
let strings = ["1", "two", "3", "four", "5"]
let numbers = strings.flatMap { Int($0) }
// [1, 3, 5] - nils removed, results flattened

When the transformation returns an array, flatMap merges all the resulting arrays into one.

compactMap: Remove Nils

compactMap maps and removes nil results in one step.

let inputs = ["42", "hello", "7", "world", "13"]
let numbers = inputs.compactMap { Int($0) }
// [42, 7, 13]

let rawIDs: [String?] = ["usr_1", nil, "usr_3", nil, "usr_5"]
let validIDs = rawIDs.compactMap { $0 }
// ["usr_1", "usr_3", "usr_5"]

This replaces a common pattern:

// Before
var result: [Int] = []
for str in inputs {
    if let n = Int(str) { result.append(n) }
}

// After
let result = inputs.compactMap { Int($0) }

Same output. Dramatically less code. No mutation.

zip: Combine Two Sequences

zip pairs elements from two sequences together.

let names = ["Alice", "Bob", "Charlie"]
let scores = [95, 87, 92]

let leaderboard = zip(names, scores).map { "\($0): \($1)" }
// ["Alice: 95", "Bob: 87", "Charlie: 92"]
// Sort by score descending
let ranked = zip(names, scores)
    .sorted { $0.1 > $1.1 }
    .map { "\($0.0): \($0.1)" }
// ["Alice: 95", "Charlie: 92", "Bob: 87"]

zip stops at the shorter sequence, so no index out of bounds risk.

sorted and Custom Comparators

let users = [
    User(name: "Riya", age: 25),
    User(name: "Aryan", age: 28),
    User(name: "Dev", age: 22)
]

// Sort by age ascending
let byAge = users.sorted { $0.age < $1.age }

// Sort by name
let byName = users.sorted { $0.name < $1.name }

// Sort by multiple criteria: age descending, then name ascending
let complex = users.sorted {
    if $0.age != $1.age { return $0.age > $1.age }
    return $0.name < $1.name
}

Real-World Pipeline: Processing an API Response

struct APIProduct: Decodable {
    let id: String
    let name: String
    let price: Double?
    let category: String
    let isAvailable: Bool
}

struct DisplayProduct {
    let id: String
    let title: String
    let formattedPrice: String
}
func processProducts(_ raw: [APIProduct]) -> [DisplayProduct] {
    raw
        .filter { $0.isAvailable && $0.price != nil }
        .filter { $0.category == "electronics" }
        .sorted { $0.price! < $1.price! }
        .prefix(10)
        .compactMap { product -> DisplayProduct? in
            guard let price = product.price else { return nil }
            return DisplayProduct(
                id: product.id,
                title: product.name.capitalized,
                formattedPrice: String(format: "$%.2f", price)
            )
        }
}

No mutation. No intermediate arrays. One clean pipeline from raw API data to display-ready models.

Interview Questions

Q: What is the difference between map, flatMap, and compactMap in Swift?

map transforms each element and returns an array of the same length. flatMap transforms each element where the transformation returns a sequence, then flattens all results into a single array. compactMap transforms each element, removes nil results, and returns an array of unwrapped values. Use map for one-to-one transformations, flatMap when each element produces multiple results, and compactMap when the transformation might fail and you want to silently drop failures.

Q: Why is the functional style preferred over loops for data transformation in Swift?

Functional transformations are declarative. They say what the result is rather than how to produce it step by step. This makes each step independently readable and testable. Chained transformations have no shared mutable state between steps, which eliminates a whole class of bugs. They also compose cleanly: adding a new filter or transform means adding one line to the chain rather than modifying existing loop logic.

Summary

• map transforms every element and returns an array of the same length.
• filter returns only elements that satisfy a condition.
• reduce collapses a collection to a single value.
• Chaining filter, map, and reduce creates readable, declarative data pipelines.
• flatMap maps and flattens one level of nesting in the result.
• compactMap maps and removes nil results in a single step.
• zip pairs elements from two sequences without risk of index out of bounds.
• sorted accepts a comparator closure and supports multi-criteria sorting.
• Functional transformations have no shared mutable state, making them easier to test and compose.

Practice

1. Beginner: Given let temperatures = [36.6, 37.2, 38.1, 36.9, 39.0, 37.5], use filter to find fever temperatures (above 37.5), map to format them as strings like "38.1°C", and reduce to find the average fever temperature.
2. Intermediate: You have let logs: [String] = ["ERROR: disk full", "INFO: app started", "ERROR: timeout", "DEBUG: request sent", "ERROR: auth failed"]. Use compactMap to extract only the error messages (remove the "ERROR: " prefix), sorted to alphabetize them, and produce a single summary string using reduce.
3. Advanced: Build a Pipeline<Input, Output> struct that wraps a transformation function. Add a then<NewOutput> method that chains another Pipeline, returning a new Pipeline<Input, NewOutput>. Use it to build a reusable product-processing pipeline that filters, sorts, and maps API products in a composable way. Show how individual pipeline steps can be unit tested in isolation.

What’s Next

Article 18: Swift Async/Await: Modern Concurrency Without the Callback Chaos

Functional programming gives you cleaner synchronous data transformations. Async/await gives you cleaner asynchronous ones. Before async/await, every network call, file read, and background task meant nested completion handlers and manual thread management. Swift 5.5 changed that entirely. It is one of the most impactful additions to the language in years.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If data pipelines just replaced a pile of loops in your head, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still writing nested for-loops to transform API responses.

Follow me so Article 18 lands in your feed automatically. Async/await is next and it will change how you write every network call going forward.

See you in the next one. 🚀

Why Generics Exist

Without generics, you write the same logic multiple times for different types.

func printInt(_ value: Int) { print(value) }
func printString(_ value: String) { print(value) }
func printDouble(_ value: Double) { print(value) }

Three functions. Same body. Only the type differs. This does not scale. Generics solve it.

func printValue<T>(_ value: T) {
    print(value)
}

printValue(42)        // works
printValue("hello")   // works
printValue(3.14)      // works

One function. Any type. The compiler generates the right version for each call automatically.

Generic Functions

The <T> is a type parameter. It is a placeholder that Swift fills in at the call site.

func swap<T>(_ a: inout T, _ b: inout T) {
    let temp = a
    a = b
    b = temp
}

var x = 10
var y = 20
swap(&x, &y)

print(x, y)  // 20 10

var hello = "hello"
var world = "world"
swap(&hello, &world)

print(hello, world)  // world hello

T can be named anything. T and U are conventions for single and paired type parameters. Use descriptive names when the meaning matters: Element, Key, Value.

Generic Types

Structs, classes, and enums can all be generic.

struct Stack<Element> {
    private var storage: [Element] = []

    mutating func push(_ item: Element) {
        storage.append(item)
    }

    mutating func pop() -> Element? {
        storage.popLast()
    }

    var top: Element? {
        storage.last
    }

    var isEmpty: Bool {
        storage.isEmpty
    }
}

var intStack = Stack<Int>()
intStack.push(1)
intStack.push(2)
intStack.push(3)

print(intStack.pop())  // Optional(3)

var stringStack = Stack<String>()
stringStack.push("Swift")
stringStack.push("Generics")

print(stringStack.top)  // Optional("Generics")

One Stack implementation. Works for Int, String, User, or any type you throw at it. The type safety is fully preserved — an Stack<Int> cannot hold a String.

Type Constraints

Unconstrained generics can only use operations available on every type. To use specific capabilities, add a constraint.

// Without constraint — T could be anything, very limited
func bigger<T>(_ a: T, _ b: T) -> T {
    // Cannot use > here — not all types support it
}

// With Comparable constraint - now > is available
func bigger<T: Comparable>(_ a: T, _ b: T) -> T {
    a > b ? a : b
}

bigger(3, 7)        // 7
bigger("apple", "mango")  // "mango" - String is Comparable

Constraints can stack:

func findAndPrint<T: Comparable & CustomStringConvertible>(_ array: [T]) {
    if let max = array.max() {
        print("Max: \(max.description)")
    }
}

T must be both Comparable and CustomStringConvertible. The compiler enforces this at every call site.

Generic Constraints with where

The where clause adds constraints inline without cluttering the function signature.

func merge<T, U>(_ dict1: [T: U], _ dict2: [T: U]) -> [T: U] where T: Hashable {
    dict1.merging(dict2) { first, _ in first }
}

func allEqual<T: Collection>(_ collection: T) -> Bool where T.Element: Equatable {
    guard let first = collection.first else { return true }
    return collection.allSatisfy { $0 == first }
}

allEqual([1, 1, 1])       // true
allEqual(["a", "a", "b"]) // false

where is particularly useful when constraining associated types of protocols used as parameters.

Associated Types in Protocols

Protocols use associatedtype instead of <T> to define a generic requirement.

protocol Container {
    associatedtype Item
    mutating func add(_ item: Item)
    func contains(_ item: Item) -> Bool
    var count: Int { get }
}

struct Bag<T: Equatable>: Container {
    typealias Item = T
    private var items: [T] = []
    mutating func add(_ item: T) {
        items.append(item)
    }
    func contains(_ item: T) -> Bool {
        items.contains(item)
    }
    var count: Int { items.count }
}

var bag = Bag<String>()
bag.add("Swift")
bag.add("Generics")
print(bag.contains("Swift"))  // true
print(bag.count)              // 2

Associated types let protocols be generic without the angle bracket syntax. This is how Collection, Sequence, and IteratorProtocol in the standard library are designed.

Generic Extensions

Add behavior to a generic type conditionally.

extension Stack where Element: Equatable {
    func contains(_ item: Element) -> Bool {
        storage.contains(item)
    }
}

extension Stack: CustomStringConvertible where Element: CustomStringConvertible {
    var description: String {
        "[" + storage.map { $0.description }.joined(separator: ", ") + "]"
    }
}

contains only exists on stacks whose elements are Equatable. description only exists when elements have a string representation. The compiler adds exactly the right capabilities to each concrete type.

Real-World Pattern: Generic Network Layer

protocol APIEndpoint {
    associatedtype Response: Decodable
    var path: String { get }
    var method: HTTPMethod { get }
}

struct UsersEndpoint: APIEndpoint {
    typealias Response = [User]
    var path: String { "/users" }
    var method: HTTPMethod { .get }
}

struct CreateOrderEndpoint: APIEndpoint {
    typealias Response = Order
    var path: String { "/orders" }
    var method: HTTPMethod { .post }
}

class APIClient {
    func request<E: APIEndpoint>(_ endpoint: E) async throws -> E.Response {
        let url = URL(string: baseURL + endpoint.path)!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(E.Response.self, from: data)
    }
}

let client = APIClient()
let users: [User] = try await client.request(UsersEndpoint())
let order: Order = try await client.request(CreateOrderEndpoint())

One request function handles every endpoint in the app. The return type is inferred automatically from the endpoint's associated type. No casting. No Any. Full type safety at every call site.

Interview Questions

Q: What are generics in Swift and why are they important?

Generics let you write functions and types that work with any type while preserving full type safety. Without generics, you either duplicate code for each type or lose type safety by using Any. Generics give you both: one implementation and compile-time guarantees. Swift's Optional, Result, Array, Dictionary, and most of the standard library are built on generics. They are the foundation of reusable, type-safe code in Swift.

Q: What is the difference between a generic type parameter and a protocol associated type?

A generic type parameter is declared at the point of use with angle brackets: func foo<T>(_ value: T). The caller decides what T is. A protocol associated type is declared inside a protocol with associatedtype. The conforming type decides what the associated type is. Generic parameters are for functions and types you write directly. Associated types are for protocols that need to express relationships between types without specifying them up front.

Summary

• Generics let you write one implementation that works with any type safely.
• Type parameters like <T> are placeholders filled in at the call site.
• Constraints like <T: Comparable> restrict which types are allowed and unlock specific capabilities.
• The where clause adds constraints without cluttering the signature.
• Structs, classes, enums, and functions can all be generic.
• Protocol associated types are the protocol-side equivalent of generic type parameters.
• Generic extensions with constraints add behavior only when the element type qualifies.
• The entire Swift standard library and most production network layers are built on generics.

Practice

1. Beginner: Write a generic pairs<T>(_ array: [T]) -> [(T, T)] function that returns consecutive pairs from an array: [1,2,3,4] becomes [(1,2), (2,3), (3,4)]. Handle arrays with fewer than two elements gracefully.
2. Intermediate: Build a generic Cache<Key: Hashable, Value> struct with set(_ value: Value, for key: Key), get(_ key: Key) -> Value?, and remove(_ key: Key) methods. Add a maxSize: Int parameter that evicts the oldest entry when the cache is full.
3. Advanced: Design a type-safe EventBus<Event> using generics and associated types. Publishers post events of a specific type. Subscribers receive only the event type they registered for. The compiler should prevent subscribing to the wrong event type entirely, with no casting at the call site. Show it working with at least two distinct event types.

What’s Next

Article 17: Functional Programming in Swift: map, filter, reduce, and Beyond

Generics make your types flexible. Functional programming makes your logic composable. map, filter, reduce, flatMap, compactMap, and zip are not just collection utilities. They are a fundamentally different way of thinking about data transformation. Once they click, you will find yourself writing cleaner, shorter, and more testable code across every layer of your app.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If generics finally make sense as a design tool rather than just syntax, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still copying functions to handle different types.

Follow me so Article 17 lands in your feed automatically. Functional programming is next and it pairs perfectly with everything you just learned.

See you in the next one. 🚀

Why Memory Management Matters in Production

An app that leaks memory does not crash immediately. It slows down. It gets warm. It consumes more RAM with every navigation until iOS kills it in the background or the user force-quits it in frustration. Memory bugs are silent killers and they are almost always caused by the same small set of patterns.

Understanding ARC is not optional knowledge for senior iOS engineers. It is foundational.

What ARC Does

Automatic Reference Counting tracks how many references point to each class instance. When that count reaches zero, ARC deallocates the object and reclaims the memory.

class User {
    let name: String

    init(name: String) {
        self.name = name
        print("\(name) initialized")
    }
    deinit {
        print("\(name) deallocated")
    }
}

var ref1: User? = User(name: "Aryan")  // count: 1 - "Aryan initialized"
var ref2 = ref1                         // count: 2
var ref3 = ref1                         // count: 3
ref1 = nil  // count: 2
ref2 = nil  // count: 1
ref3 = nil  // count: 0 - "Aryan deallocated"

ARC runs at compile time, not runtime. It inserts retain and release calls for you. No garbage collector, no pauses, no unpredictable cleanup timing.

Strong References: The Default

Every regular reference is strong. It increments the reference count and keeps the object alive.

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

let team = Team(name: "iOS")  // strong reference - count: 1

Most of the time, strong is exactly what you want. The object lives as long as someone holds a reference to it.

Retain Cycles: When ARC Gets Stuck

A retain cycle happens when two objects hold strong references to each other. Neither count reaches zero. Neither object ever deallocates.

class Author {
    var name: String
    var article: Article?

    init(name: String) { self.name = name }
    deinit { print("\(name) deallocated") }
}

class Article {
    var title: String
    var author: Author?  // strong reference back to Author
    init(title: String) { self.title = title }
    deinit { print("\(title) deallocated") }
}

var author: Author? = Author(name: "Aryan")
var article: Article? = Article(title: "Swift ARC")
author?.article = article  // Author -> Article (strong)
article?.author = author   // Article -> Author (strong)
author = nil   // Author count: still 1 (Article holds it)
article = nil  // Article count: still 1 (Author holds it)
// deinit never called - both objects leak

Two objects, each keeping the other alive. The external references are gone but the cycle keeps both counts above zero forever.

Weak References: Breaking the Cycle

A weak reference does not increment the reference count. It does not keep the object alive. If the object deallocates, the weak reference automatically becomes nil.

class Article {
    var title: String
    weak var author: Author?  // weak — does not keep Author alive
    init(title: String) { self.title = title }
    deinit { print("\(title) deallocated") }
}

var author: Author? = Author(name: "Aryan")
var article: Article? = Article(title: "Swift ARC")
author?.article = article
article?.author = author
author = nil   // Author count: 0 - "Aryan deallocated"
article = nil  // Article count: 0 - "Swift ARC deallocated"

Cycle broken. Both objects deallocate cleanly.

Weak references must be var and optional. They can become nil at any time, so the compiler requires you to treat them as Optional.

Unowned References: The Riskier Option

An unowned reference also does not increment the reference count. The difference: it does not become nil when the object deallocates. Accessing an unowned reference after deallocation crashes the app.

class Customer {
    var name: String
    var card: CreditCard?
    init(name: String) { self.name = name }
    deinit { print("\(name) deallocated") }
}

class CreditCard {
    let number: String
    unowned let customer: Customer  // card cannot outlive the customer
    init(number: String, customer: Customer) {
        self.number = number
        self.customer = customer
    }
    deinit { print("Card \(number) deallocated") }
}

var customer: Customer? = Customer(name: "Aryan")
customer?.card = CreditCard(number: "4111", customer: customer!)
customer = nil
// "Aryan deallocated"
// "Card 4111 deallocated"

Use unowned only when you are certain the referenced object will always outlive the referencing one. If there is any doubt, use weak. A crash from an invalid unowned reference is harder to diagnose than an unexpected nil.

The Closure Retain Cycle

Closures are the most common source of retain cycles in real iOS code. A closure stored as a property captures self strongly by default. If self also holds the closure, you have a cycle.

class VideoPlayer {
    var onPlaybackEnd: (() -> Void)?

    func setup() {
        onPlaybackEnd = {
            self.reset()  // strong capture of self
        }
        // VideoPlayer holds onPlaybackEnd
        // onPlaybackEnd holds VideoPlayer
        // cycle
    }

    func reset() { }
    deinit { print("VideoPlayer deallocated") }
}

Fix with a capture list:

onPlaybackEnd = { [weak self] in
    self?.reset()
}

This is the pattern from Article 7 (Closures) viewed through the lens of ARC. The capture list makes the closure’s reference to self weak. The cycle breaks. self deallocates when its external references are gone.

Finding Leaks with Instruments

Xcode’s Memory Graph Debugger is your first tool for finding retain cycles:

1. Run your app in Xcode
2. Navigate to the screen you suspect is leaking
3. Navigate away
4. Click the Memory Graph button in the Debug bar
5. Look for objects that should have deallocated but still appear in the graph

Instruments’ Leaks and Allocations templates go deeper for production profiling. Any object shown in the memory graph after it should have been released is a candidate for investigation.

Real-World Patterns That Leak (and Their Fixes)

Timer retain cycle:

// Leak — Timer holds a strong reference to self
class ClockView {
    var timer: Timer?

    func start() {
        timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in
            self.updateDisplay()  // strong capture
        }
    }
}

// Fix
timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [weak self] _ in
    self?.updateDisplay()
}

Delegate retain cycle:

// Leak — strong delegate creates a cycle
class DataLoader {
    var delegate: DataLoaderDelegate?  // strong
}

// Fix - delegates are almost always weak
class DataLoader {
    weak var delegate: DataLoaderDelegate?
}

NotificationCenter observer not removed:

// Leak in older APIs — observer not removed
class ViewController: UIViewController {
    override func viewDidLoad() {
        NotificationCenter.default.addObserver(
            self,
            selector: #selector(handleUpdate),
            name: .dataUpdated,
            object: nil
        )
    }
    // Fix: remove in deinit or use the block-based API with [weak self]
    deinit {
        NotificationCenter.default.removeObserver(self)
    }
}

Interview Questions

Q: What is a retain cycle and how do you fix one in Swift?

A retain cycle occurs when two or more objects hold strong references to each other, preventing ARC from ever reducing either object’s reference count to zero. Both objects leak. The fix is to break the cycle by making one reference weak or unowned. Use weak when the referenced object can outlive the referencing one and may become nil. Use unowned only when you can guarantee the referenced object always outlives the referencing one.

Q: What is the difference between weak and unowned in Swift?

Both are non-retaining references that do not increment ARC’s reference count. weak is always optional and automatically becomes nil when the referenced object deallocates. unowned is non-optional and does not become nil. Accessing an unowned reference after the object deallocates causes a crash. Use weak when the referenced object might deallocate before the referencing one. Use unowned when you can guarantee it will not.

Summary

• ARC automatically tracks reference counts for class instances and deallocates them at zero.
• Strong references are the default and keep objects alive.
• Retain cycles occur when objects hold strong references to each other, preventing deallocation.
• weak references do not retain, are always optional, and become nil on deallocation.
• unowned references do not retain and are non-optional. Accessing them after deallocation crashes.
• Closures capture self strongly by default. Use [weak self] capture lists to break cycles.
• Delegates should almost always be weak.
• Timers, notification observers, and stored closures are the most common real-world leak sources.
• Use Xcode’s Memory Graph Debugger and Instruments to detect leaks before they reach production.

Practice

1. Beginner: Create two classes, Parent and Child, where Parent has a strong reference to Child and Child has a strong reference back to Parent. Add deinit to both and verify they never print. Then fix the cycle using weak and verify both deinit calls fire.
2. Intermediate: Build a EventBus class that stores an array of closures as subscribers. Show how a subscriber that captures self strongly creates a leak when the subscribing object deallocates. Fix it using [weak self] and clean up nil subscribers from the array automatically.
3. Advanced: Profile a UIViewController subclass in Instruments that has a retain cycle caused by a Timer and a stored closure. Document exactly which reference is causing the cycle, fix it, and verify the deallocation in the Memory Graph Debugger. Write a brief post-mortem explaining the root cause, the fix, and the general rule it illustrates.

What’s Next

Article 16: Swift Generics: Write Once, Use Everywhere

ARC taught you how Swift manages the lifetime of objects in memory. Generics teach you how to write code that works across types without duplicating logic. They are the foundation of Swift’s collections, Result, Optional, and almost every reusable component you will ever build.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If ARC finally clicked and you can see where your app might be leaking, tap 👏 up to 50 times. It helps this series reach developers shipping apps with silent memory bugs.

Follow me so Article 16 lands in your feed automatically. Generics are next and they will change how you write reusable code forever.

See you in the next one. 🚀

Why Error Handling Is Not Optional

Every app fails sometimes. Networks go down. Files go missing. Users enter bad data. JSON arrives malformed. The question is never whether your app will encounter errors. It is whether your code handles them deliberately or discovers them as crashes.

Swift’s error system makes deliberate handling the only option. If a function can throw, the compiler forces you to acknowledge that before your code builds. You cannot forget. You cannot ignore it. That guarantee is worth more than it might seem.

Defining Errors

Swift errors conform to the Error protocol. Enums are the natural fit because they enumerate exactly what can go wrong.

enum NetworkError: Error {
    case invalidURL
    case noConnection
    case timeout(after: TimeInterval)
    case serverError(statusCode: Int)
    case decodingFailed(reason: String)
}

Each case is a distinct, named failure. No integer error codes. No string comparisons. The compiler knows every possible error at compile time.

Throwing Functions

Mark a function with throws to indicate it can fail.

func fetchUser(id: String) throws -> User {
    guard !id.isEmpty else {
        throw NetworkError.invalidURL
    }
    
    // Simulate fetch
    guard let user = database[id] else {
        throw NetworkError.serverError(statusCode: 404)
    }
    return user
}

The throws keyword is part of the function signature. Any caller can see at a glance that this function might fail.

Calling Throwing Functions

You must use try when calling a throwing function. Then handle the error with do/catch.

do {
    let user = try fetchUser(id: "usr_001")
    print("Found: \(user.name)")
} catch NetworkError.invalidURL {
    print("The URL was invalid")
} catch NetworkError.serverError(let code) {
    print("Server returned \(code)")
} catch NetworkError.timeout(let seconds) {
    print("Request timed out after \(seconds)s")
} catch {
    // Catches everything else
    print("Unexpected error: \(error)")
}

Swift’s catch supports full pattern matching, including associated values. The final bare catch is your safety net for anything you did not explicitly anticipate.

try? and try!

Two shorthand options when you need less ceremony.

// try? — converts the result to Optional, nil on failure
let user = try? fetchUser(id: "usr_001")
// user is User? — nil if fetchUser threw anything

// try! - force unwraps the result, crashes if it throws
let user = try! fetchUser(id: "usr_001")
// Crashes at runtime if fetchUser throws

try? is useful when failure is acceptable and you just want a nil. Loading a cached image, for example. If the cache misses, nil is fine.

try! is the same risk as force-unwrapping an optional. Use it only when you are certain the function cannot throw in this context, and document why.

Propagating Errors

Throwing functions can propagate errors up the call stack instead of handling them immediately. Mark the caller as throws too.

func loadUserProfile(id: String) throws -> UserProfile {
    let user = try fetchUser(id: id)       // propagates if this throws
    let posts = try fetchPosts(for: user)  // propagates if this throws
    return UserProfile(user: user, posts: posts)
}

The error bubbles up until something catches it. This lets you handle errors at the right layer instead of wrapping every function call in do/catch.

Result<Success, Failure>: Errors as Values

Result is Swift's enum for representing success or failure as a value rather than through throwing.

enum Result<Success, Failure: Error> {
    case success(Success)
    case failure(Failure)
}

Use it when you need to store an error, pass it to a completion handler, or work with APIs that use callbacks instead of async/await.

func fetchUser(id: String, completion: @escaping (Result<User, NetworkError>) -> Void) {
    guard !id.isEmpty else {
        completion(.failure(.invalidURL))
        return
    }

    // Simulate async fetch
    DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
        if let user = self.database[id] {
            completion(.success(user))
        } else {
            completion(.failure(.serverError(statusCode: 404)))
        }
    }
}

// Call site
fetchUser(id: "usr_001") { result in
    switch result {
    case .success(let user):
        print("Loaded: \(user.name)")
    case .failure(let error):
        print("Failed: \(error)")
    }
}

Result makes the success and failure paths explicit and equal. No hidden optional, no separate error parameter.

Converting Between throws and Result

Swift makes this seamless.

// throws -> Result
let result = Result { try fetchUser(id: "usr_001") }

// Result -> throws
let user = try result.get()

Result { } captures any thrown error into .failure. .get() throws the failure back out. Use whichever style fits the surrounding code.

rethrows: Conditional Throwing

A function marked rethrows only throws if one of its closure parameters throws.

func transform<T>(_ values: [T], using block: (T) throws -> T) rethrows -> [T] {
    try values.map(block)
}

// Non-throwing closure - transform doesn't throw
let doubled = transform([1, 2, 3]) { $0 * 2 }
// Throwing closure - transform can throw
let parsed = try transform(["1", "two", "3"]) { str in
    guard let int = Int(str) else { throw ParseError.invalid(str) }
    return int
}

rethrows is how map, filter, and forEach in the standard library work. They only require try when the closure you pass them throws.

Real-World Pattern: Layered Error Handling

Production apps translate low-level errors into user-facing messages at the right layer.

enum AppError: Error, LocalizedError {
    case networkUnavailable
    case sessionExpired
    case contentNotFound
    case unknown(Error)

    var errorDescription: String? {
        switch self {
        case .networkUnavailable:  return "Check your internet connection and try again."
        case .sessionExpired:      return "Your session has expired. Please log in again."
        case .contentNotFound:     return "This content is no longer available."
        case .unknown:             return "Something went wrong. Please try again."
        }
    }
}

func mapToAppError(_ error: Error) -> AppError {
    guard let networkError = error as? NetworkError else {
        return .unknown(error)
    }
    switch networkError {
    case .noConnection:            return .networkUnavailable
    case .serverError(401):        return .sessionExpired
    case .serverError(404):        return .contentNotFound
    default:                       return .unknown(error)
    }
}

Low-level network errors stay in the networking layer. The app layer speaks in user-friendly terms. The view just reads errorDescription and displays it. Each layer handles what it knows about.

Interview Questions

Q: What is the difference between throws and Result in Swift error handling?

throws uses Swift's built-in error propagation mechanism. The compiler forces callers to use try and either handle or propagate the error. Result represents success or failure as a value in an enum. Use throws for synchronous code and async/await-based APIs where the compiler can enforce error handling directly. Use Result for completion handler-based APIs, when you need to store or pass an error as a value, or when working with older callback-based code.

Q: What does rethrows mean in Swift?

rethrows marks a function that only throws if one of the closure parameters it receives throws. If you pass a non-throwing closure, the function itself does not throw and no try is needed at the call site. If you pass a throwing closure, the function can rethrow that error. This is how standard library functions like map and filter work cleanly with both throwing and non-throwing closures.

Summary

• Swift errors conform to Error. Enums with associated values are the cleanest modeling tool.
• throws in a function signature tells every caller: this can fail.
• do/catch handles errors with full pattern matching, including associated values.
• try? converts failure to nil. try! crashes on failure. Use both sparingly.
• Errors propagate up the call stack until something catches them.
• Result<Success, Failure> represents success or failure as a value, ideal for completion handlers.
• Result { try... } captures thrown errors. .get() throws them back out.
• rethrows only propagates errors when a closure parameter itself throws.
• Translate low-level errors into user-facing messages at the appropriate architectural layer.

Practice

1. Beginner: Create a divide(_ a: Double, by b: Double) throws -> Double function that throws a MathError.divisionByZero case when b is zero. Call it with do/catch, with try?, and with try!. Explain when each is appropriate.
2. Intermediate: Build a JSONLoader struct with a load<T: Decodable>(_ filename: String) throws -> T method that reads a JSON file from the app bundle and decodes it. Define a FileError enum covering file not found, read failure, and decoding failure with associated error messages. Chain the error propagation correctly so callers see meaningful errors.
3. Advanced: Create a Validator<T> struct that takes an array of (T) throws -> Void validation rules. Add a validate(_ value: T) -> Result<T, ValidationError> method where ValidationError collects all failures, not just the first one. Use rethrows where appropriate and write a concrete example validating a RegistrationForm struct with rules for username length, email format, and password strength.

What’s Next

Article 15: ARC and Memory Management: How Swift Keeps Your App From Leaking

You now know how Swift handles errors at the language level. Next: how it handles memory. Automatic Reference Counting is what keeps your objects alive exactly as long as they need to be and no longer. Understanding ARC, strong references, weak references, and retain cycles is what separates developers who write leak-free apps from those who find memory problems in production.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If Swift’s error system just made your failure handling more intentional, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still using optional returns where errors belong.

Follow me so Article 15 lands in your feed automatically. Memory management is next and it is one of the most important topics for shipping stable iOS apps.

See you in the next one. 🚀

Why Extensions Are One of Swift’s Best Features

Most languages let you add behavior to a type by subclassing it or modifying it directly. Swift offers a third path: extend any type, anywhere, without touching the original source.

You can add methods to String. Computed properties to Int. Protocol conformances to types from third-party libraries. Namespace your own code into focused, readable chunks. Extensions make all of this clean and compiler-safe.

The Basics

extension String {
    func trimmed() -> String {
        trimmingCharacters(in: .whitespacesAndNewlines)
    }
    
    var isBlank: Bool {
        trimmed().isEmpty
    }
}

let input = "  hello  "
print(input.trimmed())  // "hello"
print(input.isBlank)    // false
print("   ".isBlank)    // true

Every String in your entire project now has trimmed() and isBlank. No subclass, no wrapper type, no helper function hidden in a utility file.

What You Can Add in an Extension

Extensions support a wide range of additions:

extension SomeType {
    // Computed properties (stored properties are not allowed)
    var computedValue: Int { ... }

    // Methods
    func doSomething() { ... }
    // Initializers (convenience, not designated for classes)
    init(someParam: String) { ... }
    // Subscripts
    subscript(key: String) -> String? { ... }
    // Nested types
    enum State { case active, inactive }
}

One important limit: extensions cannot add stored properties. You can add computed properties that derive their value, but you cannot add new memory to an existing type from outside its definition.

Extending Your Own Types for Organization

Extensions are not just for adding new behavior to foreign types. They are one of the cleanest ways to organize your own code.

struct UserViewModel {
    let user: User
    var isLoading: Bool
    var errorMessage: String?
}

// Core data
extension UserViewModel {
    var displayName: String {
        user.name.isEmpty ? "Anonymous" : user.name
    }
    var avatarInitials: String {
        String(user.name.prefix(2)).uppercased()
    }
}
// Actions
extension UserViewModel {
    mutating func refresh() {
        isLoading = true
        errorMessage = nil
    }
    mutating func handleError(_ error: Error) {
        isLoading = false
        errorMessage = error.localizedDescription
    }
}

Split by responsibility, not by arbitrary line count. Each extension block has one clear purpose. New team members find what they need faster.

Protocol Conformance in Separate Extensions

This is the pattern you will see in every serious Swift codebase.

struct Product {
    let id: String
    let name: String
    let price: Double
}

// Core type stays clean
// Conformances are declared separately
extension Product: Equatable {
    static func == (lhs: Product, rhs: Product) -> Bool {
        lhs.id == rhs.id
    }
}

extension Product: Comparable {
    static func < (lhs: Product, rhs: Product) -> Bool {
        lhs.price < rhs.price
    }
}

extension Product: CustomStringConvertible {
    var description: String {
        "\(name) - $\(String(format: "%.2f", price))"
    }
}

Each conformance lives in its own extension block. When you search for “Equatable” in your file, you find it immediately. When you delete a conformance, you delete one focused block, not lines scattered through the original type.

Extending Apple’s Types

This is where extensions genuinely change how you write daily code.

extension Int {
    var isEven: Bool { self % 2 == 0 }
    var isOdd: Bool { !isEven }
    
    func times(_ action: () -> Void) {
        for _ in 0..<self { action() }
    }
}

5.times { print("hello") }  // prints "hello" 5 times
print(4.isEven)              // true

extension Double {
    var asPercentage: String {
        String(format: "%.1f%%", self * 100)
    }
}

print(0.856.asPercentage)  // "85.6%"

extension Array {
    func chunked(into size: Int) -> [[Element]] {
        stride(from: 0, to: count, by: size).map {
            Array(self[$0..<Swift.min($0 + size, count)])
        }
    }
}

let pages = [1,2,3,4,5,6,7].chunked(into: 3)
// [[1,2,3], [4,5,6], [7]]

extension Optional where Wrapped == String {
    var orEmpty: String {
        self ?? ""
    }
}

let name: String? = nil
print(name.orEmpty)  // ""

These are not clever tricks. They are the kind of extensions that end up in every production iOS codebase because they eliminate repetitive unwrapping and formatting code across hundreds of files.

Extensions with Constraints

You can limit an extension to only apply when generic type parameters meet a condition.

extension Array where Element: Numeric {
    var sum: Element {
        reduce(0, +)
    }
    
    var average: Double {
        guard !isEmpty else { return 0 }
        return Double(sum as! Double) / Double(count)
    }
}

[1, 2, 3, 4, 5].sum  // 15

Or for your own generic types:

extension Stack where T: Equatable {
    func contains(_ value: T) -> Bool {
        storage.contains(value)
    }
}

The contains method only exists when the stack holds Equatable elements. The compiler enforces this. You don't need runtime checks.

What Extensions Cannot Do

A few limits worth knowing upfront:

extension String {
    // ❌ Cannot add stored properties
    var someStoredValue: Int = 0

    // ❌ Cannot override existing methods (use subclassing for that)
    // override func hasPrefix(_ prefix: String) -> Bool { ... }
}

Extensions also cannot add designated initializers to classes or add deinit. These rules keep extensions predictable: they add to a type, they don't restructure it.

Real-World Pattern: UIColor Extension

extension UIColor {
    convenience init(hex: String) {
        var hexSanitized = hex.trimmingCharacters(in: .whitespacesAndNewlines)
        hexSanitized = hexSanitized.replacingOccurrences(of: "#", with: "")
      
        var rgb: UInt64 = 0
        Scanner(string: hexSanitized).scanHexInt64(&rgb)
        let r = CGFloat((rgb & 0xFF0000) >> 16) / 255
        let g = CGFloat((rgb & 0x00FF00) >> 8) / 255
        let b = CGFloat(rgb & 0x0000FF) / 255
        self.init(red: r, green: g, blue: b, alpha: 1)
    }

    static let brandPrimary = UIColor(hex: "#4A90E2")
    static let brandSecondary = UIColor(hex: "#F5A623")
}

// Usage
view.backgroundColor = .brandPrimary
label.textColor = UIColor(hex: "#333333")

This is a convenience initializer added to UIColor from Apple's UIKit. You cannot modify UIKit's source. Extensions make this possible cleanly.

Interview Questions

Q: What can and cannot be added to a type via an extension in Swift?

Extensions can add computed properties, methods, initializers (convenience initializers for classes), subscripts, nested types, and protocol conformances. They cannot add stored properties, cannot override existing implementations (that requires subclassing), and cannot add designated initializers or deinit to classes. The constraint on stored properties exists because extensions cannot change the memory layout of a type defined elsewhere.

Q: Why do senior Swift engineers put protocol conformances in separate extension blocks?

Separating conformances into distinct extensions makes each one easy to find, reason about, and delete independently. When you search for Equatable conformance, you find one focused block rather than code scattered through the main type definition. It also makes code review cleaner: a diff that adds Codable conformance via an extension is immediately understandable without reading the entire type.

Summary

• Extensions add computed properties, methods, initializers, subscripts, and protocol conformances to any type.
• Extensions cannot add stored properties or override existing methods.
• Organizing your own types into focused extension blocks by responsibility improves readability and navigation.
• Protocol conformances in separate extension blocks make each conformance easy to find and remove.
• Constrained extensions apply only when generic parameters meet specific requirements.
• Extensions on Apple’s types like String, Array, and UIColor eliminate repetitive utility code across a codebase.

Practice

1. Beginner: Write extensions on String for isValidEmail: Bool (basic format check), wordCount: Int, and capitalizingFirstLetter() -> String. Use them in a form validation function.
2. Intermediate: Extend Array with three useful methods: second: Element? (returns the second element safely), groupedBy<Key: Hashable>(_ keyPath: KeyPath<Element, Key>) -> [Key: [Element]], and removingDuplicates() -> [Element] where Element: Equatable. Write tests for each.
3. Advanced: Create a UserDefaults extension that uses a generic subscript with Codable constraints to read and write any Codable type. Use @propertyWrapper style with a custom Persisted<T: Codable> wrapper that reads from and writes to UserDefaults automatically. Show how it eliminates boilerplate compared to raw UserDefaults usage.

What’s Next

Article 14: Swift Error Handling: throw, try, catch, and Result

Extensions make your types richer. Error handling makes them honest. Swift’s error system is not just try/catch ported from other languages. It is a compile-enforced mechanism that forces you to acknowledge every failure path before your code builds. Combined with Result<T, Error>, it becomes one of the cleanest error propagation systems in any modern language.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If extensions changed how you think about organizing code, tap 👏 up to 50 times. It helps this series reach developers still writing utility helper files full of free functions.

Follow me so Article 14 lands in your feed the moment it goes live. Error handling is next and it is far more powerful than most developers realize.

See you in the next one. 🚀

Why Protocols Change Everything

Swift is not an object-oriented language at heart. It is a protocol-oriented one. Apple said this at WWDC 2015 and then proceeded to build SwiftUI, Combine, and the entire standard library around it.

Understanding protocols is the difference between writing code that works and writing code that scales, composes, and stays testable as your app grows.

What Is a Protocol?

A protocol defines a contract. It says: “Any type that conforms to me must provide these properties and methods.” It says nothing about how they’re implemented.

protocol Greetable {
    var name: String { get }
    func greet() -> String
}

Any struct, class, or enum can conform:

struct User: Greetable {
    var name: String

    func greet() -> String {
        "Hello, I'm \(name)"
    }
}

struct Bot: Greetable {
    var name: String
    func greet() -> String {
        "BEEP. I AM \(name.uppercased()). BOOP."
    }
}

Both types are Greetable. Both implement greet() differently. Code that accepts a Greetable works with either, without knowing which one it has.

Protocol Properties

Protocols specify whether a property must be gettable, settable, or both.

protocol Vehicle {
    var speed: Double { get }        // read-only minimum requirement
    var fuelLevel: Double { get set } // must be read-write
    var description: String { get }
}

A conforming type can satisfy { get } with either a stored property or a computed one. It must satisfy { get set } with a mutable stored property.

struct Car: Vehicle {
    var speed: Double          // stored — satisfies { get }
    var fuelLevel: Double      // stored — satisfies { get set }

    var description: String {  // computed - also satisfies { get }
        "Car going \(speed) km/h"
    }
}

Default Implementations with Extensions

Protocol extensions let you provide default behavior. Conforming types get it for free and can override it if needed.

protocol Describable {
    var name: String { get }
    func describe() -> String
}

extension Describable {
    func describe() -> String {
        "I am \(name)"  // default implementation
    }
}
struct Product: Describable {
    var name: String
    // describe() is provided automatically
}
struct SpecialProduct: Describable {
    var name: String
    func describe() -> String {
        "Special: \(name)"  // overrides the default
    }
}
print(Product(name: "Laptop").describe())         // I am Laptop
print(SpecialProduct(name: "Laptop").describe())  // Special: Laptop

This is one of the most powerful patterns in Swift. Add behavior to a protocol once and every conforming type benefits. No inheritance required.

Protocol Composition

A type can conform to multiple protocols. You can also require multiple protocols at once using &.

protocol Flyable {
    func fly()
}

protocol Swimmable {
    func swim()
}
struct Duck: Flyable, Swimmable {
    func fly() { print("Flap flap") }
    func swim() { print("Splash splash") }
}
func demonstrate(_ animal: Flyable & Swimmable) {
    animal.fly()
    animal.swim()
}
demonstrate(Duck())

This is composition over inheritance. Instead of building a class hierarchy to represent a flying, swimming animal, you compose behaviors from focused protocols. Adding a Walkable protocol later doesn't require restructuring anything.

Using Protocols as Types

Protocols are first-class types. You can use them as parameter types, return types, and stored properties.

protocol Shape {
    var area: Double { get }
}

struct Circle: Shape {
    var radius: Double
    var area: Double { .pi * radius * radius }
}
struct Rectangle: Shape {
    var width: Double
    var height: Double
    var area: Double { width * height }
}
func totalArea(of shapes: [Shape]) -> Double {
    shapes.reduce(0) { $0 + $1.area }
}
let shapes: [Shape] = [Circle(radius: 5), Rectangle(width: 4, height: 6)]
print(totalArea(of: shapes))  // 102.53...

The function doesn’t know or care whether each shape is a Circle or Rectangle. It just knows they're Shape. This is polymorphism without inheritance.

Equatable, Comparable, Hashable: The Standard Protocols

Swift’s standard library is built on protocols. Three you’ll use constantly:

struct User: Equatable, Comparable, Hashable {
    let id: String
    var name: String

// Equatable - compiler synthesizes == for you if all properties are Equatable
    // Hashable - compiler synthesizes hash(into:) for you
    // Comparable - you provide this one
    static func < (lhs: User, rhs: User) -> Bool {
        lhs.name < rhs.name
    }
}
let users = [User(id: "2", name: "Riya"), User(id: "1", name: "Aryan")]
let sorted = users.sorted()  // sorted by name because of Comparable
let set = Set(users)         // works because of Hashable
let isEqual = users[0] == users[1]  // works because of Equatable

Conform to these and your type plugs into the entire Swift ecosystem: sorting, sets, dictionaries, diffing, and more.

Codable: The Protocol That Replaced Boilerplate

Codable is Encodable & Decodable. Conform to it and Swift synthesizes JSON encoding and decoding automatically.

struct Article: Codable {
    let id: Int
    let title: String
    let publishedAt: Date
    let tags: [String]
}

let json = """
{
    "id": 1,
    "title": "Swift Protocols",
    "publishedAt": "2025-08-14T10:00:00Z",
    "tags": ["swift", "ios"]
}
""".data(using: .utf8)!
let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
let article = try decoder.decode(Article.self, from: json)
print(article.title)  // Swift Protocols

Three lines to decode a full JSON object into a typed Swift struct. No manual mapping, no stringly-typed dictionary access, no runtime surprises.

Protocol-Oriented Programming in Practice

The real power shows up in architecture. Here is a testable network layer built entirely on protocols:

protocol NetworkService {
    func fetch<T: Decodable>(endpoint: String) async throws -> T
}

// Production implementation
struct LiveNetworkService: NetworkService {
    func fetch<T: Decodable>(endpoint: String) async throws -> T {
        let url = URL(string: "https://api.myapp.com" + endpoint)!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(T.self, from: data)
    }
}
// Test implementation - no network required
struct MockNetworkService: NetworkService {
    var mockData: Data
    func fetch<T: Decodable>(endpoint: String) async throws -> T {
        try JSONDecoder().decode(T.self, from: mockData)
    }
}
// ViewModel accepts the protocol, not the concrete type
class UserViewModel {
    private let network: NetworkService
    init(network: NetworkService = LiveNetworkService()) {
        self.network = network
    }
}

In production: inject LiveNetworkService. In tests: inject MockNetworkService. The view model never knows the difference. This is dependency injection via protocols and it is how testable iOS apps are built.

Interview Questions

Q: What is a protocol in Swift and how does it differ from inheritance?

A protocol defines a contract: a set of requirements any conforming type must satisfy. Inheritance copies behavior from a parent class to a child class. Protocols enable composition: a type can conform to many protocols simultaneously, each adding focused capabilities. Unlike inheritance, protocols work with structs and enums, not just classes. Swift favors protocols because they are more flexible, more testable, and avoid the fragile base class problems that deep inheritance hierarchies create.

Q: What is a default implementation in a protocol extension and why is it useful?

A default implementation is behavior provided in a protocol extension that conforming types automatically inherit without writing any code. It is useful because it lets you add shared behavior to all conforming types at once, allows new protocol requirements to be added without breaking existing conformances, and removes the need for a base class just to share implementation. Conforming types can override the default when they need different behavior.

Summary

• A protocol defines a contract: required properties and methods without implementation.
• Any struct, class, or enum can conform to a protocol.
• Protocol extensions provide default implementations that conforming types inherit for free.
• Protocol composition with & lets functions require multiple capabilities at once.
• Protocols as types enable polymorphism without inheritance.
• Equatable, Comparable, Hashable, and Codable are foundational standard library protocols.
• Protocol-oriented programming powers testable architecture through dependency injection.
• Swift’s standard library, SwiftUI, and Combine are all built on this pattern.

Practice

1. Beginner: Define a Printable protocol with a prettyPrint() method. Create three types that conform to it: Invoice, Receipt, and ShippingLabel. Add a default implementation that prints the type name, then override it meaningfully for each type.
2. Intermediate: Build a Cacheable protocol with var cacheKey: String { get } and var expiresAfter: TimeInterval { get }. Add a default expiresAfter of 300 seconds via a protocol extension. Conform User, Product, and Article structs to it with different cache keys.
3. Advanced: Create a Repository<T> protocol with fetch(id: String) async throws -> T, save(_ item: T) async throws, and delete(id: String) async throws. Build a InMemoryRepository<T> struct that conforms to it using a dictionary. Then create a UserService that depends on any Repository<User> and write a test using the in-memory version without touching a network or database.

What’s Next

Article 13: Swift Extensions: Adding Behavior Without Subclassing

Protocols define what a type can do. Extensions define what it already does, retroactively. You can extend any type in Swift, including ones from Apple’s frameworks, and add computed properties, methods, and protocol conformances without touching the original source. It is one of the cleanest features in the language.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If protocol-oriented programming clicked today, tap 👏 up to 50 times. It helps this series reach developers still building class hierarchies that should be protocol compositions.

Follow me so Article 13 lands in your feed automatically. Extensions are next and they make every type in the language feel like yours.

See you in the next one. 🚀

Why Optionals Exist

In most languages, any variable can be null at any time. You find out at runtime, usually as a crash. Swift takes a different approach: if a value can be absent, you must say so explicitly. The compiler then refuses to let you use it as if it were definitely there.

That one rule eliminates an entire category of bugs before your app ever runs.

What Is an Optional?

An optional is a type that wraps another type and adds the possibility of absence.

var name: String = "Aryan"   // must have a value
var nickname: String? = nil  // may or may not have a value

The ? after a type is syntactic sugar for Optional<String>. Under the hood, Optional is just an enum:

enum Optional<Wrapped> {
    case some(Wrapped)
    case none
}

When you write String?, you get a type that is either .some("Aryan") or .none. That's all an optional is. Everything else follows from this.

Forced Unwrapping: The Dangerous Shortcut

The ! operator extracts the value from an optional. If the optional is nil, it crashes.

var username: String? = "aryan_dev"
print(username!)  // "aryan_dev"

var empty: String? = nil
print(empty!)     // 💥 Fatal error: unexpectedly found nil

Forced unwrapping has its place. It should never be your default. Every ! in production code is a promise that this value will never be nil here. If that promise breaks, your app crashes.

Rule: Treat ! like a comment that says "I guarantee this is never nil." If you can't honestly say that, don't use it.

Optional Binding: The Right Way

if let safely unwraps an optional. If it has a value, you get it. If not, you take the else branch.

var username: String? = "aryan_dev"

if let name = username {
    print("Hello, \(name)")  // name is String here, not String?
} else {
    print("No username set")
}

Swift 5.7 shorthand when the variable name stays the same:

if let username {
    print("Hello, \(username)")
}

For functions with multiple optional preconditions, guard let keeps the code flat:

func processOrder(userID: String?, productID: String?, quantity: Int?) {
    guard let userID else { return }
    guard let productID else { return }
    guard let quantity, quantity > 0 else { return }
 
   // All three are safely unwrapped here
    placeOrder(user: userID, product: productID, qty: quantity)
}

This pattern eliminates the pyramid of nested if let blocks that plagues code written by developers still figuring out optionals.

Nil Coalescing: Provide a Default

The ?? operator returns the unwrapped value if it exists, or a default if it doesn't.

var displayName: String? = nil
let name = displayName ?? "Guest"
print(name)  // "Guest"

Chain it for multiple fallbacks:

let name = firstName ?? lastName ?? username ?? "Anonymous"

Use this for simple fallback logic. For complex branching, if let or guard let is clearer.

Optional Chaining: Navigate Safely

The ?. operator calls a method or accesses a property on an optional. If the optional is nil, the whole expression returns nil instead of crashing.

struct Address {
    var city: String
}

struct User {
    var address: Address?
}

var user: User? = User(address: Address(city: "Mumbai"))
print(user?.address?.city)  // Optional("Mumbai")
print(user?.address?.city.uppercased())  // Optional("MUMBAI")
user = nil
print(user?.address?.city)  // nil - no crash

The result of an optional chain is always optional. If anything in the chain is nil, the whole thing short-circuits to nil.

Combine with ?? to get a non-optional result:

let city = user?.address?.city ?? "Unknown city"

map and flatMap on Optionals

Optionals have functional methods too. This surprises most developers.

let input: String? = "42"

// map transforms the wrapped value if it exists
let doubled = input.map { Int($0) }
// Returns Optional<Optional<Int>> - nested optionals
// flatMap flattens the result
let number = input.flatMap { Int($0) }
// Returns Optional<Int> - cleaner

flatMap is especially useful when a transformation itself returns an optional:

let userIDString: String? = "123"
let userID: Int? = userIDString.flatMap { Int($0) }

One line. Safe. No forced unwrapping. This is how functional Swift handles optional transformations.

Implicitly Unwrapped Optionals

Declared with ! instead of ?. Behave like regular values but crash if nil.

var label: UILabel!  // implicitly unwrapped

Use this only when a value is guaranteed to be set before first use but cannot be set in init. IBOutlets are the canonical example. UIKit sets them after init but before viewDidLoad, so the guarantee holds.

Outside of IBOutlets and a handful of UIKit patterns, avoid them. They trade safety for convenience, and the convenience rarely outweighs the risk.

Optional in Switch

Because optionals are enums, you can switch on them directly:

let score: Int? = 85

switch score {
case .some(let value) where value >= 90:
    print("A")
case .some(let value) where value >= 80:
    print("B")
case .some(let value):
    print("C or below: \(value)")
case .none:
    print("No score recorded")
}

Or use the shorthand case let value? syntax:

switch score {
case let value? where value >= 90:
    print("A: \(value)")
case let value?:
    print("Score: \(value)")
case nil:
    print("No score")
}

Real-World Pattern: Decoding Optional API Fields

struct Product: Decodable {
    let id: String
    let name: String
    let description: String?   // not always returned by API
    let discountPrice: Double? // only present during sales
    let imageURL: URL?
}

func display(_ product: Product) {
    let desc = product.description ?? "No description available"
    let price = product.discountPrice.map { "Sale: $\($0)" } ?? "Full price"
    let image = product.imageURL ?? URL(string: "https://cdn.myapp.com/placeholder.png")!
    print(desc)
    print(price)
}

Optionals here aren’t just syntax. They’re documentation. Any engineer reading this struct immediately knows which fields the API might omit.

Interview Questions

Q: What is an optional in Swift and how does it work under the hood?

An optional is a generic enum with two cases: .some(Wrapped) and .none. The ? syntax is shorthand for Optional<T>. When a variable is declared as String?, the compiler wraps it in this enum. Using the value directly without unwrapping is a compile-time error. This design means nil-related bugs are caught before the app runs, not during user sessions.

Q: What is the difference between if let, guard let, and ?? for handling optionals?

if let unwraps an optional inside a block. The unwrapped value is only available inside that block. guard let unwraps at the top of a scope and exits if nil. The unwrapped value is available for the rest of the function. ?? provides an inline default value when the optional is nil. Use if let for optional branches, guard let for preconditions, and ?? for simple fallback values.

Summary

• An optional is Optional<T>: either .some(value) or .none.
• Forced unwrapping with ! crashes at runtime if the value is nil. Use it only when you can guarantee the value exists.
• if let safely unwraps inside a block. guard let unwraps and exits early if nil.
• ?? provides a default value inline when an optional is nil.
• Optional chaining with ?. short-circuits to nil instead of crashing.
• map transforms an optional's value. flatMap handles transformations that return optionals.
• Implicitly unwrapped optionals (!) are for IBOutlets and UIKit patterns only.
• Optionals are enums, so you can use switch pattern matching on them directly.

Practice

Beginner: Write a function greet(name: String?) -> String that returns "Hello, [name]!" if name exists and "Hello, stranger!" if it doesn't. Implement it three ways: forced unwrap, if let, and ??. Explain which you'd use in production and why.

Intermediate: Given this struct:

struct Order {
    var user: User?
    var shippingAddress: Address?
    var promoCode: String?
}

Write a function summarize(_ order: Order) -> String using optional chaining and ?? to produce a readable summary without any forced unwraps or crashes, regardless of which fields are nil.

Advanced: Implement a safeSubscript extension on Array that returns an optional instead of crashing on out-of-bounds access:

extension Array {
    subscript(safe index: Int) -> Element? { ... }
}

Then use flatMap to safely extract and transform values from an array of optionals without any force unwraps.

What’s Next

Article 12: Swift Protocols: Contracts, Conformance, and the Power of Protocol-Oriented Programming

Optionals showed you how Swift uses the type system to enforce safety. Protocols take that further. They define contracts that any type can fulfill, enabling one of Swift’s most powerful architectural patterns: protocol-oriented programming. It’s the reason Swift code composes so cleanly.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If optionals finally make sense as a safety system rather than just syntax, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still scattering ! across their codebase.

Follow me so Article 12 lands in your feed automatically. Protocols are next and they will change how you architect everything.

See you in the next one. 🚀

Why Enums Are Bigger Than You Think

Every tutorial introduces enums as a fancy list of named values. That framing undersells them completely.

Swift enums can carry data. They can have methods. They can conform to protocols. They work as the backbone of error handling, network state, navigation routing, and API response modeling. Once you see what they can actually do, you’ll find yourself reaching for them constantly.

The Basics

An enum defines a type with a fixed set of cases.

enum Direction {
    case north
    case south
    case east
    case west
}

var heading = Direction.north
heading = .west  // Swift infers the type after first assignment

The dot syntax after first assignment is a small thing that makes call sites read cleanly.

Raw Values

Attach a primitive value to each case.

enum Planet: Int {
    case mercury = 1
    case venus
    case earth
    case mars
}

print(Planet.earth.rawValue)  // 3 - auto-increments from 1
// Initialize from a raw value - returns Optional because it can fail
let planet = Planet(rawValue: 2)  // Optional<Planet> - venus
let unknown = Planet(rawValue: 99)  // nil

String raw values are common for API mapping:

enum UserRole: String {
    case admin = "ADMIN"
    case editor = "EDITOR"
    case viewer = "VIEWER"
}

// Decode directly from an API response string
let role = UserRole(rawValue: "EDITOR")  // .editor

This pattern eliminates strongly-typed comparisons like if role == "ADMIN" scattered across your codebase.

Associated Values: The Game Changer

Each case can carry its own data. Different cases can carry different types.

enum PaymentMethod {
    case creditCard(number: String, expiry: String)
    case bankTransfer(accountID: String, routingNumber: String)
    case applePay
    case cash
}

let method = PaymentMethod.creditCard(number: "4111111111111111", expiry: "12/26")

No struct needed. The data lives inside the case itself.

Extract the values with pattern matching in a switch:

switch method {
case .creditCard(let number, let expiry):
    print("Card ending \(number.suffix(4)), expires \(expiry)")
case .bankTransfer(let account, _):
    print("Bank transfer from account \(account)")
case .applePay:
    print("Apple Pay")
case .cash:
    print("Cash payment")
}

The compiler forces you to handle every case. Miss one and it won’t build. That exhaustiveness is a feature, not a constraint.

Modeling State with Enums

This is where enums go from useful to indispensable. Consider a network request that can be in one of several states:

enum LoadingState<T> {
    case idle
    case loading
    case loaded(data: T)
    case failed(error: Error)
}

Now your view model holds exactly one value of this type instead of three separate booleans and an optional:

// Before — fragile, easy to get into impossible states
var isLoading = false
var data: [User]?
var error: Error?

// After - only valid states are representable
var state: LoadingState<[User]> = .idle

A state where isLoading is true AND error is set? Not possible with the enum. This is called making invalid states unrepresentable and it's one of the most valuable design principles in Swift.

Enums with Methods and Computed Properties

Enums aren’t just data containers. They can have behavior too.

enum Suit: String, CaseIterable {
    case hearts = "♥"
    case diamonds = "♦"
    case clubs = "♣"
    case spades = "♠"

    var isRed: Bool {
        self == .hearts || self == .diamonds
    }

    func label() -> String {
        "\(rawValue) (\(isRed ? "red" : "black"))"
    }
}

print(Suit.hearts.label())     // ♥ (red)
print(Suit.allCases.count)     // 4 - CaseIterable gives you this for free

CaseIterable synthesizes an allCases array automatically. Useful for populating pickers, iterating every case in tests, or building menus.

Indirect Enums: Recursive Structures

For tree structures and recursive data, mark the enum indirect:

indirect enum TreeNode {
    case leaf(value: Int)
    case branch(left: TreeNode, right: TreeNode)
}

let tree = TreeNode.branch(
    left: .leaf(value: 3),
    right: .branch(
        left: .leaf(value: 7),
        right: .leaf(value: 12)
    )
)

Without indirect, the compiler can't determine the size of the type at compile time. The keyword tells it to store associated values on the heap instead.

Real-World Pattern: API Error Modeling

enum APIError: Error {
    case unauthorized
    case notFound(resource: String)
    case rateLimited(retryAfter: TimeInterval)
    case serverError(code: Int, message: String)
    case networkUnavailable
}

func handle(_ error: APIError) {
    switch error {
    case .unauthorized:
        redirectToLogin()
    case .notFound(let resource):
        showAlert("Could not find \(resource)")
    case .rateLimited(let seconds):
        scheduleRetry(after: seconds)
    case .serverError(let code, let message):
        logError(code: code, message: message)
    case .networkUnavailable:
        showOfflineBanner()
    }
}

Each error case carries exactly the data it needs. The switch handles all of them. No strongly-typed error messages, no integer error codes compared with magic numbers, no optional unwrapping chains.

Interview Questions

Q: What is the difference between raw values and associated values in Swift enums?

Raw values are fixed primitive values attached to each case at definition time. Every case of the same enum has the same type. Associated values are dynamic data attached when you create a case. Different cases can carry different types and different amounts of data. Raw values are set in the enum definition; associated values are set at the call site.

Q: What does “making invalid states unrepresentable” mean?

It means structuring your types so the compiler physically cannot represent a state that shouldn’t exist in your app. A classic example: replacing isLoading: Bool, data: T?, and error: Error? with a single LoadingState<T> enum. With three separate booleans, you can accidentally set isLoading = true and error = someError simultaneously. With the enum, only one state exists at a time. The compiler enforces it.

Summary

• Enums define a type with a fixed, exhaustive set of cases.
• Raw values attach a primitive to each case at definition time, useful for API mapping.
• Associated values let each case carry its own data, with different types per case.
• Swift’s switch is exhaustive on enums: every case must be handled or it won’t compile.
• Enums can have methods, computed properties, and protocol conformances.
• CaseIterable gives you an allCases array for free.
• indirect enables recursive enum structures like trees.
• Modeling state with enums makes invalid states unrepresentable at the type level.

Practice

1. Beginner: Create a Season enum with four cases. Add a computed property isWarm: Bool and a description: String that returns a short sentence about each season. Iterate all cases using CaseIterable and print the descriptions.
2. Intermediate: Model a Notification enum with cases for message(from: String, text: String), friendRequest(from: String), paymentReceived(amount: Double, currency: String), and systemAlert(title: String). Write a function that takes a Notification and returns the string to display in a push notification banner.
3. Advanced: Build a Result<Success, Failure: Error> type from scratch as a custom enum (don't use Swift's built-in). Add a map method that transforms the success value, a mapError method that transforms the failure, and a get() throwing method that returns the success value or throws the error. Then explain why Swift's standard library already provides this and when you'd use your own instead.

What’s Next

Article 11: Swift Optionals: nil, Unwrapping, and the Safety System Behind the ?

Enums taught you how Swift models “this case or that case.” Optionals are built on exactly the same mechanism: a value is either .some(wrapped) or .none. Understanding optionals at that level changes how you read and write Swift forever.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If associated values just opened up new ways to model your data, tap 👏 up to 50 times and repost 🔁. It helps this series reach developers who are still using strongly state.

Follow me so Article 11 lands in your feed automatically. Optionals are next, and there is a lot more to them than the ? symbol suggests.

See you in the next one. 🚀

Why Classes Still Matter

Structs are Swift’s default. But open any UIKit file and you’re in class territory immediately. UIViewController, UIView, URLSession, NotificationCenter all classes. Understanding why these aren't structs is what makes you a better architect, not just a better syntax writer.

What Is a Class in Swift?

A class is a reference type a blueprint that lives on the heap. When you create an instance, Swift allocates memory for it and hands you a reference (a pointer) to that memory. Every variable that “holds” the class instance actually holds a pointer to the same object.

class Vehicle {
    var make: String
    var speed: Double

    init(make: String, speed: Double) {
        self.make = make
        self.speed = speed
    }

    func describe() -> String {
        "\(make) going \(speed) km/h"
    }
}

let car = Vehicle(make: "Tesla", speed: 120)
print(car.describe())  // Tesla going 120 km/h

Unlike structs, classes don’t get a free member wise initializer. You write init yourself.

Reference Semantics in Practice

This is the single most important thing to understand about classes.

var car1 = Vehicle(make: "Tesla", speed: 100)
var car2 = car1       // car2 is NOT a copy — it's the same object

car2.speed = 200
print(car1.speed)  // 200 - car1 changed too
print(car2.speed)  // 200

Both car1 and car2 point to the same Vehicle in memory. Changing one changes both. This isn't a bug it's the feature. Sometimes you want shared mutable state. A music player's AudioSession, a user's AuthManager, a network layer's URLSessionthese should exist once and be shared everywhere.

That’s exactly when a class earns its place.

Inheritance Extending Behavior Without Rewriting It

Classes support inheritance. A subclass gets all the properties and methods of its parent and can override or extend them.

class Animal {
    var name: String

    init(name: String) {
        self.name = name
    }

    func sound() -> String {
        "..."
    }
}

class Dog: Animal {
    override func sound() -> String {
        "Woof"
    }

    func fetch() {
        print("\(name) fetches the ball!")
    }
}

let dog = Dog(name: "Bruno")
print(dog.sound())   // Woof
dog.fetch()          // Bruno fetches the ball!

The override keyword is required the compiler enforces it. You can't accidentally override a method. You have to mean it.

final Preventing Further Subclassing

final class PaymentProcessor {
    // No one can subclass this
}

Mark a class final when subclassing would break its invariants or when you want the compiler to enable direct method dispatch (faster than dynamic dispatch). Apple marks many of their classes final for exactly this reason.

deinit Cleanup When an Object Dies

Classes have a deinitializer that runs automatically when the last reference is released.

class DatabaseConnection {
    let connectionID: String

    init(id: String) {
        self.connectionID = id
        print("Connection \(id) opened")
    }

    deinit {
        print("Connection \(connectionID) closed")
        // Close socket, release file handles, cancel timers
    }
}

var conn: DatabaseConnection? = DatabaseConnection(id: "db_001")
// prints: Connection db_001 opened
conn = nil
// prints: Connection db_001 closed - deinit fired automatically

Structs don’t have deinit. If you need guaranteed cleanup file handles, network sockets, observers, timers you need a class.

How ARC Manages Class Memory

Swift uses Automatic Reference Counting to track how many references point to each class instance. When the count hits zero, deinit runs and the memory is freed.

var a: Vehicle? = Vehicle(make: "BMW",
                         speed: 80)  // ref count: 1
var b = a                            // ref count: 2
a = nil                              // ref count: 1
b = nil                              // ref count: 0 → deinit fires

This is automatic you don’t call free() or delete. But ARC isn't free of footguns. Retain cycles (covered in Article 7 on closures) can keep the count above zero permanently, leaking the object forever. Classes require more discipline than structs precisely because of this.

Class Properties: static vs class

Both belong to the type, not an instance. The difference is overridability.

class Shape {
    static var defaultColor = "black"   // cannot be overridden
    class var description: String {     // can be overridden by subclasses
        "A generic shape"
    }
}

class Circle: Shape {
    override class var description: String {
        "A circle"
    }
}

print(Shape.description)   // A generic shape
print(Circle.description)  // A circle

Use static when the value should never change per subclass. Use class when subclasses should be able to customize it.

Real-World Pattern: Singleton Service

The most common class-specific pattern in iOS:

final class AnalyticsService {
    static let shared = AnalyticsService()

    private init() {}  // Prevents external instantiation

    func track(event: String, properties: [String: Any] = [:]) {
        // Send to analytics backend
        print("Event: \(event), props: \(properties)")
    }
}

// Usage anywhere in the app
AnalyticsService.shared.track(event: "user_login")

One instance, shared across the entire app. This only makes sense as a class a struct would give every call site its own copy, which defeats the purpose entirely.

Classes vs Structs: The Real Decision Framework

Question Answer → Does this model data? Struct Does multiple code share the same instance? Class Do you need inheritance? Class Do you need deinit for cleanup? Class Should copies be independent? Struct Is this a UIKit component? Class (UIKit requires it) Is this a SwiftUI view? Struct (SwiftUI requires it)

When in doubt, start with a struct. The compiler will tell you when you actually need a class.

Interview Questions

Q: What is a class in Swift and how does it differ from a struct?

A class is a reference type instances live on the heap and multiple variables can share the same object. Structs are value types each assignment creates an independent copy. Classes support inheritance and deinit; structs don't. Classes are managed by ARC and can form retain cycles; structs are stack-allocated (generally) and don't have this risk.

Q: When would you choose a class over a struct?

Choose a class when you need shared mutable state across multiple parts of the app, when you need deinit for resource cleanup, when you're subclassing (UIKit, for example), or when identity matters two references must point to the exact same instance. Everything else defaults to a struct.

Summary

• Classes are reference types assignment shares the object, not a copy.
• Unlike structs, classes require you to write init manually.
• Subclasses inherit all properties and methods; override is required and enforced.
• final prevents subclassing and enables faster method dispatch.
• deinit runs when ARC drops the reference count to zero use it for resource cleanup.
• static properties can't be overridden; class properties can.
• Singletons are the canonical class pattern one shared instance for services.
• Default to structs. Reach for classes when you have a specific reason.

Practice

1. Beginner: Create a BankAccount class with owner: String, balance: Double, and init. Add deposit() and withdraw() methods. Create two variables pointing to the same account and show that a deposit on one is reflected in the other.
2. Intermediate: Build a Logger singleton that stores an in-memory array of log entries (strings). Add log(_ message: String) and clearLogs() methods. Use deinit to print a message showing when the logger would be released then explain why in practice it never fires for a singleton.
3. Advanced: Create a MediaPlayer class with a delegate protocol for playback events. Use a weak delegate reference to avoid a retain cycle. Implement play(), pause(), and stop() and have them notify the delegate. Explain in a comment why the delegate must be weak and what would happen if it weren't.

What’s Next

Article 10: Swift Enums — Associated Values, Raw Values, and Pattern Matching

Enums in Swift are nothing like enums in other languages. They carry data, conform to protocols, have methods, and work as the backbone of Swift’s error handling and state modeling. One of the most powerful features in the entire language and most developers use only 10% of what they can do.

If the struct vs class decision finally clicked, tap 👏 up to 50 times and do re-post 🔁, it directly helps this series reach developers still confused by reference types.

Follow me so Article 10 lands in your feed the moment it’s live. Enums are coming and they’re going to surprise you.

See you in the next one. 🚀

What looks like a simple data container is actually Swift’s most powerful tool for writing safe, predictable, performant code.

Why This Is One of the Most Important Topics in Swift

Apple’s own frameworks are built predominantly with structs. SwiftUI.View is a struct. CGRect is a struct. URL is a struct. Array, Dictionary, String all structs.

This isn’t an accident. It’s a deliberate architectural choice. Understanding why changes how you design every model, every data layer, and every piece of state in your app.

What Is a Struct?

A struct is a value type that groups related data and behavior together.

struct User {
    let id: String
    var name: String
    var age: Int
}

let user = User(id: "usr_001", name: "Aryan", age: 28)
print(user.name)  // Aryan

Swift automatically generates a member-wise initializer you get init(id:name:age:) for free, no code needed.

The Core Idea: Value Semantics

This is what makes structs fundamentally different from classes.

var original = User(id: "usr_001", name: "Aryan", age: 28)
var copy = original   // copy gets its own independent copy

copy.name = "Riya"
print(original.name)  // "Aryan" - completely unaffected
print(copy.name)      // "Riya"

When you assign a struct, you get a real copy. Changing one never affects the other. This is called value semantics and it eliminates an entire class of bugs.

Compare this to a class:

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

var original = UserClass(name: "Aryan")
var copy = original   // both point to the SAME object

copy.name = "Riya"
print(original.name)  // "Riya" - original was changed too

With a class, copy is not a copy. It's another reference to the same object. Shared mutable state is the source of some of the hardest bugs in iOS development.

Mutating Methods

Struct methods cannot modify properties by default. You must mark them mutating:

struct Counter {
    var count = 0
    mutating func increment() {
        count += 1
    }
    mutating func reset() {
        count = 0
    }
}

var counter = Counter()
counter.increment()
counter.increment()
print(counter.count)  // 2

The mutating keyword is a contract it signals to every reader: "this method changes state." It also enforces that you cannot call it on a let constant:

let fixedCounter = Counter()
fixedCounter.increment()  // ❌ Cannot use mutating member on immutable value

The compiler catches this at build time. No crash. No runtime surprise.

Computed Properties

Structs can have properties that compute their value on demand:

struct Rectangle {
    var width: Double
    var height: Double
    // Computed - no stored value, calculated each time
    var area: Double {
        width * height
    }
    var isSquare: Bool {
        width == height
    }
}

let rect = Rectangle(width: 10, height: 5)
print(rect.area)      // 50.0
print(rect.isSquare)  // false

Computed properties look like stored properties at the call site clean, no method call syntax needed.

Property Observers

React to property changes with willSet and didSet:

struct StepTracker {
    var steps: Int = 0 {
        didSet {
            if steps > 10_000 {
                print("Goal reached! 🎉")
            }
        }
    }
}

var tracker = StepTracker()
tracker.steps = 10_500  // prints: Goal reached! 🎉

Production use: didSet is how you trigger side effects when data changes logging, validation, UI updates in UIKit models.

Static Properties and Methods

Belong to the type itself, not any instance:

struct AppConfig {
    static let version = "2.1.0"
    static let maxRetries = 3
    static let baseURL = "https://api.myapp.com"
    static func buildURL(endpoint: String) -> String {
        baseURL + endpoint
    }
}

print(AppConfig.version)                        // "2.1.0"
print(AppConfig.buildURL(endpoint: "/users"))   // "https://api.myapp.com/users"

No instance needed. Perfect for configuration, constants, and utility functions.

Structs vs Classes When to Use Which

This comes up in every iOS interview. Here’s the honest answer:

Use a struct when:

• Modeling data (User, Product, Order, APIResponse)
• The value should be independent when copied
• You don’t need inheritance
• You want thread safety by default

Use a class when:

• You need a single shared instance (managers, services)
• You need deinit for cleanup
• You’re working with UIKit (which is class-based)
• Identity matters two references must point to the same thing

Apple’s own guideline: default to structs. Only reach for a class when you have a specific reason.

Real-World Pattern: API Response Model

struct APIResponse<T: Decodable>: Decodable {
    let data: T
    let message: String
    let statusCode: Int
    var isSuccess: Bool {
        statusCode >= 200 && statusCode < 300
    }
}

struct Product: Decodable {
    let id: String
    let name: String
    let price: Double
    let inStock: Bool
}

// Usage
let response: APIResponse<Product> = try JSONDecoder().decode(...)
if response.isSuccess {
    display(response.data)
}

Structs + Decodable is the standard pattern for parsing API responses in production iOS apps. Value semantics means your parsed models are safe to pass across layers without unexpected mutation.

How Swift Optimizes Struct Memory

Swift doesn’t always copy structs immediately. It uses Copy-on-Write (CoW) for collections the copy only happens when you actually mutate the new value.

var array1 = [1, 2, 3, 4, 5]
var array2 = array1   // No copy yet — they share the same buffer
array2.append(6)      // NOW the copy happens - array1 is unaffected

You get value semantics without paying the full copy cost until it’s necessary. This is why passing large arrays around in Swift is cheaper than it looks. (We’ll cover CoW in depth in Phase 3.)

Interview Question

Q: What’s the difference between a struct and a class in Swift, and when would you choose one over the other?

Structs are value types assignment creates an independent copy. Classes are reference types assignment creates another reference to the same object. Structs live on the stack (generally), are thread-safe by default, and don’t support inheritance. Classes live on the heap, support inheritance, and share state across references.

Choose a struct for data models, API responses, and anything where independence on copy is valuable. Choose a class when you need shared state, lifecycle management via deinit, or when interfacing with UIKit. Apple's official guidance: default to structs, and only use a class when you have a concrete reason.

Summary

• Structs are value types every assignment is an independent copy.
• Classes are reference types assignment shares the same object.
• mutating methods signal and enforce state changes on structs.
• Computed properties calculate values on demand clean call site, no method syntax.
• didSet / willSet react to property changes without subclassing.
• Static properties and methods belong to the type, not any instance.
• Default to structs. Use classes when you specifically need reference semantics.
• Swift uses Copy-on-Write copies are deferred until mutation occurs.

Practice

1. Beginner: Create a Temperature struct with a stored property celsius: Double and computed properties fahrenheit and kelvin. Add a mutating func increase(by degrees: Double) method.
2. Intermediate: Model a shopping cart as a struct with an array of CartItem structs. Add mutating methods to add, remove, and clear items, and a computed property for totalPrice. Demonstrate that copying the cart gives you an independent snapshot.
3. Advanced: Create a generic Stack<T> struct with mutating push(), mutating pop(), and a peek computed property. Make it conform to CustomStringConvertible for clean print output. Then explain in a comment why Stack as a struct is safer than Stack as a class in a multi-function codebase.

What’s Next

Article 9: Swift Classes — Reference Types, Inheritance, deinit, and When They Beat Structs

You now know structs deeply. Next: classes when shared identity matters, how inheritance works in Swift, what deinit gives you, and why UIKit is entirely class-based. Understanding both sides of this divide makes you a far more intentional architect.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If structs finally make sense as a design choice not just syntax tap 👏 up to 50 times and do 🔁. It helps this series reach developers making the same struct vs class mistakes every day.

Follow me so Article 9 lands in your feed automatically. Classes build directly on everything you just learned.

See you in the next one. 🫡