Swift

Value types vs. reference types: why it matters

Swift's type system draws a sharp line between value semantics (structs, enums) and reference semantics (classes). When you assign or pass a struct, the entire value is copied — each variable has its own independent data. When you assign a class, only the reference is copied — both variables point to the same object. This distinction matters enormously for correctness: a function that modifies a struct parameter affects only its local copy; a function that modifies a class instance affects every reference to that object. Apple's frameworks (SwiftUI especially) are built heavily on value types and Copy-on-Write (CoW) optimisation — actual copying is deferred until mutation, so most copies are O(1).

Swift Concurrency: async/await and actors

Swift 5.5 (2021) introduced first-class concurrency: async/await, Task, TaskGroup, and actors. An actor is a reference type that serialises access to its mutable state — only one task can access actor state at a time, eliminating data races at compile time. The Swift compiler performs actor isolation checking — it is a compile error to access actor-isolated state from outside the actor without await. @MainActor marks code that must run on the main thread (UI updates).

import Foundation

// Async function
func fetchUser(id: Int) async throws -> String {
    try await Task.sleep(nanoseconds: 100_000_000)  // 0.1s
    return "User\(id)"
}

// Structured concurrency — parallel tasks
func fetchAll() async throws {
    async let user1 = fetchUser(id: 1)
    async let user2 = fetchUser(id: 2)
    let (u1, u2) = try await (user1, user2)   // run in parallel
    print("\(u1) and \(u2)")
}

// Actor — safe shared mutable state
actor Counter {
    private var count = 0
    func increment() { count += 1 }
    func value() -> Int { count }
}

// Usage
Task {
    let counter = Counter()
    await counter.increment()
    print(await counter.value())
}

// @MainActor — guarantees UI thread
@MainActor
func updateLabel(text: String) {
    // label.text = text  — safe: always on main thread
}

Generics and opaque types

Swift generics are fully reified — the compiler generates specialised code per type. Swift 5.7 (2022) added primary associated types and simplified protocol use with some (opaque type) and any (existential type). some View means "some specific conforming type, chosen by the callee" — the compiler knows the concrete type at compile time. any View means "any type conforming to View" — dynamic dispatch at runtime. SwiftUI's body: some View is the canonical use of opaque types.

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

// Generic struct with constraint
struct Pair<T: Comparable> {
    let first: T
    let second: T
    var min: T { first < second ? first : second }
}

// some — opaque return type (compiler knows concrete type)
func makeShape() -> some Shape {
    return Circle(radius: 5)   // caller gets a Shape but not the concrete type
}

// any — existential (dynamic dispatch)
func printShape(_ shape: any Shape) {
    print(shape.area())
}

// Protocol with associated type
protocol Container {
    associatedtype Element
    func add(_ item: Element)
    func all() -> [Element]
}

SwiftUI and the declarative UI paradigm

SwiftUI (introduced 2019) is Apple's modern UI framework built on Swift's type system. Views are structs conforming to the View protocol. UI is described declaratively — you describe what the UI should look like given the current state, and SwiftUI handles the rendering and diffing. State is managed with property wrappers: @State (local view state), @StateObject/@ObservedObject (reference type state), @Binding (two-way binding), @EnvironmentObject (injected dependency). SwiftUI previews compile and render instantly in Xcode.

Swift's memory model: ARC and weak references

Swift uses Automatic Reference Counting (ARC) for memory management — not a tracing garbage collector. ARC inserts retain and release calls at compile time (not runtime). When a class instance's reference count drops to zero, it is immediately deallocated. ARC is deterministic — deallocation happens at a known point, not at some future GC pause. However, ARC cannot automatically resolve reference cycles: if object A holds a strong reference to B and B holds a strong reference to A, neither will ever be deallocated. The fix: weak references (automatically becomes nil when the object is deallocated) and unowned references (crash if accessed after deallocation, like !). Closures that capture self must use [weak self] or [unowned self] capture lists to break cycles.

The Swift compiler and LLVM

Swift is compiled by the Swift compiler (swiftc) which uses LLVM as its backend. The frontend performs parsing, semantic analysis, type checking, and Swift Intermediate Language (SIL) generation. SIL is a high-level IR that enables Swift-specific optimisations: devirtualisation, generic specialisation, and ARC optimisation (coalescing retain/release pairs, eliminating redundant retains). SIL then lowers to LLVM IR, where standard LLVM optimisation passes run. The whole-module optimisation mode (-O whole-module) allows the compiler to see and optimise across all source files simultaneously.

Swift evolution and ABI stability

Swift's evolution process (Swift Evolution, github.com/apple/swift-evolution) governs language changes through a proposal system. Swift 5.0 (March 2019) achieved ABI stability — binary compatibility between Swift modules compiled with different compiler versions on Apple platforms. Before Swift 5, every app had to bundle its own copy of the Swift runtime. After ABI stability, the Swift runtime is part of the OS (iOS 12.2+, macOS 10.14.4+), reducing app binary sizes. Swift 5.9 (2023) added macros — compile-time code generation.