Swift interview questions and answers

Core Difference

A let does not have to be a compile-time constant. It can be initialized at runtime. What matters is that the binding is never assigned another value afterward.

Mutability of Referenced Objects

let fixes the binding, not necessarily the state of the object it refers to. Reference types such as classes are mutable through their mutable properties and methods, even when the instance is held by a constant.

The session binding cannot later refer to a different Session, but the existing object’s properties can change. In contrast, a let binding to a struct or array prevents mutations that would change that stored value. For example, changing a mutable stored property of a struct, or adding or removing an array element, is not allowed through a let binding.

If a value type contains a reference to a class, the value-type container is still protected by let, but the referenced class object may still be mutated through its own mutable properties or methods.

Initialization and Scope

• Stored properties: A stored property declared with let must receive its initial value during initialization, either in its declaration or in the type’s initializer.

• Local constants: A local let must be initialized before its first use. Swift’s definite-initialization analysis can often determine this from the surrounding control flow.

• Shadowing: A new constant or variable may use the same name in a nested scope. The new declaration shadows the previous one, so the outer declaration remains accessible after the nested scope ends.

Best Practices and Concurrency

• Prefer let by default and use var only when reassignment is necessary. This makes the intended mutability clear and reduces accidental state changes.

• Do not treat let as deep immutability. For a class instance, its mutable properties may still change even when the instance is held by a constant.

• Use value types such as structs for independently copied, predictable state. Use classes when shared reference identity or shared mutable behavior is required.

• Under Swift 6 strict concurrency checking, let does not make a non-Sendable value safe to share. Values crossing concurrency domains must still satisfy the relevant Sendable requirements.

How They Work

An optional type adds the ? suffix to another type:

• String?: either a String or no value.

• Int?: either an Int or no value.

• [User]?: either an array of User values or no value.

Swift models these states using Optional.some(value) and Optional.none. In ordinary code, you normally interact with the wrapped value rather than constructing those cases directly.

Optionals can wrap both value types and reference types. For example, URL? stores either a URL value or nil, while URLSession? stores either a reference to a URLSession or nil.

Unwrapping Safely

Accessing an optional directly requires unwrapping. The compiler forces you to account for the possibility of nil, which prevents accidental use of a missing value.

• if let binding: Uses a value only when it exists.

if let user = currentUser { ... }

• Shorthand optional binding: Swift 5.7 and later can infer the local name.

if let currentUser { ... }

• guard let binding: Requires the value to exist before continuing in the current scope.

guard let response = response else { return }

• Optional chaining: Accesses properties or calls methods only when the optional contains a value. The entire expression produces another optional.

user?.profile.displayName

• Nil-coalescing operator: Supplies a fallback when the original optional is nil.

let name = suppliedName ?? "Guest"

• Optional map and flatMap: Transform an optional’s contained value while preserving optionality. map can create nested optionals; flatMap avoids that nesting.

Why They Improve API Design

Optionals communicate intent clearly:

• A failed network request can return Data?.

• A dictionary lookup can return Value?.

• A property that has not yet been assigned can have type String?.

• A search operation can return [Result]?, distinguishing “no search performed” from an empty result array.

This is especially useful in SwiftUI. A view property such as selectedItem: Item? can naturally represent no current selection, and SwiftUI updates when that state changes.

Optionals and JSON

Swift’s Codable framework maps JSON null to nil for optional properties. Missing JSON keys and explicit JSON null both usually decode as nil for an optional property.

By contrast, a non-optional property must be present and contain a compatible value. If that requirement is not met, decoding throws an error rather than silently creating nil.

Best Practices and Common Pitfalls

• Prefer optional binding over force unwrapping with !. Force unwrapping crashes when the value is nil.

• Use implicitly unwrapped optionals (Type!) sparingly. They are mainly appropriate where initialization is guaranteed by the surrounding framework, such as some Objective-C interoperability boundaries.

• Do not use optionals merely to avoid handling invalid states in core business logic. Validate required input and throw a clear error when invalid values are exceptional.

• Remember that optionality describes the presence of a value, not necessarily why it is absent. Additional state or a throwing API may be needed when different failure reasons matter.

• In Swift 6 language mode, strict concurrency checking is enabled. If an optional crosses concurrency domains, its wrapped type should conform to Sendable just as it would when used without optionality.

How Tuples Work

A tuple can contain values of different types, including a fixed number of elements:

• (42, "Swift") groups an Int and a String.

• (name: "Taylor", score: 95) adds labels that make each element easier to identify.

• Elements are accessed by numeric position, such as .0 and .1, or by label, such as .name and .score.

• Labels improve readability but do not change the tuple’s underlying structure.

• Tuples cannot grow or shrink after creation.

Unlike arrays and dictionaries, tuples do not define a separate named type. They are best suited to small, fixed collections rather than general-purpose collections of application data.

Common Uses

• Grouping related values: Represent coordinates, HTTP status information, or a user’s name and score without introducing a new type.

• Returning multiple values: A function can return one tuple containing several related results.

• Destructuring: A tuple can be decomposed into separate constants or variables during assignment.

• Matching patterns: switch statements can inspect tuple contents and match combinations of values.

• Traversing collections: Dictionary iteration produces a tuple containing its key and value.

• Testing values in closures: A closure can return a tuple when several related results are needed.

Value Semantics and ARC

Tuples are value types. Assigning a tuple to another variable or passing it to a function normally copies its values:

• A tuple containing only value types such as Int, String, or Struct remains independent after copying.

• If a tuple contains a class instance, the tuple value is copied, but both tuples still reference the same class object.

• Mutating an element of one tuple therefore does not affect the other when the element itself is a value type.

This differs from classes, whose instances are reference types. Arrays and dictionaries are also value types (structs) but use copy-on-write optimization to avoid unnecessary copies.

Tuples Versus Other Types

Use a struct when the data represents a meaningful domain concept, must be passed around repeatedly, or benefits from methods and protocol conformances. For example, a UserProfile struct is usually clearer than a repeated (name: String, age: Int) tuple.

Limitations and Best Practices

• Avoid relying on positional access such as .0 in unfamiliar code because its meaning is not immediately obvious.

• Prefer labels when elements have distinct meanings, but avoid labels that merely repeat their types.

• Do not use tuples as substitutes for arrays when the number of elements needs to change.

• Remember that tuple types do not provide the same protocol-conformance and generic-constraint capabilities available to named types.

• Use structs for public APIs, persistent models, and values that require behavior; use tuples mainly for local, short-lived groupings.

The Three Core Collections

• Array<Element>, written [Element]: keeps insertion order, accesses elements by a zero-based Int index, and allows duplicates. Best default when order matters or you iterate sequentially.

• Dictionary<Key, Value>, written [Key: Value]: maps unique keys to values; Key must conform to Hashable. Subscripting with a missing key returns Value?, which is why dictionary lookups are naturally optional-handling code.

• Set<Element>: stores unique elements with no defined order; Element must conform to Hashable. It adds set algebra — union(_:), intersection(_:), subtracting(_:), symmetricDifference(_:), isSubset(of:), isDisjoint(with:).

Declaring any of them with let makes it immutable; only a var gets access to mutating methods such as append(_:), insert(_:) or remove(at:).

Ordering and Performance

Hash-based operations degrade to O(n) if many keys collide, and because Swift randomizes hash seeds per process, iteration order of Dictionary and Set can differ between runs — never rely on it.

Value Semantics, Copy-on-Write and Sendable

• All three are structs, so assignment and parameter passing copy the value: mutating the copy never affects the original.

• The copy is cheap because the storage is shared until one side mutates it (copy-on-write); only then is the buffer duplicated.

• They conform to Sendable conditionally: [Int], [String] or an array of a Sendable struct can safely cross actor boundaries or be captured by a Task. A collection of non-Sendable class instances is not Sendable, and strict concurrency checking in the Swift 6 language mode reports passing it into an actor.

• Views such as ArraySlice, Substring and Dictionary.Values share storage with their parent and keep the whole buffer alive; convert with Array(slice) when you keep a small fragment for a long time.

Beyond the Standard Library

• String is itself a Collection of Character, so generic algorithms over sequences work on text too.

• Swift Collections (added through Swift Package Manager) provides Deque for O(1) insertion at both ends, OrderedSet and OrderedDictionary for hash lookup plus insertion order, Heap, BitSet, and in recent releases sorted tree-based TreeDictionary and TreeSet.

• Foundation offers the Objective-C reference types NSArray, NSDictionary and NSSet, which bridge automatically to their Swift counterparts; new Swift code should prefer the native value types.

Choosing and Using Them

• Use a Set rather than an Array whenever the main operation is membership testing: set.contains(x) is O(1) but array.contains(x) is O(n).

• Choose OrderedDictionary from Swift Collections when you need both key lookup and stable iteration order.

• Make your own types Hashable; Swift synthesizes Equatable and Hashable when every stored property conforms.

• Never mutate a collection while iterating it; use removeAll(where:) or iterate over a copy.

• Call reserveCapacity(_:) before appending many elements to avoid repeated reallocations.

• Prefer let collections: immutability is both safer and friendlier to Swift 6 concurrency checking.

Core Control-Flow Tools

• if and else: Evaluate one or more Boolean conditions.

• guard: Require a condition to succeed; otherwise exit the current scope. A guard body must transfer control, commonly with return, throw, break, or continue.

• switch: Match a value against exhaustive cases. Unlike languages with implicit fallthrough, Swift does not execute the next case unless the programmer explicitly uses fallthrough.

• for-in: Iterate over a sequence, including collections, ranges, and dictionary elements.

• while: Repeat a body while a condition remains true.

• repeat-while: Execute a body at least once and then repeat it while the condition is true.

Conditions and Pattern Matching

Swift conditions can use comparisons, ranges, Boolean values, and pattern matching. For example, an if‑else chain can assign a grade based on a score:

• if score >= 90 { grade = "A" } else if score >= 80 { grade = "B" } else { grade = "C" }

Optional binding safely unwraps an optional value:

• if let username = currentUsername { print(username) }

In Swift 6, the shorthand form is also supported:

• if let currentUsername { print(currentUsername) }

Use guard when continuing without the unwrapped value would be invalid:

• guard let user = currentUser else { return }

A switch can combine value patterns, ranges, and where clauses:

• switch statusCode { case 200...299: print("Success"); case 400...499: print("Client error"); case let code where code >= 500: print("Server error: \(code)"); default: print("Other response") }

For an exhaustive switch over an enum or similar type, a default clause may be unnecessary because the compiler verifies that every case is handled.

Choosing a Loop

Additional loop features include:

• for value in 1...5 includes both endpoints, while 1..<5 excludes the upper endpoint.

• for case let value in values where value > 0 iterates only over values matching a pattern.

• Iterating a dictionary produces its key-value elements, but dictionary order is unspecified.

• break exits a loop, while continue starts the next iteration.

• Labels can identify a particular loop when nested.

Best Practices and Common Pitfalls

• Prefer for-in instead of index-based iteration when the index is unnecessary.

• Use guard for validation and early exit; it keeps the successful path free of deeply nested conditionals.

• Remember that switch cases do not fall through automatically.

• Ensure every while condition can eventually become false.

• Remember that repeat-while always executes once, even when its condition is initially false.

• In Swift 6 language mode, strict concurrency checking is enabled. Mutable state shared across concurrency domains must still be isolated appropriately, such as within an actor, or satisfy the relevant Sendable rules.

Enumerations in Swift

• Definition: enum Direction { case north, south } creates a closed set of cases. Unlike C-style enums, Swift cases are not integers and have no implicit ordering.

• Value semantics: An enum is a value type. Assignment and parameter passing preserve value semantics, although a class instance stored as a payload remains a reference.

• Members: Enums can define computed properties, methods, initializers, subscripts, nested types, and protocol conformances.

• Exhaustiveness: A switch over an enum must normally cover every case, allowing the compiler to identify missing branches. Optional and Result are library enums.

• Raw values versus associated values: A raw-value enum gives every case a value of one shared raw type, such as String. Explicit raw values must be unique, and an enum cannot combine a raw type with cases that take associated-value arguments.

How Associated Values Work

• Per-case payloads: A case such as card(number: String, expiry: String) can coexist with a case such as cash. Payload types are declared by each individual case rather than by the enum as a whole.

• Optional labels: case point(Double, Double) and case point(x: Double, y: Double) are both valid. Labels make patterns and call sites easier to understand.

• Different data per instance: Two .card values can contain different card numbers because the payload is part of each enum value.

• Recursion: An enum can contain itself directly only when the relevant case or enum is marked indirect, as commonly used for expression trees.

• Synthesized conformances: An enum with associated values can synthesize Equatable, Hashable, and Codable conformance when the enum declares those conformances and every associated value satisfies the corresponding requirements. The synthesized Codable representation includes the case name and payload labels, so renaming a case or labeled payload changes that JSON representation.

Extracting Associated Values

1. A switch pattern binds associated values and normally requires exhaustive case coverage.

2. if case, guard case, for case, and while case can match a particular case without a full switch.

3. case let .success(data) is shorthand for binding the single associated value of .success; case .success(let data) is equivalent. A case with multiple values uses separate bindings such as case let .point(x, y).

4. A where clause can filter a case pattern using the bound payload values.

Semantics, Protocols and Concurrency

• Storage and ARC: Associated-value data is stored within the enum value. If a payload is a class instance, the enum holds a strong reference to it, and a reference cycle is possible if that class refers back to the enum.

• Protocol-oriented design: Enums can conform to protocols and be exposed through some or any protocol types while retaining a closed set of states internally.

• Sendable: An enum can conform to Sendable when every associated value is Sendable. Public enums should declare that conformance explicitly, while non-public enums may infer it. An enum with a non-Sendable payload cannot receive normal checked Sendable conformance. Swift 6 strict concurrency checking diagnoses unsafe attempts to send non-Sendable values across actor isolation boundaries, although region-based isolation can permit some transfers that remain within a connected isolation region.

Best Practices and Pitfalls

• Prefer associated values over a structure containing several mutually exclusive optional properties when modeling states such as loading, loaded(Item), and failed(LoadError). Use a Sendable error type when the state must cross concurrency domains.

• CaseIterable is not synthesized for an enum with associated values because the compiler cannot enumerate every possible associated-value instance. Expose a separate finite collection or property when a finite set of values is needed.

• Avoid default: when switching over your own enums because it can hide newly added cases. Adding a case to a public enum is source-breaking for callers with exhaustive switches.

• Reserve @unknown default for non-frozen enums imported from another module when using library evolution.

• Use indirect only when recursive enum values are genuinely required, and give associated values clear labels for readable patterns and call sites.

Exhaustiveness the Compiler Enforces

• No default needed for enums: switching over an enum must handle every case, or the code does not compile. Add a case to the enum later and each non-exhaustive switch becomes a compile error, pointing at exactly the sites that need updating. In C, C++ and classic Java, a missing branch is silently skipped.

• Bool and Optional are provably exhaustive: case true/case false, or case .some(let value)/case .none, need no default.

• default is still required for types with an unbounded set of values, such as Int or String.

• @unknown default handles non-frozen enums imported from another module or an Apple framework: exhaustive now, with a compiler warning if a future version adds a case. A plain default silences that warning.

No Implicit Fallthrough

• Only the matched case runs, then control leaves the switch; no break is needed and the accidental fall-through bugs familiar from C or traditional Java cannot happen.

• Inside a loop, continue in a case body continues the loop, not the switch.

• fallthrough exists when you genuinely want to enter the next case body, but it does not test the next case’s conditions — it jumps straight into that body.

Patterns Swift Supports

• Range patterns: case 0..<10, case 100....

• Tuple patterns: case (0, 0), case (_, let y).

• Value binding: case let .success(data) extracts the associated value.

• where guards: a case can add a boolean condition on the bound values.

• Type-casting patterns: case let text as String, case is Int.

• Multiple patterns per case: case .up, .down:.

• Swift matches any type usable with the ~= operator, so switching on String, Double or your own Equatable types works, unlike C where the expression must be integral.

• Enum cases with associated values can be matched precisely or partially, and by label, not just by position.

Switch as an Expression

Since Swift 5.9 a switch can produce a value, so you can assign it, return it, or embed it in a collection literal. Every branch must be exhaustive and yield the same type; break and fallthrough are not allowed there. This replaces many if/else if chains that would otherwise end in a forced unwrap.

How It Compares

Java 21 finalized pattern matching for switch and C# has had pattern-based switch expressions since C# 8, so the remaining Swift advantages are exhaustiveness, ranges, tuple patterns and where clauses.

Best Practices and Pitfalls

• Avoid default on your own enums: it defeats the exhaustiveness check and hides new cases from the compiler.

• Use @unknown default for non-frozen enums from other modules so future cases warn instead of breaking silently.

• Do not use fallthrough to share code; list several patterns in one case or extract a helper function instead.

• Keep where clauses cheap and readable; heavier logic belongs in the case body.

• Prefer switching over enums to switching over raw Int codes followed by if chains.

How It Works

• Local inference: When you write let count = 42, the compiler sees the integer literal and infers Int. For let name = "Swift", it infers String.

• Contextual inference: The expected type from the surrounding context guides inference. In let numbers: [Int] = [1, 2, 3], the array literal infers [Int] because the variable annotation demands it. Similarly, passing a closure to a function lets the compiler infer parameter and return types from the function’s signature.

• Expression-level inference: Complex expressions like let result = someValue + 10 infer the type by combining the known type of someValue with the literal 10.

Key Scenarios

• Variables and constants: var score = 0 → Int; let pi = 3.14159 → Double (default floating-point literal type).

• Collections: let names = ["Ada", "Grace"] → [String]; let scores = [95, 87, 92] → [Int].

• Closures: let doubler = { (x: Int) in x * 2 } can be shortened to let doubler = { $0 * 2 } when the context provides the type, e.g., let transform: (Int) -> Int = { $0 * 2 }.

• Generics: let empty = [] requires an explicit type annotation (e.g., let empty: [String] = []) because there is no element to infer from.

Interaction with Optionals

• let optionalName: String? = "Taylor" is explicit; let optionalName = "Taylor" infers String, not String?. To get an optional you must either annotate or assign nil: let optionalName = Optional("Taylor") or var optionalName: String? = nil.

Type Inference and Generics

• Generic functions infer type parameters from arguments: func identity<T>(_ value: T) -> T { value } called as identity(42) infers T == Int.

• In Swift 6, strict concurrency checking may require explicit Sendable conformances on inferred closure types when crossing actor boundaries.

Limitations and Explicit Annotations

• Ambiguous literals: Integer literals default to Int; floating-point literals default to Double. For Float, CGFloat, or Decimal you must annotate: let rate: Float = 0.15.

• Protocol types: let animal: any Animal = Dog() requires the any keyword (Swift 5.7+) or an explicit type; inference would give the concrete type Dog.

• Complex closures: When the compiler cannot infer parameter types from context, you must write them: let handler = { (data: Data, response: URLResponse?) in … }.

Best Practices

• Prefer inference for local variables and simple expressions; it reduces noise and keeps code readable.

• Add explicit types for public APIs, stored properties, and when the inferred type would be unexpectedly broad (e.g., Any from heterogeneous literals).

• Use type placeholders (_) when you want the compiler to infer only part of a type: let numbers: [_] = [1, 2, 3] infers the element type but keeps the array wrapper explicit.

• Enable strict concurrency (-strict-concurrency=complete) to catch inference-related Sendable issues early in Swift 6 language mode.

The Casting Operators

as is also used for bridging between Swift and Foundation types, for example NSString to String, on Apple platforms.

How It Works

Every Swift instance carries dynamic type metadata that the runtime can inspect; type(of: value) exposes it. An upcast with as is purely a compile-time view: for reference types the same instance is shared with no new allocation, and for value types assignment semantics still apply. A downcast, by contrast, is resolved at runtime by checking the class hierarchy or protocol conformance.

• Classes: downcasting walks the inheritance chain, so a UIView can be cast to UIButton only if it really is one.

• Value types: is and as? also work for structs and enums when the source is an existential such as any Shape or Any; the cast succeeds if the concrete value conforms.

• Existentials: converting a concrete Circle to any Shape is an implicit existential conversion; any is the recommended spelling for existential types, and the ExistentialAny upcoming feature makes it mandatory.

• Pattern matching: case let x as T in a switch combines the check and the bind in one step and is the idiomatic form.

Any, AnyObject and Concurrency

• Any: holds a value of any type, including value types and functions; useful for heterogeneous collections like [Any].

• AnyObject: holds only class instances, so it can be used with weak/unowned references.

• Sendable: in Swift 6 language mode Any is not Sendable, and protocol existentials are not Sendable unless the protocol inherits Sendable. They cannot cross an actor boundary or be captured by a @Sendable closure without an error. Prefer concrete Sendable types, or declare any MyProtocol & Sendable.

• Retain cycles: downcasting a reference does not change ownership; delegate-style properties should be weak (class-bound protocols) to avoid cycles.

Code Example

import Foundation

protocol Shape {
    func area() -> Double
}

struct Circle: Shape {
    let radius: Double
    func area() -> Double { .pi * radius * radius }
}

final class Square: Shape {
    let side: Double
    init(side: Double) { self.side = side }
    func area() -> Double { side * side }
}

let shapes: [any Shape] = [Circle(radius: 2), Square(side: 3)]

for shape in shapes {
    // `case let x as T` checks the dynamic type and binds it in one step
    switch shape {
    case let circle as Circle:
        print("circle, area \(circle.area())")
    case let square as Square:
        print("square, area \(square.area())") // square is a class reference
    default:
        print("unknown shape")
    }
}

// `is` for a check only
print(shapes[1] is Square) // true

// `as?` with guard for a conditional downcast
if let circle = shapes[0] as? Circle {
    print(circle.radius)
}

// `as` upcasts and coerces literals at compile time
let anyShape: any Shape = Circle(radius: 1) as any Shape
let ratio = 1 as Double

// Bridging only happens with Foundation on Apple platforms
let legacy: NSString = "hello"
let modern: String = legacy as String

Best Practices and Pitfalls

• Prefer as? over as!: forced casts trap on failure; use guard let or a switch with as patterns instead. Reserve as! for cases where failure is genuinely a programmer error.

• Do not confuse casting with conversion: someInt as Double does not compile; use Double(someInt) to change a value’s representation.

• Prefer protocols and generics to Any: any Shape keeps type safety and lets the compiler check conformance, while Any erases it and is not Sendable.

• Check conformance, not class only: casting to a protocol succeeds for any conforming concrete type, including structs and enums.

• Mind actor isolation: avoid passing Any or non‑Sendable existentials between actors; make the protocol inherit Sendable when values must cross isolation boundaries.

Basic Declaration

A class declaration includes its name and an optional inheritance clause:

class Vehicle {
    // Stored properties
    var wheels: Int
    let manufacturer: String

    // Initializer
    init(wheels: Int, manufacturer: String) {
        self.wheels = wheels
        self.manufacturer = manufacturer
    }

    // Method
    func description() -> String {
        return "\(manufacturer) vehicle with \(wheels) wheels"
    }
}

Use self when referring to the current instance from inside a method or initializer. This is especially useful when an initializer parameter has the same name as a property.

Properties and Initialization

• Stored properties: Hold a value as part of the instance’s state.

• Computed properties: Calculate a value through getter and optional setter blocks.

• Required initialization: Every stored property must have a value before initialization completes.

• Default values: A property with a default value does not need to be assigned by every initializer.

• Memberwise initializers: Classes do not automatically receive the memberwise initializer commonly generated for structures.

• Failable initializers: An initializer declared with init? may return nil when an instance cannot be validly created.

A computed property can transform stored state without storing another copy:

class Vehicle {
    var wheels: Int
    let manufacturer: String

    init(wheels: Int, manufacturer: String) {
        self.wheels = wheels
        self.manufacturer = manufacturer
    }

    var isFourWheeled: Bool {
        wheels == 4
    }
}

Classes Versus Structures

Prefer a struct when independent copies and value semantics are appropriate. Use a class when identity, inheritance, or intentionally shared mutable state is required.

Inheritance and Overriding

A subclass declares its superclass after a colon and overrides eligible methods using override:

class ElectricVehicle: Vehicle {
    let batteryCapacity: Int

    init(wheels: Int, manufacturer: String, batteryCapacity: Int) {
        self.batteryCapacity = batteryCapacity
        super.init(wheels: wheels, manufacturer: manufacturer)
    }

    override func description() -> String {
        return "\(super.description()), battery capacity: \(batteryCapacity) kWh"
    }
}

A subclass initializer must initialize its own stored properties before calling super.init. A method marked override can call super to access the superclass implementation.

Code Example

The following example uses the modern Swift initializer syntax and marks the class final because it is not intended to be subclassed:

final class Vehicle: Sendable {
    let manufacturer: String
    let wheels: Int

    init(manufacturer: String, wheels: Int) {
        precondition(wheels > 0, "A vehicle must have at least one wheel")
        self.manufacturer = manufacturer
        self.wheels = wheels
    }

    func description() -> String {
        return "\(manufacturer) vehicle with \(wheels) wheels"
    }
}

let car = Vehicle(manufacturer: "Example", wheels: 4)
print(car.description())

Vehicle can safely conform to Sendable because it is final and its stored properties are immutable and themselves Sendable.

Best Practices and Common Pitfalls

• Prefer structures for independent value-like data; choose classes when shared identity or inheritance is genuinely needed.

• Mark classes final when subclassing is unnecessary, enabling optimization and clarifying intended usage.

• Use weak or unowned references for parent-child or callback relationships that could otherwise create retain cycles.

• Do not assume classes are concurrency-safe. In Swift 6 language mode, strict concurrency checking detects unsafe sharing of non-Sendable class instances.

• Use an actor when a class-like type must protect mutable state accessed concurrently.

• Keep initializers responsible for establishing valid invariants, using validation or precondition where appropriate.

Core Semantics

• Copying: Assigning or passing a struct produces an independent value, so mutating one copy does not change another. Assigning or passing a class instance shares the same object.

• Copy-on-write: Standard-library types such as Array, Dictionary, Set, and String are structs that avoid unnecessary physical copies until mutation occurs.

• Storage location: Whether a value is stored on the stack or heap is a compiler implementation detail, not a Swift guarantee.

• Shared state: A struct can still contain a class reference, so value semantics do not automatically make every struct thread-safe. Independent value semantics require that the struct does not share mutable references.

Feature Comparison

Equality, Identity, and Mutation

• == versus ===: == compares values for types conforming to Equatable; === compares class-instance identity. Two class instances can be equal by value without being the same object.

• let bindings: A let struct cannot have its stored properties mutated or call a mutating method. A let class only fixes the reference, so its var properties remain mutable.

• Reference properties: Even a let struct can indirectly mutate a class instance reached through one of its reference properties.

Inheritance, Initialization, ARC, and Concurrency

• Both structs and classes can conform to protocols. Extensions can supply default implementations, making protocol composition preferable to deep class hierarchies.

• A struct receives a memberwise initializer unless it declares a custom initializer in its original definition; an initializer added in an extension does not suppress that memberwise initializer.

• ARC retains class instances. Strong parent-child references or closures capturing self can create retain cycles. Use weak when the referent should become nil, or unowned when it must remain alive for the reference’s entire valid lifetime.

• In Swift 6 language mode, complete strict concurrency checking is the default. Sendable matters when values cross actor or other isolation boundaries. Swift infers conformance for non-public structs and enums whose stored values are Sendable; classes never get inferred conformance, and public types should state conformance explicitly.

• A final class can safely conform to Sendable when its stored properties are immutable and Sendable. A non-final class normally requires @unchecked Sendable, where the author must guarantee appropriate synchronization. Actors are implicitly Sendable.

Choosing a Type

• Prefer a struct for models, DTOs, configuration, and independent state. SwiftUI views are typically structs, and state wrappers such as @State and @Binding support value-semantic state flow.

• Use a class for identity, shared mutable reference state, inheritance, Objective-C interoperability, or deinit-based cleanup.

• Use an actor when shared mutable state must be isolated across concurrency domains.

• Prefer composition and protocols over class hierarchies, and mark classes final unless subclassing is intentional.

• On Apple platforms, the @Observable macro requires iOS/iPadOS 17, macOS 14, tvOS 17, watchOS 10, or visionOS 1. ObservableObject and @Published remain valid for older SwiftUI deployment targets, including iOS/iPadOS 13, macOS 10.15, tvOS 13, and watchOS 6.

Core Rules

• Single inheritance: A class can inherit from at most one superclass. Swift does not support multiple class inheritance.

• Class-only: Only classes participate in inheritance. Structures and enumerations use value semantics; protocols describe shared capabilities without adopting a superclass.

• Member reuse: A subclass receives the superclass’s instance and class members and can add stored properties, computed properties, methods, subscripts, and nested types.

• Access to the superclass: A subclass can access inherited members through super, including when implementing overridden behavior.

• Type relationships: A subclass instance can be used wherever its superclass type is expected, supporting polymorphic APIs.

Initialization and Stored Properties

Swift uses a two-phase initialization process to ensure an object is fully initialized before it is used.

• A subclass that defines stored properties must initialize its own properties before calling a superclass initializer.

• If the subclass does not define stored properties, it inherits the superclass’s initializers automatically.

• A subclass that defines any designated initializer does not automatically inherit the superclass’s designated initializers.

• The superclass initializer must be called from the subclass initializer.

• Overridden initializers must call a required superclass initializer where the language rules require it.

• Property observers and the willSet/didSet behavior of inherited properties continue to work as defined by the superclass.

Automatic initializer inheritance does not remove the need to initialize all inherited stored properties correctly.

Overriding and Polymorphism

Overriding changes behavior declared by a superclass while preserving the same contract.

• override is required when replacing an inherited class member.

• An overridden method can call the superclass implementation through super.

• A stored property cannot be replaced with another stored property, although it can be observed by adding willSet/didSet or overridden as a computed property.

• Computed properties and subscripts can be overridden.

• final prevents a class, method, property, or initializer from being overridden.

• A designated initializer can be overridden by a subclass; convenience initializers can also be overridden under the initializer rules.

• A subclass cannot reduce the access level of an inherited member it overrides.

Method calls on class values support polymorphic behavior: when an override exists, the implementation associated with the runtime class is used. The compiler still performs static type checking at the call site.

Composition and Protocol-Oriented Design

Prefer composition when an object needs a capability but is not a specialized form of the superclass.

• Composition: Store another type as a property and delegate work to it.

• Protocol conformance: Define behavior as a requirement list, allowing unrelated types to share the same capability.

• Protocol composition: Combine several protocols when a type needs multiple independent capabilities.

• Existentials and some: Use protocol-constrained types such as some Collection when a concrete type is not important to callers.

For example, a networking service can be injected through a protocol rather than inherited through a generic “base service” class. This reduces coupling and makes testing easier.

ARC and Retain-Cycle Pitfalls

Classes are reference types whose object lifetime is managed by ARC.

• A strong reference keeps an object alive.

• A weak reference does not keep its target alive and is automatically set to nil when the target is deallocated.

• An unowned reference also does not keep its target alive, but it is assumed to remain valid while referenced.

• Closures and parent-child object relationships can create retain cycles.

Use weak or unowned for back-references where appropriate, avoid strong closure captures when a cycle is possible, and document ownership clearly. This is especially important when classes are used across concurrency domains in Swift 6: values crossing concurrency boundaries may need to satisfy Sendable, and mutable shared state should generally be isolated using actors rather than inherited synchronization mechanisms.

Best Practices

• Model inheritance only for strong, stable “is-a” relationships.

• Keep the superclass small and focused; deep hierarchies make behavior difficult to predict.

• Expose protocols at dependency boundaries and inject implementations.

• Use final when a class is not designed for subclassing.

• Initialize inherited state correctly and preserve required initializer contracts.

• Treat ARC ownership and possible retain cycles as part of the class design.

• In Swift 6 language mode, combine inheritance with strict concurrency checking deliberately: use Sendable, immutable value types, and actors where shared mutable state requires isolation.

Access Control Levels

Swift restricts access to declarations using access modifiers:

For classes, open is required when other modules need to subclass the class or override its methods. A public class exposes the class but does not permit external subclassing. The open modifier applies only to classes and class members, not structs or other declarations.

Read and Write Visibility

A property’s getter and setter can have different access levels. This is useful when callers should inspect a value but only the type should modify it. For example, public private(set) var balance: Int gives callers a public getter while restricting its setter to the type. Other common patterns include internal private(set) and public internal(set).

Swift has no protected access level. To expose controlled mutation, provide an appropriate method rather than making the underlying property publicly writable.

Structs and Classes

• Structs are value types: Each instance holds its own state. A method that changes stored properties must be marked mutating.

• Classes are reference types: Multiple references can point to the same instance. A method can normally mutate its properties without the mutating keyword.

• Encapsulation works in both: private state can protect invariants regardless of whether the containing type has value or reference semantics.

• Classes do not receive a synthesized memberwise initializer. Structs may receive one, although an explicit initializer is preferable when validation or a particular public API is required.

Protecting Invariants

Encapsulation is strongest when all state-changing paths pass through controlled methods. For example, a deposit operation can reject nonpositive amounts, while a balance remains publicly readable but not directly assignable.

Access control is a compile-time visibility mechanism rather than a security boundary. It does not prevent runtime memory inspection or deliberately unsafe access.

Best Practices and Common Pitfalls

• Keep mutable state private whenever possible and expose intent-specific operations instead.

• Use public private(set) for observable values that callers should not modify directly.

• Validate arguments inside the type rather than relying only on callers.

• Mark struct methods that mutate state as mutating.

• Use package for APIs shared by modules in one Swift package but not intended for external consumers.

• Remember that public does not make a class externally subclassable; use open when that is intentional.

How Inheritance Works

• A Swift class may declare one superclass using the inheritance syntax, and the superclass provides inherited properties, methods, initializers, and other behavior.

• A class without an explicitly declared superclass is a base class; Swift has no universal root class that all classes implicitly inherit from. AnyObject can refer to an instance of any class type, but it is not a superclass.

• Inherited members can be overridden when the subclass provides a compatible implementation.

• Swift classes are reference types: multiple references can point to the same instance, and the instance is managed by ARC.

• Inheritance represents an “is-a” relationship. For example, a PremiumAccountViewController can be a subclass of AccountViewController because it represents a specialized kind of that type.

Swift does not allow a class to inherit directly from two superclasses. This restriction avoids several problems associated with multiple class inheritance, such as ambiguous method resolution and conflicting stored-property initialization.

Protocol Conformance as the Alternative

A class can conform to multiple protocols in the same declaration. Protocols are central to Swift’s protocol-oriented programming model and can be adopted by classes, structures, enums, and actors.

• Multiple protocol conformance: A single class can implement several unrelated protocol requirements.

• Protocol inheritance: A protocol can inherit from other protocols, allowing it to combine related requirements.

• Protocol composition: Several protocols can be combined into a single requirement that a type must satisfy.

• Class inheritance plus protocols: A subclass can inherit behavior from its superclass while also conforming to multiple additional protocols.

For example, a networking class might inherit from a platform-specific base class while conforming to protocols for caching, authentication, and retry behavior. This is generally preferable to trying to model those responsibilities through multiple class inheritance.

Composition and Delegation

When a type needs behavior from multiple implementations, composition or delegation is often clearer than inheritance.

• Composition: The type stores another object as a property and forwards work to it.

• Delegation: The type communicates with another object through a protocol, without requiring a subclass relationship.

• Protocol abstractions: Dependencies can be represented by protocols, making them easier to substitute in tests and reducing tight coupling.

For example, rather than creating a class hierarchy containing separate base classes for persistence, networking, and caching, one type can hold collaborators conforming to the relevant protocols.

Choosing the Right Design

Use class inheritance when the subclass genuinely represents a specialized form of its superclass and needs its stored state or behavior. Use protocol conformance when the goal is to describe capabilities independently of the implementation.

Avoid using inheritance solely to reuse code. Protocol-oriented design and composition usually provide better flexibility, testability, and separation of concerns, especially when working with value types or unrelated subsystems.

Method Overloading

• Definition: Multiple methods share a base name but differ in parameter types, argument labels, generic requirements, or other signature details.

• Resolution: The compiler chooses the appropriate overload based on the arguments supplied at the call site.

• Scope: Overloading can be used with classes, structures, enumerations, and extensions.

• Return type: The return type alone cannot be used to distinguish overloads. Swift does not permit overloading based on return type; attempting to do so is a compile-time error.

For example, a type could provide a method named process that accepts an Int, a String, or a collection of a particular element type. Each is a separate overload, and callers select it through argument matching.

Overloading is useful when the operations are conceptually related and the caller should not need to remember different method names. It also works well with Swift’s protocol-oriented design, where several conforming implementations can expose similarly named methods with type-specific inputs.

Method Overriding

• Definition: A subclass provides a new implementation for an inherited instance method.

• Requirement: The overriding declaration must use the override keyword. Swift uses this marker to verify that the method actually overrides a superclass method.

• Scope: Overriding applies to classes that inherit from another class. Structures and enumerations do not support class-style inheritance.

• Dynamic dispatch: When a method is called through a superclass-typed reference, the runtime can select the subclass implementation, provided the method is overridable and the reference is not otherwise constrained.

A subclass can call the superclass implementation using super.methodName(...). This is useful when the subclass adds behavior but still needs the original implementation.

Methods declared final cannot be overridden. A class itself declared final cannot be subclassed.

Comparison

Best Practices and Common Pitfalls

• Keep overloads meaningfully different: Avoid many overloads that differ only in subtle type distinctions, especially where callers may find the intended overload unclear.

• Use clear argument labels: Labels such as from, to, and with can make overloaded calls easier to read, although they also participate in overload selection.

• Do not confuse overloading with shadowing: A method in a subclass with the same name but an incompatible signature is not an override and should not be presented as one.

• Respect value-type semantics: Because structures are copied rather than referenced, methods on a structure generally operate on the instance they are called on. Overriding is a class-inheritance feature, not a general substitute for protocol conformance.

• Consider protocols for customization: When behavior varies by type rather than by subclass, a protocol with a method requirement may be more idiomatic than a large class hierarchy.

• Account for concurrency in Swift 6: If a method accesses mutable shared state, use appropriate isolation such as an actor or @MainActor. Swift 6 language mode enables strict concurrency checking, so concurrent code should make isolation and Sendable requirements explicit.

How It Works

A convenience initializer must call another initializer using self.init(...). The delegated initializer is responsible for fully initializing the instance:

class Person {
    let name: String
    let age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }

    convenience init(name: String) {
        self.init(name: name, age: 0)
    }
}

The designated initializer init(name:age:) initializes both stored properties. The convenience initializer init(name:) supplies a default value for age and delegates to it.

Convenience initializers can also be declared in a class extension, which is useful when adding alternative creation APIs without modifying the class’s original implementation:

extension Person {
    convenience init(anonymous: Bool) {
        self.init(name: "Anonymous", age: 0)
    }
}

Convenience vs. Designated Initializers

Structs and enums do not use the designated-versus-convenience distinction. They can define custom initializers, but those are not classified as convenience initializers.

Inheritance Rules

A subclass cannot call a superclass convenience initializer directly. Its initializer delegation must call an appropriate superclass designated initializer.

A subclass inherits convenience initializers only when it satisfies the relevant initializer-inheritance requirements:

• If the subclass defines no designated initializers, it inherits the superclass’s designated and convenience initializers.

• If the subclass provides implementations of all superclass designated initializers, it automatically inherits the superclass’s convenience initializers.

• Otherwise, the subclass does not inherit those convenience initializers.

These rules differ from overridable methods: initializers are not overridden in the same way. A subclass initializer can introduce new parameters, but it must still coordinate correctly with the superclass’s initialization requirements.

Best Practices and Common Pitfalls

• Keep designated initializers authoritative: They should contain the primary initialization logic, while convenience initializers provide sensible defaults or alternate inputs.

• Always delegate correctly: A convenience initializer must call self.init(...); forgetting this call causes a compiler error.

• Avoid duplicated initialization: If several initializers set the same properties, delegating to one designated initializer reduces maintenance problems.

• Use extensions for optional APIs: A convenience initializer in an extension keeps convenience-focused functionality separate from the core class definition.

• Consider failable initialization: If creation can legitimately fail, use init? or init! appropriately and document the failure conditions rather than silently substituting invalid values.

How final Works

When you mark a class as final, the Swift compiler knows no subclass can inherit from it. When you mark a method, property, or subscript as final, subclasses cannot override it. This restriction is enforced at compile time, so any attempt to subclass a final class or override a final member produces a compile error.

• Class-level: Marking a class such as a Database type as final prevents any subclass of that type.

• Member-level: Marking a method such as save() as final prevents overriding it within subclasses.

The compiler uses this information to make static dispatch decisions instead of dynamic dispatch through the virtual method table.

Performance Benefits

Final declarations enable several compiler optimizations that improve runtime performance:

• Devirtualization: The compiler can replace virtual method calls with direct static calls, avoiding the cost of looking up the method in the virtual table.

• Inlining: Final methods are candidates for inlining, where the method body is inserted directly at the call site, eliminating function call overhead.

• Optimization opportunities: The compiler can perform constant folding and other optimizations when it knows a method cannot be overridden.

This matters most in performance-critical code such as game loops, rendering pipelines, or hot paths in networking libraries.

Design and Safety Benefits

Beyond performance, final provides important design guarantees:

• Intent signaling: It tells other developers that a type or behavior is complete and not meant to be extended.

• Framework stability: Library authors can prevent breaking changes caused by subclasses overriding internal behavior.

• Security: Sensitive implementations, such as cryptographic primitives or authentication logic, cannot be tampered with through subclassing.

• Predictable behavior: Applications relying on specific implementations get guaranteed behavior without runtime surprises.

Best Practices

• Use final for performance-critical code where the compiler can benefit from static dispatch.

• Use final in public frameworks to lock down behavior that must not change in downstream code.

• Do not overuse final on internal types where flexibility and testing through subclassing may be valuable.

• Consider alternatives: For UI code in SwiftUI, prefer value types and composition over inheritance, which reduces the need for final in many cases.

• Document the reason: When marking something final, add a comment explaining why subclassing is disallowed.

Common pitfall: marking everything final for the sake of it can reduce code reusability and make testing harder, since you cannot subclass to inject test doubles.

Declaring a Protocol

• Property requirements: var name: String { get } requires read access, while { get set } also requires mutation. Protocol property requirements use var, not let.

• Method requirements: Plain signatures such as func describe() -> String, without a body.

• Initializer requirements: init(value: Int) requires every conformer to provide that initializer.

• Type-level requirements: static func makeDefault() -> Self or static var identifier: String.

• Associated types: associatedtype Element lets a protocol work generically. Since Swift 5.7, a primary associated type can be written as protocol Container<Element>, allowing any Container<Int>.

• Inheritance and composition: protocol Named: AnyObject, Sendable refines other protocols. Inheriting AnyObject restricts conformance to classes and permits class-bound protocol existentials such as any Named to be used with weak.

Conformance and Dispatch

Any struct, enum, class or actor can conform in its declaration or an extension. An extension can also add retroactive conformance when both the type and protocol are owned by other modules; in Swift 6 language mode, mark it with @retroactive to acknowledge the risk of future conflicts.

• Default implementations: Protocol extensions can supply default implementations of protocol requirements. Conditional conformances use constraints, such as the standard library’s Array conformance to Encodable when its Element is Encodable.

• Static dispatch: A member supplied only by a concrete type’s extension, rather than declared as a protocol requirement, is selected from the static type. Declare it in the protocol when conformers must participate in dynamic dispatch.

• any P: An existential hides the concrete type, and calls to protocol requirements use runtime dispatch through the conformer’s witness table.

• some P: An opaque type hides the concrete type from clients while preserving it in the implementation and avoiding existential boxing. Protocol-requirement calls can still use witness-table dispatch, although the compiler may optimize them using the hidden concrete type.

Common Use Cases

• Dependency injection and testability: Define protocol UserRepository, inject a production implementation, and substitute a stub during testing.

• Delegation: A class-bound protocol and weak var delegate: (any Delegate)? prevent the delegate from retaining the delegating object.

• Modelling capabilities: Equatable, Hashable, Comparable, Codable, CaseIterable and Identifiable express capabilities through protocol conformance.

• Generic algorithms: Collection, Sequence and AsyncSequence let one algorithm operate over many concrete types.

• Framework boundaries: SwiftUI’s View and ViewModifier protocols let application code conform to framework contracts rather than subclass framework types.

• Conditional conformance: extension Array: Encodable where Element: Encodable enables encoding only when the elements can also be encoded.

Protocols and Swift 6 Concurrency

• Sendable: This marker protocol indicates that a value can be transferred safely between concurrency domains. A protocol that inherits Sendable requires its conformers to satisfy the compiler’s Sendable checks. Swift 6 language mode enables complete strict-concurrency checking and diagnoses unsafe conformances.

• Async requirements: An actor-isolated method can satisfy an async requirement such as func load() async throws -> Data; callers outside the actor use await.

• Actor conformance: Actors can conform to protocols normally. Under an ordinary, non-isolated conformance, a synchronous requirement needs a nonisolated implementation that does not access isolated mutable state.

Code Example

import Foundation

// The protocol declares the contract; conforming types supply the behaviour.
protocol UserRepository: Sendable {
    var userCount: Int { get }                         // Read-only requirement
    func userName(for id: Int) async throws -> String? // Async, throwing requirement
}

// This value type is Sendable because its stored properties are Sendable.
struct InMemoryUserRepository: UserRepository {
    private let names: [Int: String]

    var userCount: Int { names.count }

    func userName(for id: Int) async throws -> String? {
        names[id]
    }
}

// `some UserRepository` hides the concrete type without existential boxing.
func greeting(
    for id: Int,
    using repository: some UserRepository
) async throws -> String {
    guard let name = try await repository.userName(for: id) else {
        return "Hello, stranger"
    }

    return "Hello, \(name)"
}

Best Practices and Pitfalls

• Keep protocols small and cohesive. Compose capabilities such as Encodable & Decodable instead of creating one large protocol.

• Avoid unnecessary abstractions. A single implementation does not automatically justify a protocol; dependency boundaries, testing and cross-module APIs are common reasons to introduce one.

• Remember the dispatch rule. A method available only through an extension is not part of protocol-requirement dispatch.

• Watch ARC with delegates. Strong references in both directions create a retain cycle. Use weak for the back-reference; class-typed properties can also be weak, while a protocol-typed property must use a class-bound protocol.

• Choose some or generics when avoiding existential boxing matters. Use any when heterogeneous storage is genuinely required.

How Protocol Conformance Works

A protocol defines a set of properties, methods, or other requirements that adopting types must satisfy. A type conforms by listing the protocol after its type declaration:

protocol Describable {
    var description: String { get }
}

The conforming type then implements the required members. Requirements can be implemented in the type declaration, in an extension, or—where the language permits—through a superclass.

Swift uses witness matching to verify conformance. The member’s name, arguments, return type, and access level must satisfy the protocol requirement. Swift can also synthesize implementations for some standard protocols, such as Equatable and Hashable, when all stored properties support them.

Declaring and Extending Conformance

Use the following forms as appropriate:

struct Article {
    let title: String
}

// Conformance declared with the type
extension Article: Describable {
    var description: String {
        "Article: \(title)"
    }
}

An extension can add conformance to a type, but it cannot add stored properties because extensions do not introduce storage to the type. For example, Article cannot gain a new stored views property inside that extension.

A type may adopt multiple protocols, and protocols can inherit other protocols:

protocol IdentifiableByName {
    var name: String { get }
}

protocol UserProfile: IdentifiableByName {
    var displayDescription: String { get }
}

Using a Conforming Type

A conforming type can be used wherever the protocol is expected. Generic code can constrain a type to a protocol:

func printDescription<T: Describable>(of value: T) {
    print(value.description)
}

Swift also has existential types, which let you use a protocol itself as a type:

func printAnyDescription(of value: any Describable) {
    print(value.description)
}

any ProtocolName is the spelling of an existential, and it is required—not just preferred—in the Swift 6 language mode. Any protocol can be used this way today, including protocols with associated types; members that mention an associated type or Self generally have to be reached by opening the existential or through a generic constraint that names the concrete conforming type.

Code Example

The following example declares a protocol, adopts it in an extension, and uses the conforming type through both generic and existential APIs:

protocol Describable {
    var description: String { get }
}

struct Article: Sendable {
    let title: String
    let author: String
}

extension Article: Describable {
    var description: String {
        "\(title), by \(author)"
    }
}

func printDescription<T: Describable>(of value: T) {
    print(value.description)
}

let article = Article(title: "Swift Protocols", author: "Ada")

printDescription(of: article)

let describable: any Describable = article
print(describable.description)

This compiles in Swift 6. Article can safely cross concurrency domains because it explicitly conforms to Sendable, and all of its stored properties are themselves sendable.

Best Practices and Common Pitfalls

• Prefer explicit conformance: Listing the protocol on the type makes its behavior easier to discover, even when the implementation appears in an extension.

• Check requirements carefully: A mismatched method signature, mutability, access level, or optionality causes a compile-time conformance error.

• Use some ProtocolName for opaque return types: This is useful when a function returns one specific conforming type but callers should not depend on that concrete type.

• Use any ProtocolName for heterogeneous values: An existential can hold different conforming types, subject to the protocol’s requirements.

• Consider concurrency: In Swift 6 language mode, strict concurrency checking is enabled. If protocol values cross actor or concurrency-domain boundaries, consider making the protocol inherit Sendable and ensure conforming types satisfy that requirement.

• Avoid accidental retroactive conformance: Adding conformance to a type or protocol from another module can conflict with a future conformance added by that module. The compiler diagnoses this (an error in the Swift 6 language mode) unless you mark a deliberate one with @retroactive, e.g. extension MyType: @retroactive MyProtocol.

What an Extension Can Add

• Computed and static properties: instance and type-level properties with a getter, and a setter for computed ones.

• Methods: instance, static and class methods, including async methods and throws methods.

• Initializers: new initializers, but for classes only convenience initializers — a class’s designated initializers must stay in the main body.

• Subscripts and nested types such as helper enums or error types.

• Protocol conformance: the conformance can be declared in the extension, which keeps the type’s body focused on stored state.

• Generic constraints: an extension can be constrained (extension Array where Element: BinaryInteger), and a generic type can gain conditional conformance (extension Box: Equatable where Value: Equatable).

What an Extension Cannot Add

• Stored properties, and property observers on existing stored properties. Use an associated object or a wrapper type instead — or, preferably, restructure the type.

• Overrides of existing members, and deinit.

• Required or designated initializers for a class.

• A protocol conformance that conflicts with one declared elsewhere: Swift 6 emits a warning for retroactive conformances where both the type and the protocol come from other modules. Mark the conformance @retroactive only when you deliberately mean it, and be aware that two modules doing this can crash at runtime.

Common Uses

• Organising code: splitting a large type into Type+Feature.swift files, one extension per protocol conformance.

• Protocol-oriented programming: a protocol extension provides a default implementation, so conformers inherit shared behaviour and only override what differs.

• Concurrency: adding async methods, or declaring conformance to Sendable for a type you own. A class that protects its own state with a lock can declare extension MyClass: @unchecked Sendable {} — the @unchecked keyword moves the safety responsibility to you, so use it only when synchronisation is genuinely guaranteed.

• Framework types: adding helpers to String, Collection, Date, and so on, instead of writing free functions.

Dispatch Behaviour

A method declared only in an extension of a class cannot be overridden, so it is dispatched statically. The same trap applies to protocol extensions: a method that is not a protocol requirement but only an extension default is dispatched statically, so if a conforming type supplies its own version and you call it through a protocol-typed value, the extension’s implementation runs. Declare the method in the protocol itself when you need dynamic dispatch.

Access Control

private members are visible to extensions of the same type in the same file, which makes same-file extension splitting a convenient way to keep state encapsulated. In a different file, use fileprivate only when truly needed; internal is the default.

Code Example

import Foundation

// 1. Computed property added to a standard library type
extension String {
    var isBlank: Bool {
        trimmingCharacters(in: .whitespacesAndNewlines).isEmpty
    }
}

// 2. Protocol conformance declared outside the type body
struct Temperature: Codable {
    var celsius: Double
}

extension Temperature: CustomStringConvertible {
    var description: String { "\(celsius) °C" }
}

// 3. Protocol extension: shared default implementation
protocol Greeter {
    var name: String { get }
    func greet() -> String   // requirement -> dynamically dispatched
}

extension Greeter {
    func greet() -> String { "Hello, \(name)" }
}

// 4. Conditional conformance on a generic type
struct Box<Value> { let value: Value }

extension Box: Equatable where Value: Equatable {
    static func == (lhs: Box<Value>, rhs: Box<Value>) -> Bool {
        lhs.value == rhs.value
    }
}

// 5. Constrained extension: available only for integer elements
extension Array where Element: BinaryInteger {
    var total: Element { reduce(0, +) }
}

print(" ".isBlank)                              // true
print(Temperature(celsius: 21))                 // 21.0 °C
print(Box(value: 1) == Box(value: 1))           // true
print([1, 2, 3].total)                          // 6

Best Practices and Pitfalls

• Group each protocol conformance in its own extension and name files Type+Protocol.swift; this scales far better than one giant body.

• Do not use extensions to sneak stored state around the language rules; redesign the type instead.

• Avoid “extension sprawl”: helpers added to third-party types in an app are hard to find and can clash with the framework’s future API.

• Reach for @retroactive sparingly and only inside an app target you control, never as a habit in a library.

• Remember that extension members are statically dispatched unless they are protocol requirements or declared in a class body, and that @unchecked Sendable is a promise the compiler cannot verify.

What Protocol Extensions Provide

• Default implementations: A protocol extension can implement an existing protocol requirement. A conforming type may still provide its own implementation, which is selected through the protocol’s witness table.

• Additional members: It can add methods, computed properties, and subscripts that are not protocol requirements. These are extension-only members and use static dispatch.

• Conditional availability: Constraints can limit an extension to suitable conformers, such as extension Greeter where Self: Equatable.

• No stored properties: Like other extensions, a protocol extension cannot add stored properties, property observers, or a deinitializer.

• Existential limitations: Extension-only members are callable on any P only when their declarations are compatible with an existential. Members involving an unavailable associated type or a concrete Self cannot be used that way.

Protocol inheritance is a separate declaration. For example, protocol MyProtocol: Sendable {} requires every conformer to satisfy Sendable; it does not automatically make an otherwise non-Sendable type safe. Swift 6 language mode uses complete strict concurrency checking, so violations of required Sendable boundaries are diagnosed as errors.

Comparison With a Concrete-Type Extension

Dispatch and Shadowing

Calls to a protocol requirement through a protocol-typed value use the witness table and can select a conformer-specific implementation. Calls to a member that exists only in a protocol extension are statically dispatched according to the expression’s static type.

If a concrete type declares a member with the same name and signature as a protocol-extension-only helper, the concrete member is selected when that concrete type is statically known. A caller using any P still receives the extension implementation. This difference can surprise callers, so use a protocol requirement when polymorphic dispatch is required.

Similarly, a method added directly to a class in an extension cannot be overridden by a subclass. When subclass customization is required, declare the method in the protocol and provide an overridable implementation in the class.

Best Practices and Pitfalls

• Declare a requirement when conformers need to provide different implementations or callers need polymorphic behavior.

• Do not rely on a protocol default for security enforcement: any conformer may implement the requirement. Enforce the invariant at a non-overridable call site or policy boundary.

• Prefer conditional Self constraints when a helper requires additional capabilities; this makes the requirement visible in the API.

• Keep extension-only helpers distinct from requirement names to avoid accidental shadowing and confusing dispatch behavior.

• In Swift 6 language mode, adding a conformance between a type and protocol both owned by other modules can produce a retroactive-conformance warning. Mark that specific conformance with @retroactive only after confirming that the conformance is intentional and documenting the ownership conflict.

How Protocol Polymorphism Works

A protocol declares requirements such as properties, methods, initializers, or subscripts. Each conforming type supplies its own implementation:

• A Dog type might implement a makeSound() requirement by barking.

• A Cat type might implement the same requirement by meowing.

• Code written against the protocol can request either behavior without branching on the concrete type.

Protocols therefore provide behavioral polymorphism, unlike class inheritance, which provides subtype polymorphism.

Runtime Dispatch with Existential Types

An existential, written as any ProtocolName, represents one or more values whose concrete types are not exposed at compile time. When a protocol requirement is called through an existential, Swift uses the conforming type’s implementation at runtime.

This is useful when:

• A value may have one of several unrelated concrete types.

• Types are assembled dynamically, such as from a collection of heterogeneous services.

• The caller needs the protocol’s API but does not need the concrete type’s additional capabilities.

Existentials can also be stored in arrays, passed as function arguments, and returned from functions. They may additionally conform to standard protocols such as Equatable or Hashable when their implementations support those requirements.

Static Dispatch with Generics and Opaque Types

A generic constrained by a protocol, such as T: ProtocolName, uses static dispatch. The compiler selects the concrete implementation when the function is specialized, which can enable additional optimization.

An opaque type, written as some ProtocolName, also uses static dispatch while hiding the concrete type from the caller. It differs from any ProtocolName:

• some ProtocolName represents exactly one concrete type known to the compiler.

• any ProtocolName may represent different concrete types, and its requirements are dispatched dynamically.

For performance-sensitive or type-specific code, prefer some or generics. For genuinely heterogeneous collections, use any.

Protocol Composition and Specialization

Multiple protocols can be combined with &, expressing that a type supports several capabilities. A class-bound composition such as ProtocolName & AnyObject allows the value to be treated as a reference type and, where appropriate, to be held weakly.

Protocols can also contain associated types. These are useful when a requirement is parameterized by another type, but they can make existentials less flexible. Swift 6 supports primary associated types, allowing selected associated types to be specified explicitly when an existential is formed.

Protocol extensions can provide default implementations, but they are statically dispatched unless the requirement is invoked through an existential.

Value Types, Reference Types, and ARC

Protocols do not determine whether a conforming type is copied or referenced:

• A struct or enum conforming to a protocol is still a value type.

• A class conforming to a protocol is still a reference type.

Consequently, storing a class instance in an existential or protocol-composition variable does not copy the instance. Reference semantics can introduce shared mutable state and retain cycles. Use weak or unowned carefully when protocol values reference their owners; both qualifiers are valid only for class-bound references.

Concurrency and Best Practices

In the Swift 6 language mode, strict concurrency checking exposes many data-race risks at compile time. When protocol values cross concurrency domains, require Sendable where appropriate, or define explicit isolation and actor requirements. Avoid assuming that a protocol is Sendable merely because it has no stored properties.

Practical guidelines include:

• Define small, focused protocols rather than one large “god” protocol.

• Prefer protocol composition over deep class hierarchies.

• Use any for runtime heterogeneity and some for static specialization.

• Keep protocol requirements meaningful and avoid unnecessary associated-type complexity.

• Remember that protocol extension defaults are selected statically, not overridden dynamically through existentials.

How Protocol Composition Works

Swift combines protocols with the & operator. The main forms are:

• Generic constraint: T: Feedable & Refreshable

• Existential: any Feedable & Refreshable

• Opaque type: some Feedable & Refreshable

• Type alias: typealias Both = Feedable & Refreshable; the standard library’s Codable is itself a type alias for Decodable & Encodable

• Class plus protocols: SomeClass & Feedable & Refreshable, requiring an instance of SomeClass (or a subclass) that also conforms to both protocols

A composed protocol does not introduce a new nominal type. Instead, it expresses that a value must satisfy all of the listed protocol requirements. The protocols remain logically separate: each declares its own properties, methods, and associated types, and extensions on each protocol can supply default implementations.

Composition Versus Inheritance

Protocol inheritance creates an “is-a” relationship. If Playable inherits from MediaItem, every Playable must also satisfy MediaItem. Protocol composition is closer to a “can do both” relationship: Playable and Seekable may apply to unrelated types without either protocol depending on the other.

A type can conform to both composed protocols through separate declarations. It may also provide one implementation that satisfies compatible requirements from both protocols.

Generic Constraints Versus Existentials

Generic composition provides static dispatch and is usually preferable when the implementation needs associated-type requirements or operations tied to Self. The compiler knows the concrete conforming type and can optimize calls accordingly.

A composed existential, such as any Feedable & Refreshable, can store values of different concrete conforming types. Calls through it use dynamic dispatch, and some associated-type and Self-dependent operations may be less convenient than with a generic type.

Modern Swift also supports opaque types with some, allowing a function to return one concrete type that conforms to multiple protocols while hiding that type from callers.

Advantages and Limitations

• Capability-based design: Types can fulfill different roles without inheriting from a broad base protocol.

• Loose coupling: Protocol requirements depend on interfaces rather than concrete implementations.

• Reuse: A composition can be reused across generic constraints, properties, parameters, and return types.

• Clear contracts: Feedable & Refreshable documents two required capabilities in one place.

• Protocol extensions: Default implementations can still be supplied through extensions of the individual protocols when the relevant conformance is visible.

Potential limitations include weaker optimization and fewer available operations when using existentials. Composition also does not automatically provide implementations; each conforming type must satisfy the requirements, and each protocol’s extension supplies any eligible defaults.

Practical Guidance

• Prefer composition when capabilities are independent or may appear in different combinations.

• Use inheritance when protocols form a genuine specialization hierarchy and inherited requirements are meaningful for every subtype.

• Prefer generic composition when static dispatch, associated types, or concrete Self behavior matters.

• Use existential composition when heterogeneous conforming values must share one API boundary.

• Keep composed protocols focused and cohesive; a large composition of unrelated requirements can become difficult to implement and maintain.

• In Swift 6, continue to account for strict concurrency checking when protocols contain mutable state or non-Sendable requirements. A capability intended for concurrent use can be composed with Sendable only when conforming implementations satisfy that requirement safely.

Purpose and Declaration

Associated types are declared with associatedtype:

• associatedtype Element: each conforming type supplies its own concrete Element type.

• The protocol can use the associated type in its requirements, properties, and methods.

• A type may satisfy the requirement through type inference or by declaring an explicit typealias.

For example, IteratorProtocol has an associated type named Element. Sequence declares its own associated types Element and Iterator (constrained to IteratorProtocol, with Iterator.Element == Element); Collection refines Sequence and inherits them.

The selected type does not need to be a class. It can be a value type, such as String or Int, or another appropriate type.

Type Relationships and Constraints

Protocol requirements can constrain the relationship between associated types using same-type requirements. For instance, a protocol might declare two associated types, Key and Value, and require a method func value(forKey key: Key) -> Value. A conforming type can then fix Key to be exactly String by writing typealias Key = String. This expresses more than simply saying that some key type exists: it states the precise relationship the conforming type must support.

Associated types are especially useful for defining protocol-oriented algorithms that remain generic over element types. A method can accept a collection and operate on its Element without knowing whether the collection contains strings, integers, or user-defined values.

Associated Types Versus Generic Parameters

Although associated types and generic parameters both introduce type placeholders, they are selected differently:

An associated type is therefore not the same as a generic parameter on the protocol. Protocols do not directly declare generic parameters in the same way functions and types do; associated types provide the required type-level flexibility.

Inference and Explicit Declarations

Swift can often infer an associated type from a conformance’s implementation. However, explicitly declaring it can improve clarity, for example by writing typealias Element = String. Explicit declarations are particularly useful when:

• The inferred type would be unexpectedly broad.

• Several associated types depend on one another.

• The implementation would otherwise expose implementation-specific inferred types.

• Code must work with Swift’s stricter concurrency and generic-type requirements.

In Swift 6 language mode, strict concurrency checking can affect captured mutable state, but associated types themselves remain valid and widely used. Sendable requirements should be added when a protocol needs values crossing concurrency domains.

Existentials and Opaque Types

A protocol with associated types cannot be used as a plain existential value in all situations because its associated types may be ambiguous. Swift provides alternatives:

• some Protocol: an opaque type whose concrete type is known only within the defining scope.

• any Protocol: an existential value; however, associated types are not directly accessible and must be handled through manual type erasure (e.g., AnySequence) when needed.

For APIs that return one specific conforming type while hiding implementation details, some is often appropriate. For storage that intentionally accepts multiple possible conformers, any may be used when the associated-type constraints permit it.

Best Practices and Common Pitfalls

• Prefer concrete associated-type relationships: Use same-type requirements when the protocol requires one precise relationship.

• Keep protocols focused: Introduce an associated type only when conforming types legitimately need different implementations.

• Do not assume dynamic dispatch from an associated type: Associated types describe static type relationships; they do not by themselves make members dynamically dispatched.

• Avoid unnecessary inference: Declare important associated types explicitly to make API contracts clearer.

• Design for generic usability: Avoid forcing unrelated conformers into one common associated-type implementation unless that relationship is central to the protocol.

What Closures Are Used For

• Callbacks and completion handlers: passing behavior to an API that invokes it later.

• Collection transformations: map, filter, compactMap, and reduce accept closures that perform each operation.

• SwiftUI actions: a Button action is a closure that performs the behavior associated with the button.

• Asynchronous and concurrent work: Task and task-group APIs accept closures that perform work in an asynchronous context.

• Deferred evaluation: @autoclosure delays evaluating an expression until the API needs its value. The right-hand side of ??, for example, is evaluated only when the optional is nil.

• Sorting and comparison: sort(by:) and sorted(by:) use closure predicates to order elements.

Syntax and Conveniences

• Closure expression: the general form is { (parameters) -> ReturnType in statements }. Swift can often infer parameter and return types, and a single-expression closure can omit an explicit return.

• Trailing closure: a closure can be written after the call’s parentheses, such as [1, 2, 3].map { $0 * 2 }. Multiple trailing closures are supported since Swift 5.3.

• Shorthand arguments: $0, $1, and later numbered values refer to closure parameters without declaring them explicitly.

• Shared capture context: copying a closure value copies its reference to the captured context. Mutations of a captured mutable variable through either copy are therefore visible through both.

• Throwing closures: a closure parameter can be declared throws. An API commonly uses rethrows when it throws only because its closure argument throws.

Capturing Values and Memory

A closure captures the values it references from its enclosing scope. Captured object references remain strongly retained while the closure exists.

• Mutable variables: a plain captured var is captured by reference, so later mutations of that variable are visible inside the closure.

• Constants and explicit capture lists: an expression such as [copy = value] captures the value when the closure is formed. This is a shallow capture: for a class instance, the reference is copied but the referenced object is not cloned.

• Retain cycles: if an object stores an escaping closure that strongly captures that same object, ARC keeps both alive through the cycle.

• Weak and unowned captures: [weak self] followed by guard let self else { return } avoids that cycle while allowing temporary strong access. [unowned self] does not retain the object and is appropriate only when its lifetime is guaranteed to exceed the closure’s use.

Escaping, Sendable, and Actor Isolation

• Strict concurrency checking: in the Swift 6 language mode, violations such as sending non-Sendable captured state into a @Sendable context are compile-time errors rather than warnings.

• Mutable local state: a @Sendable closure cannot capture mutable local state for concurrent mutation.

• Task isolation: Task schedules work independently, but an unstructured task created in an actor-isolated context inherits that actor’s isolation by default. Code after an await therefore returns to the original actor unless another isolation was explicitly selected.

• Main-actor work: a closure isolated to MainActor is suitable for UI state updates. When such a closure also crosses an isolation boundary, it should satisfy the applicable Sendable requirements.

Common Pitfalls and Best Practices

• Use [weak self] when an escaping closure stored by a type would otherwise strongly capture that type; use unowned only for guaranteed lifetime relationships.

• Do not assume that await makes non-Sendable state safe to transfer. Access actor-isolated state through the actor, and capture only values that satisfy the applicable sendability rules.

• Prefer async/await for new asynchronous APIs when the platform provides a suitable async alternative; retain completion handlers where existing API compatibility requires them.

• Keep closures focused and move substantial logic into named methods or types.

• Store shared mutable concurrent state in an actor and access it with await rather than sharing mutable captured state unsafely.

Escaping and Non-Escaping Closures

A function’s closure parameters are non-escaping by default. The compiler ensures that such a parameter cannot be used after the function returns, allowing the function to call it during that invocation.

Mark a closure parameter @escaping when the function:

• Stores it in a property, collection, or other longer-lived object.

• Passes it to another parameter or API that retains it.

• Needs it to remain available for later execution.

@escaping only permits a closure to outlive the call. It does not guarantee that the closure will be stored, executed later, or run asynchronously.

Captures and ARC

@escaping does not change how values are captured; strong, weak, and unowned capture semantics remain the same. It changes how long the closure—and therefore its strong captures—may remain alive.

When a closure captures a class instance, Swift’s automatic reference counting normally keeps that instance alive. If an object stores a closure that strongly captures the same object, a retain cycle forms:

• Owner → closure → owner: neither object can be deallocated.

• [weak self]: avoids the cycle by holding a weak reference, but self must be unwrapped before use.

• [unowned self]: avoids the cycle without optional unwrapping, but assumes the referenced object remains alive.

A weak or unowned capture never extends the referenced object’s lifetime. Capturing a mutable local variable normally captures it by reference, so later changes to that variable can be observed by the closure.

Concurrency in Swift 6

@escaping and @Sendable are independent:

• @escaping controls whether a closure may outlive its call.

• @Sendable allows a closure to cross concurrency domains safely with respect to its captured state. Captured values must satisfy the applicable Sendable requirements.

• Actor isolation determines where the closure executes; neither attribute automatically moves execution to the main actor.

The Swift 6 language mode enables complete strict concurrency checking by default, turning many sendability and isolation violations into compile-time errors. Share mutable state through an actor, use immutable Sendable values, or keep the state isolated to the appropriate actor.

A @Sendable closure may also be invoked concurrently, so its implementation must tolerate that possibility. An actor-isolated closure can remain safe without crossing isolation domains.

Code Example

final class Job {
    private typealias Completion = @Sendable () -> Void
    private var completion: Completion?

    // @escaping permits the closure to be stored beyond this call.
    func schedule(_ completion: @escaping @Sendable () -> Void) {
        self.completion = completion
    }

    func finish() {
        completion?()
    }
}

// A closure parameter is non-escaping by default.
func performNow(_ operation: () -> Void) {
    operation()
}

// @escaping permits retention; @MainActor selects the execution context.
func performLater(_ operation: @escaping @Sendable () -> Void) {
    Task { @MainActor in
        operation()
    }
}

performNow {
    print("Running synchronously")
}

performLater {
    print("Running on the main actor")
}

let job = Job()
job.schedule {
    print("Job completed")
}
job.finish()

Best Practices and Common Pitfalls

• Add @escaping only when the closure genuinely must survive the current call.

• Do not infer escaping behavior merely because a function uses async/await; check whether the closure is actually retained.

• Use [weak self] for stored callbacks that capture their owner to prevent retain cycles.

• Treat @Sendable as a separate concurrency requirement, not a replacement for @escaping.

• Isolate mutable state in an actor rather than weakening concurrency checks.

• Clear one-shot callbacks after invocation when releasing their captures promptly is important.

Core Higher-Order Functions on Collections

Swift’s Sequence and Collection protocols provide generic higher-order methods for working with collections:

Use compactMap, not flatMap, when a transformation produces an optional. In Swift 6, flatMap flattens sequences rather than promoting optional results.

How They Work

• Functions and closures are values: A function can be stored, passed as an argument, or returned from another function.

• Protocol-based APIs: Sequence and Collection are protocols, so these methods work generically over different collection types.

• Closure lifetime: Standard methods such as map and filter use nonescaping closures by default. A custom API must mark a closure parameter as @escaping only when it stores or returns that closure.

• Value and reference semantics: Structures and enums, including the User structure in the example, are value types. Classes are reference types whose lifetimes are managed by ARC.

• Concurrency: Swift 6 does not implicitly make a synchronous closure @Sendable merely because its input is Sendable. Strict concurrency checking in the Swift 6 language mode diagnoses unsafe captures across isolation boundaries.

Chaining, Laziness, and Custom Functions

Chaining eager methods such as map and filter creates an intermediate collection for each stage. Applying lazy defers evaluation until iteration. A lazy chain using prefix(5) stops once it has five matching results, although a preceding filter may evaluate additional nonmatching elements.

A function that returns another function is also higher-order. For example, makeMultiplier captures its factor and returns a reusable closure that applies that factor.

Code Example

struct User: Codable, Sendable {
    let id: Int
    let name: String
    let email: String?
    let isActive: Bool
}

let users = [
    User(id: 1, name: "Alice", email: "alice@example.com", isActive: true),
    User(id: 2, name: "Bob", email: nil, isActive: false),
    User(id: 3, name: "Carol", email: "carol@example.com", isActive: true)
]

// Transform, filter, aggregate, and sort the active users' email domains.
let activeDomains = users
    .filter { $0.isActive }
    .compactMap { $0.email }
    .compactMap { email -> String? in
        guard let separator = email.lastIndex(of: "@") else {
            return nil
        }

        let domain = email[email.index(after: separator)...]
        return domain.isEmpty ? nil : String(domain)
    }
    .reduce(into: Set<String>()) { domains, domain in
        _ = domains.insert(domain)
    }
    .sorted()

print(activeDomains) // ["example.com"]

// A higher-order function that returns another function.
func makeMultiplier(_ factor: Int) -> (Int) -> Int {
    { value in value * factor }
}

let double = makeMultiplier(2)
print(double(5)) // 10

// A higher-order function that accepts a function.
func applyTwice<T>(_ transform: (T) -> T, to value: T) -> T {
    transform(transform(value))
}

print(applyTwice({ $0 + 1 }, to: 3)) // 5

Best Practices and Common Pitfalls

• Prefer compactMap: It safely removes nil results instead of using filter followed by force unwrapping.

• Keep transformations pure: Use forEach when the closure performs mutation or I/O rather than hiding side effects inside map or filter.

• Avoid retain cycles: An escaping closure stored by an object can retain that object through a captured strong reference. Capture [weak self] when appropriate, and use unowned only when the referenced value is guaranteed to remain valid.

• Respect concurrency boundaries: Do not assume a closure is Sendable. Pass only sendable captured values across isolation boundaries, or protect mutable state with an actor.

• Measure lazy versus eager performance: Laziness avoids intermediate collection allocations but introduces iterator and closure overhead.

How They Work

• map: Calls a closure for every element and returns the transformed results in the original iteration order.

• filter: Calls a closure for every element and returns the elements for which the closure returns true, preserving their relative order.

• reduce: Processes the elements sequentially, maintaining an accumulated result that is returned after the final element.

For arrays, map and filter return new arrays without mutating the original. reduce returns its accumulated result without changing the source array. Swift may share an array’s storage between copies until one copy is mutated because of copy-on-write optimization.

let prices = [10, 20, 30, 40]

let doubled = prices.map { $0 * 2 }
let expensive = prices.filter { $0 >= 30 }
let total = prices.reduce(0) { $0 + $1 }

The results are:

• doubled: [20, 40, 60, 80]

• expensive: [30, 40]

• total: 100

Common Variations

map and filter also have lazy sequence variants. Lazy evaluation can avoid creating intermediate arrays, but elements are computed only when the sequence is consumed:

let doubledPrices = Array(
    prices.lazy.filter { $0 > 20 }.map { $0 * 2 }
)

Code Example

The following example applies all three operations to shopping-cart items:

struct CartItem {
    let name: String
    let category: String
    let quantity: Int
    let unitPriceCents: Int
}

struct ItemTotal {
    let name: String
    let totalCents: Int
}

let items = [
    CartItem(name: "Keyboard", category: "Accessories",
             quantity: 1, unitPriceCents: 7_500),
    CartItem(name: "Mouse", category: "Accessories",
             quantity: 2, unitPriceCents: 2_500),
    CartItem(name: "Monitor", category: "Displays",
             quantity: 1, unitPriceCents: 25_000)
]

// Transform each selected item into a summary.
let itemTotals: [ItemTotal] = items
    .filter { $0.quantity >= 2 }
    .map { item in
        ItemTotal(
            name: item.name,
            totalCents: item.quantity * item.unitPriceCents
        )
    }

// Combine the summaries into one total.
let cartTotal = itemTotals.reduce(0) { total, item in
    total + item.totalCents
}

// Build a dictionary using a mutable accumulator.
let totalsByCategory = items.reduce(into: [String: Int]()) { totals, item in
    let itemTotal = item.quantity * item.unitPriceCents
    totals[item.category, default: 0] += itemTotal
}

print(itemTotals) // [ItemTotal(name: "Mouse", totalCents: 5000)]
print(cartTotal)  // 5000

// Sort explicitly because dictionary iteration order is unspecified.
for (category, total) in totalsByCategory.sorted(by: { $0.key < $1.key }) {
    print("\(category): \(total)")
}
// Prints:
// Accessories: 12500
// Displays: 25000

Best Practices and Pitfalls

• Prefer an explicit initial value with reduce: It makes the accumulator type and the result for an empty collection clear.

• Avoid reduce without an initial value on a possibly empty collection: Calling it on an empty collection traps because there is no first element to use as the initial accumulator.

• Use reduce(into:) for complex accumulation: It directly models a mutable accumulator without requiring a temporary variable outside the closure.

• Choose compactMap for optional transformations: If a map closure returns T?, map produces [T?]; compactMap unwraps one optional level and omits nil results.

• Chain operations for readability: Place filtering before mapping when filtering should reduce the amount of transformation work.

• Remember that closure order matters: In items.map(transform).filter(selection), mapping occurs first. Reversing the calls changes which values the filter examines.

Sorting and Ordering

Swift’s standard library offers several sorting algorithms that work on any Sequence or Collection type. The sorted() method returns a new array with elements in ascending order, while sort() mutates the collection in place. You can provide a custom comparison using the by: parameter, which accepts a comparison closure.

• sorted(): Returns a new sorted array without modifying the original.

• sort(): Sorts the collection in place, mutating the original.

• sorted(by:): Sorts using a custom closure for non-default ordering.

• min() / max(): Returns the smallest or largest element.

For example, sorting an array of strings by length uses sorted(by: { $0.count < $1.count }).

Searching and Membership

The library includes efficient search operations. The contains(where:) method checks if any element matches a predicate, and firstIndex(where:) returns the index of the first matching element. The standard library has no built-in binary search; for logarithmic-time lookup in sorted collections, use partitioningIndex(where:) from the Swift Algorithms package or write a small binary search.

• contains(_:): Checks for the presence of a specific value.

• contains(where:): Checks for an element matching a predicate.

• firstIndex(where:): Returns the index of the first match, or nil.

• first(where:): Returns the first element that satisfies a predicate, or nil.

Transforming and Reducing

Mapping and reducing are core functional operations. map transforms each element, compactMap filters out nil values while transforming, and reduce combines all elements into a single value. flatMap flattens nested collections.

• map(_:): Transforms each element into a new value.

• compactMap(_:): Maps elements, discarding nil results.

• reduce(::): Accumulates elements into a single result.

• flatMap(_:): Maps and flattens nested sequences.

Practical Best Practices

When working with these algorithms, prefer sorted() over sort() unless in-place mutation is required, since Swift’s value semantics make copying safer. Use compactMap instead of map followed by filter for cleaner code when dealing with optionals. For large sorted datasets, a binary search (such as Swift Algorithms’ partitioningIndex(where:)) is significantly faster than a linear firstIndex(where:).

Common Pitfalls

Avoid mixing map and filter when compactMap is available, as it is more efficient and readable. Be cautious with sort() on large collections since in-place mutation can have unexpected side effects in value-type contexts. Always ensure the collection is sorted before running a binary search, as it requires a sorted input to produce correct results.

Core Characteristics

• Value semantics: Strings are structs with copy-on-write optimization; assignment and parameter passing create independent logical copies.

• Unicode correctness: A String is a collection of extended grapheme clusters (user-perceived characters), not code points or code units. This means "👨‍👩‍👧‍👦".count == 1 even though it comprises multiple Unicode scalars.

• Protocol conformance: String conforms to BidirectionalCollection, RangeReplaceableCollection, ExpressibleByStringLiteral, CustomStringConvertible, Codable, and Sendable.

Common Mutating Operations

• Concatenation: + operator or append(_:) / append(contentsOf:) for in-place mutation.

• Insertion & removal: insert(_:at:), insert(contentsOf:at:), remove(at:), removeSubrange(_:), removeAll(keepingCapacity:).

• Replacement: replaceSubrange(_:with:) replaces a range with another string or collection of characters.

• Case changes: uppercased(), lowercased(), capitalized (locale-aware variants accept a Locale parameter).

• Trimming: trimmingCharacters(in:) removes leading/trailing characters from a CharacterSet (e.g., .whitespacesAndNewlines).

• Splitting & joining: split(separator:maxSplits:omittingEmptySubsequences:) returns [Substring]; joined(separator:) recombines a sequence of strings.

Non-Mutating Queries & Transformations

• Prefix / suffix: hasPrefix(_:), hasSuffix(_:), prefix(_:), suffix(_:), dropFirst(_:), dropLast(_:).

• Containment: contains(_:) for characters or substrings; range(of:options:range:locale:) for advanced search (case-insensitive, diacritic-insensitive, regex via .regularExpression).

• Substring extraction: Subscripting with Range<String.Index> or PartialRangeFrom/Through/UpTo yields a Substring (shared storage, O(1) slice).

• Numeric parsing: Int("42"), Double("3.14") initializers return optionals; wholeMatch(of:) with Regex for structured parsing.

Unicode Views & Interoperability

Converting a Substring to String (String(substring)) copies storage, breaking the shared buffer—do this only when the substring outlives the original string.

Indices & Ranges

• String.Index is an opaque position type; integer offsets are not valid subscripts because grapheme clusters have variable width.

• Use startIndex, endIndex, index(after:), index(before:), index(_:offsetBy:limitedBy:) for navigation.

• Subscripts accept any range expression of String.Index (Range, ClosedRange, and the partial ranges); integer ranges are not accepted.

Regular Expressions (Swift 5.7+)

Swift 5.7 introduced Regex<Output> with compile-time checked captures:

let pattern = #/(\d{4})-(\d{2})-(\d{2})/#
if let match = "2024-06-15".wholeMatch(of: pattern) {
    let (_, year, month, day) = match.output
    print(year, month, day) // "2024" "06" "15"
}

The extended-delimiter #/.../# syntax allows multi-line patterns and unescaped slashes (regex literals do not support interpolation).

Performance Best Practices

• Prefer Substring for temporary slices; convert to String only when storage must be owned.

• Use utf8/utf16 views when algorithmic complexity depends on code-unit counts (e.g., byte offsets for network protocols).

• Reserve capacity with reserveCapacity(_:) when building large strings incrementally.

• Avoid repeated + in loops; use String interpolation or a String builder pattern (var result = ""; result.append(...)).

Code Example

import Foundation

// Building a formatted string efficiently
func makeCSVRow(_ fields: [String]) -> String {
    var row = ""
    row.reserveCapacity(fields.reduce(0) { $0 + $1.count } + fields.count - 1)
    for (i, field) in fields.enumerated() {
        if i > 0 { row.append(",") }
        // Escape quotes per RFC 4180
        let escaped = field.replacingOccurrences(of: "\"", with: "\"\"")
        row.append("\"\(escaped)\"")
    }
    return row
}

// Unicode-aware truncation preserving grapheme clusters
func truncate(_ string: String, to maxLength: Int, suffix: String = "…") -> String {
    guard string.count > maxLength else { return string }
    let end = string.index(string.startIndex, offsetBy: maxLength - suffix.count)
    return String(string[..<end]) + suffix
}

// Regex parsing with captures
let logLine = "[2024-01-15 14:30:00] User login: alice@example.com"
let logRegex = #/\[(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\] ([\w ]+): (\S+)/#
if let match = logLine.wholeMatch(of: logRegex) {
    let (_, timestamp, event, detail) = match.output
    print("Event: \(event) at \(timestamp) — \(detail)")
}

Common Pitfalls

• Integer subscripting: string[5] does not compile; use string[string.index(string.startIndex, offsetBy: 5)].

• Assuming count equals byte length: "🇺🇸".utf8.count == 8 but "🇺🇸".count == 1.

• Retaining Substring long-term: Keeps the entire original string alive; copy to String when storing.

• Locale-insensitive case changes: uppercased() is locale-independent (use Foundation’s uppercased(with:) for locale-specific rules); for case-insensitive comparisons prefer localizedStandardCompare or compare(_:options:range:locale:) with .caseInsensitive.

How It Works

• Core cases: Optional<Wrapped> is an enum whose cases are none and some(Wrapped).

• Syntactic sugar: Wrapped? is shorthand for Optional<Wrapped>, and nil represents .none.

• Unwrapping: A wrapped value is accessed through optional binding (if let or guard let), optional chaining (?.), nil coalescing (??), or forced unwrapping (!), which should be avoided where practical.

• Type safety: A nonoptional String cannot represent absence, while String? can. This distinction is preserved in function signatures, properties, collections, and generic code.

Key Features

• Explicit absence: APIs can distinguish “no value” from valid values such as an empty string or zero.

• Generic composition: Optional works with value types, reference types, and other optionals, although nested optionals such as String?? often indicate overcomplicated modeling.

• Protocol conformances: Optional unconditionally conforms to ExpressibleByNilLiteral, CustomStringConvertible, and CustomDebugStringConvertible. Its Equatable, Hashable, and Comparable conformances require the corresponding conformance from Wrapped; it supports Codable when Wrapped is Encodable or Decodable.

• Transformation APIs: map(_:) and flatMap(_:) transform an optional without manually unwrapping it. compactMap(_:) is instead a Sequence method that transforms elements and discards nil results.

Common Patterns

• Optional binding: if let name = user.name { print(name) } executes only when a name is present.

• Guard and early exit: guard let token = authToken else { throw AuthError.missingToken } handles absence before continuing.

• Nil coalescing: user.name ?? "Guest" supplies a fallback when the optional is nil.

• Optional chaining: user.address?.city?.uppercased() short-circuits when a required link in the chain is absent.

• Implicitly unwrapped optionals: Type! is mainly associated with framework initialization and Objective-C interoperability. It still represents absence and can crash when accessed before a value is initialized.

Interoperability and Concurrency

• Objective-C: Audited nullable object-pointer APIs import as optionals, while audited nonnull APIs import as nonoptional types. Type! is an implicitly unwrapped optional, not the normal representation of every annotated pointer.

• C/C++: Clang imports pointers using types such as UnsafePointer<T>, UnsafeMutablePointer<T>, UnsafeRawPointer, or UnsafeMutableRawPointer. Nullability information affects whether an imported pointer declaration is optional, but optionality alone does not make dereferencing it memory-safe.

• Concurrency: Optional conforms to Sendable when its wrapped type is Sendable. In the Swift 6 language mode, strict concurrency checking enforces isolation requirements when optional values cross actor boundaries.

Best Practices

• Prefer nonoptional types: Make a property or parameter nonoptional unless absence is a valid domain state.

• Handle absence explicitly: Prefer guard let, if let, or optional chaining over forced unwrapping.

• Avoid unnecessary nesting: Use one optional level unless each level has distinct semantics.

• Define nil semantics: Document what nil means, such as “not loaded” or “not applicable.”

• Choose the clearest transformation: Use map(_:) for simple transformations and flatMap(_:) when the transformation itself returns an optional.

Common Pitfalls

• Accidental double wrapping: If value has type U?, Optional(value) has type U??. Keep the original value when one optional level is intended; an existing U?? named value can be flattened to U? with value.flatMap { $0 }.

• Misunderstanding copying: Optional is an enum value type. Copying it copies the enum and its payload; if the payload is a class instance, the reference is copied, not the referenced object.

• Misusing concurrency attributes: @Sendable is not an attribute for making Optional concurrency-safe. Make the wrapped model type Sendable when required.

• Trusting implicitly unwrapped optionals: Accessing Type! while it is still nil causes a runtime crash even though its declaration visually resembles a nonoptional type.

Type Safety and Generics

• Element type is part of the type: [String] can contain only String values, so the compiler rejects incorrect uses at build time. An unparameterized NSArray exposes its elements as Any; Objective-C represents them as id, requiring casts when they are used as concrete types.

• Objective-C lightweight generics are erased: NSArray<NSString *> * documents intent in Objective-C, but the runtime does not enforce that restriction.

• Heterogeneous typing is explicit: [Any] makes the loss of element-specific type information visible instead of implicit.

Value Semantics and Copying

• Array is a struct: assigning or passing it copies the value semantically. The implementation initially shares the same storage and performs a copy only when one side mutates it, which is copy-on-write.

• The array itself is isolated: under normal passing rules, a callee cannot mutate the caller’s array. However, class instances stored as elements remain shared references, so Array does not prevent aliasing bugs involving mutable element objects.

• Mutability is controlled by the binding: let prevents replacing or mutating the array binding, but it does not make reference-type elements deeply immutable.

• NSMutableArray has reference semantics: aliases to the same mutable collection observe its mutations. Nested value-only data in Swift arrays instead follows consistent value semantics.

Concurrency and Sendable

• Conditional Sendable conformance: Array<Element> conforms to Sendable when Element does. Therefore [Int] or [User] can cross actor boundaries safely when User also conforms to Sendable.

• Swift 6 strict checking: complete strict concurrency checking is enabled by default in the Swift 6 language mode, so unsuitable captures and transfers are diagnosed.

• Objective-C collections lack the same element-dependent guarantee: NSArray and NSMutableArray should not be treated as Sendable merely because their collection APIs are immutable or mutable. They need an audited concurrency-safe wrapper when crossing isolation domains.

• Actor storage is naturally supported: an actor can safely isolate a [Message] internally, but returning it to another isolation domain additionally requires Message: Sendable.

Performance Characteristics

• Unboxed value storage: [Int], [CGPoint], and arrays of Swift structs store elements directly in a contiguous buffer. NSArray stores Objective-C object references, so values without an Objective-C representation require explicit boxing or an Objective-C-compatible wrapper.

• Efficient indexing: Swift Array indexing accesses its contiguous storage directly rather than sending an Objective-C message for every element access.

• Storage-sharing slices: ArraySlice is a view over an array’s existing storage. NSArray exposes subarray(with:) instead of an equivalent Swift-style storage-sharing slice view.

• Bridging can have costs: converting between Swift and Foundation collection representations may require representation-dependent work. String and NSString are toll-free bridged, so that particular conversion is not inherently a boxed allocation, although converting the collection may still have a cost.

• Use ContiguousArray when appropriate: the standard library notes that it can bridge more efficiently to Objective-C when elements are class instances or @objc protocol values.

API and Protocol-Oriented Design

• Standard-library algorithms: map, filter, compactMap, reduce, first(where:), and sort are generic over element types.

• Collection protocols: Array participates in protocols such as Sequence, Collection, RandomAccessCollection, MutableCollection, and RangeReplaceableCollection, allowing generic algorithms to be reused.

• Codable support: when Element: Codable, Array can be encoded and decoded directly with JSONEncoder and JSONDecoder. NSArray is not Swift-Codable; JSONSerialization is the normal Foundation JSON path for it.

• Equality and hashing: when its elements support the required protocols, Array compares and hashes by value. NSArray instead provides Foundation’s isEqual(to:), which compares corresponding elements using isEqual.

• Array literals: let names = ["Ada", "Grace"] creates a typed Swift collection without a container class.

Best Practices and Common Pitfalls

• Prefer Array by default and use NSArray or NSMutableArray only where Objective-C interoperability requires them.

• Avoid forced bridging casts such as as!; use as? with a fallback because a failed forced cast traps at runtime.

• Validate indices before subscripting untrusted input. Swift array access traps on an out-of-range index, while Objective-C’s objectAtIndex: raises NSRangeException.

• Do not assume mutations are shared across bridged representations; an Array and its bridged Foundation collection should be treated as separate value/reference representations.

• Keep concurrency safety explicit: an array is safe to transfer only when its element type conforms to Sendable.

How It Works

• A function signals that it may fail by declaring throws in its signature.

• The throw statement raises a specific error value.

• try must be placed before a potentially throwing expression.

• A do block contains the try expression, while one or more catch clauses handle failures.

• Catch clauses are evaluated in order, so place specific cases before a general catch-all clause.

• The final catch without a pattern handles any error and makes the block exhaustive.

If the error should be handled by the caller instead of locally, the caller can also use try in a throwing function and let the error propagate.

Defining and Matching Errors

Custom errors are usually represented by an enum conforming to Error:

enum ValidationError: Error {
    case emptyInput
    case invalidNumber(String)
    case outOfRange(Int)
}

The associated values retain useful context about the failure. Catch clauses can bind those values:

• catch ValidationError.emptyInput

• catch ValidationError.invalidNumber(let text)

• catch ValidationError.outOfRange(let age)

A general catch receives the error through an implicitly declared error variable.

Code Example

import Foundation

enum ValidationError: Error, Sendable {
    case emptyInput
    case invalidNumber(String)
    case outOfRange(Int)
}

func parseAge(from rawValue: String) throws -> Int {
    let value = rawValue.trimmingCharacters(in: .whitespacesAndNewlines)

    guard !value.isEmpty else {
        throw ValidationError.emptyInput
    }

    guard let age = Int(value) else {
        throw ValidationError.invalidNumber(value)
    }

    guard (0...130).contains(age) else {
        throw ValidationError.outOfRange(age)
    }

    return age
}

func processAge(_ rawValue: String) -> String {
    do {
        let age = try parseAge(from: rawValue)
        return "Valid age: \(age)"
    } catch ValidationError.emptyInput {
        return "Enter an age."
    } catch ValidationError.invalidNumber(let text) {
        return "\"\(text)\" is not a valid number."
    } catch ValidationError.outOfRange(let age) {
        return "Age \(age) is outside the accepted range."
    } catch {
        return "Unexpected error: \(error.localizedDescription)"
    }
}

print(processAge(" 42 "))
print(processAge("unknown"))

Here, parseAge(from:) is marked throws because it can fail. The try in processAge(_:) marks the potentially failing call, and each catch clause converts the failure into an appropriate user-facing result.

Cleanup and Resource Management

Use defer when work must happen whether the operation succeeds or throws. A defer statement executes when the current scope (typically the function) exits, including when an error causes an early exit.

func processFile(at url: URL) throws {
    defer {
        print("Finished processing \(url.lastPathComponent)")
    }
    do {
        let data = try Data(contentsOf: url)
        print("Read \(data.count) bytes")
    } catch {
        print("Failed to read the file: \(error)")
        throw error
    }
}

The defer block runs after the do-catch completes, whether by normal return or by throwing an error.

Best Practices and Common Pitfalls

• Handle errors at an appropriate layer: Catch locally when recovery is possible; otherwise propagate the error.

• Preserve context: Rethrowing the original error retains its type and diagnostic information.

• Order catch clauses carefully: A broad typed catch placed earlier can prevent later, more specific clauses from running.

• Do not silently swallow failures: If recovery is inappropriate, log the error or rethrow it rather than returning misleading success.

• Support concurrency safely: Swift 6 enables strict concurrency checking in the Swift 6 language mode. Errors that cross task or actor boundaries should use Sendable error types with Sendable associated values.

• Respect task cancellation: In asynchronous code, detect CancellationError and rethrow it rather than treating cancellation as an ordinary recoverable failure.

How It Works

A custom error type generally follows three steps:

1. Declare an enum that conforms to Error.

2. Define a case for each meaningful failure.

3. Throw a specific case from a function declared with throws, then handle it with try, do, and catch.

For example, a ValidationError can distinguish a missing name from an invalid age. The invalidAge case can carry the rejected age as an Int, allowing callers to inspect the failure instead of parsing a message.

Representing Error Cases

• Simple cases: Use a case without associated values when its name contains all the necessary information, such as missingName.

• Associated values: Use them when callers need diagnostic details, such as an invalid value, HTTP status code, or affected identifier.

• Computed properties: Add properties when related information should be derived from a case, such as whether the failure is recoverable.

• Nested enums: Group failures by subsystem when that keeps the public API clearer.

A switch over the concrete error enum can be checked for exhaustiveness by the compiler. If a new case is added, exhaustive switches that must handle it can produce compiler diagnostics.

Throwing and Handling Errors

A function advertises that it may fail by declaring throws. A caller must use try when invoking that function. A do-catch statement can then match specific error cases and inspect their associated values, while a general catch handles errors from other domains.

Typed catches are useful when different failures require different recovery actions. For example, a missing name might be recoverable by requesting input, whereas an invalid age might require the caller to correct a submitted value.

Providing User-Facing Messages

Error provides the essential error behavior but does not define a presentation message. For errors that need user-facing text, conform to Foundation’s LocalizedError protocol and implement its errorDescription property.

Keeping the message in errorDescription separates machine-readable failure information from presentation text. This allows the same error to be localized or presented differently in different user interfaces without changing its associated diagnostic data.

Best Practices and Common Pitfalls

• Define a separate error enum for each application domain rather than creating one oversized error type.

• Keep cases precise enough that callers can make meaningful decisions.

• Use associated values for structured diagnostic data instead of embedding formatted messages in the error.

• Use throws for failures that callers can reasonably handle; programmer errors that make continuing impossible may instead justify fatalError.

• Do not silently swallow errors. Handle them appropriately or allow them to propagate to a layer responsible for logging or user notification.

• In Swift 6, Error conforms to Sendable. When a custom error can cross concurrency domains, its associated values should therefore also be safe to transfer.

• Use Result<Success, Failure> when an API is modeling an expected success-or-failure outcome rather than an exceptional operation.

How throws Works

A declaration marked throws may execute a throw statement to transfer control to an error handler. Every direct call to that function must be marked with try; if the call is asynchronous, it also requires await.

The try keyword identifies the potentially throwing operation, but it does not by itself handle the error. The surrounding context must catch it, propagate it from another throwing function, or deliberately convert or force it:

A non-throwing function cannot contain throw or call a throwing function without using try.

Error Types

Thrown values must conform to Swift’s Error protocol. Enums containing error cases are idiomatic because they model a finite failure domain and can carry associated information:

• A custom enum can conform to Error.

• An enum with associated values can represent failures such as missing resources, invalid responses, or decoding failures.

• Plain strings and other arbitrary values cannot be thrown directly; they must be represented by a type conforming to Error.

The untyped throws declaration does not specify one concrete error type. It is equivalent to throws(any Error), meaning the function can throw any value conforming to Error.

Typed Throws in Swift 6

Swift 6 introduced typed throws. A declaration such as throws(FileError) promises that the function throws only the specified concrete error type. This gives callers more precise information and supports exhaustive, switch-based handling when the error set is closed.

Typed throws are especially useful for stable public APIs with a deliberately limited set of failures. They are less suitable when a function may need to introduce new error cases over time, because adding cases to a public error enum can affect exhaustive client handling. Untyped throws remains appropriate when the API intentionally exposes a broader error domain.

Async/Await and Concurrency

Error propagation and asynchronous execution are independent capabilities:

• A function can be synchronous and throwing.

• A function can be asynchronous and throwing.

• A function can be synchronous and non-throwing.

• A function can be asynchronous and non-throwing.

A throwing asynchronous function is called using try await. Swift 6 language-mode strict concurrency checking applies to values transferred across actor or task isolation boundaries under Sendable rules. It does not make thrown errors automatically Sendable, and async does not imply that a function can throw.

Best Practices and Common Pitfalls

• Use an Error-conforming enum rather than throwing strings or other unstructured values.

• Use throws when the failure is meaningful and the caller should handle or propagate it; use an optional result when absence is an expected, non-exceptional outcome.

• Handle errors explicitly with do/catch when the caller can recover. Use try? only when losing the error information is intentional.

• Avoid try! in production because it converts a recoverable failure into a runtime trap.

• Use rethrows only for functions that propagate errors from throwing closure parameters; such functions cannot throw unrelated errors.

• Document expected errors in API documentation, especially for public functions.

• Remember that forgetting try at a call site is a compile-time error, not merely a runtime concern.

How ARC Works

• Compiler-managed lifetime: Swift’s compiler performs lifetime analysis and inserts the required retain and release operations. These operations are an implementation detail; redundant pairs may be optimized away.

• Strong ownership: A strong reference keeps its class instance alive. Creating, copying, or reassigning an owning reference establishes the corresponding ownership.

• Release and deallocation: When the last required strong reference is released, ARC calls the instance’s deinit, if one exists, and then deallocates it.

• Deterministic management: ARC uses deterministic reference-counted release rather than a background garbage collector. The compiler may extend a local variable’s lifetime beyond its last use, so deallocation need not coincide exactly with the end of the lexical scope.

Strong, Weak, and Unowned References

A weak property must be declared as an optional mutable property, such as weak var delegate: SomeClass?. An unowned reference is nonoptional and does not retain its target, so the target must be guaranteed to outlive the object containing the reference.

Retain Cycles and Closures

• A retain cycle exists when strong ownership forms a cycle, preventing every object in that cycle from reaching zero strong references.

• A common example is an object storing an escaping closure that strongly captures that same object.

• Capturing self weakly with [weak self] breaks this cycle, but self becomes optional inside the closure and must be checked before use.

• Use [unowned self] only when the referenced instance is provably guaranteed to outlive the closure’s execution.

• Captures of class references are strong by default; other captured values are captured by value.

Actors and Strict Concurrency

• An actor is a reference type whose instance is managed by ARC. Its mutable state is protected by actor isolation rather than by reference counting alone.

• Task { } inherits the current actor’s isolation, while Task.detached { } does not.

• Capturing an actor strongly in a detached task does not inherently create a retain cycle. It keeps the actor alive until the task completes, which may be desirable; use [weak self] only when the task should not extend the actor’s lifetime.

• In the Swift 6 language mode, strict concurrency checking enforces isolation and Sendable requirements for many cross-isolation transfers. Prefer Sendable value types for transferable data and actor isolation for shared mutable state.

Value Types and Reference Types

• Classes and actors are reference types: assignments share the same instance, and ARC manages the instance’s lifetime.

• Closures have reference semantics, and the class instances they capture are retained or released according to their capture semantics.

• Structs, enums, and tuples have value semantics: assignment copies the value rather than sharing mutable storage. If a value type contains a class reference, that nested reference is still managed by ARC.

Best Practices and Common Pitfalls

• Use strong ownership by default, then deliberately choose weak or unowned for relationships that must not create ownership cycles.

• Prefer [weak self] for escaping closures stored by an object that owns self; check the optional value before using it.

• Remember that arrays hold class elements strongly. Model each element’s intended lifetime explicitly rather than assuming collection membership is non-owning.

• Prefer value types when value semantics are sufficient; they simplify ownership and avoid many retain-cycle problems.

• Use deinit logging only as a development diagnostic, since side effects there can affect timing and should not be used in production.

• Prefer safe unowned references over unowned(unsafe) unless a carefully audited low-level design requires the latter.

How Retain Cycles Occur

Classes are reference types managed by Automatic Reference Counting (ARC). A class can store a closure, and that closure can capture the class instance strongly. The class then retains the closure while the closure retains the class, creating a cycle.

Closure capture follows value semantics for value-type values: local structs, enums, and other values are captured by value. However, when a captured value contains a class reference, that reference is normally retained strongly unless the capture is explicitly marked weak or unowned.

Capture-List Strategies

A capture list specifies how a closure captures values from its enclosing scope.

• [weak self]: Creates a non-owning reference that becomes nil after the instance is deallocated. Inside the closure, self is therefore optional. Use this when the closure may execute after the instance could disappear, such as in asynchronous callbacks, timers, notifications, or long-running tasks.

• [unowned self]: Creates a non-owning, nonoptional reference that does not keep the instance alive. Accessing it after the instance has been deallocated causes a runtime trap. Use it only when the closure is guaranteed to run while the instance is still alive and the lifetime relationship is clear.

• [weak delegate] or [weak owner]: Apply weak capture to other class-bound dependencies when those references are not required to keep the closure’s dependencies alive.

• Capture values locally: Assign required value-type data to local constants before creating the closure. This avoids retaining an owning object when only its value data is needed.

A weak capture only breaks the ownership edge it modifies. If the closure strongly captures another object that indirectly retains the closure’s owner, a cycle can still remain.

Redesign the Ownership Relationship

Weak capture is not always the best solution. Sometimes the ownership should be redesigned:

• Keep the closure on the object responsible for invoking it, but capture that object weakly when its lifetime is independent.

• Use a delegate with a weak reference when the delegate relationship follows the standard ownership pattern.

• Store independent state in structs or other value types rather than unnecessary class instances.

• Avoid making one object own both a callback and the object that the callback strongly captures.

• Capture only the dependencies the closure actually needs rather than capturing an entire owner graph.

Using a value type does not automatically eliminate cycles. A struct containing a closure can still participate indirectly if that closure captures a class that ultimately retains the struct or its callback.

Best Practices and Swift 6 Concurrency

• Prefer [weak self] when the closure might outlive the instance, and handle the optional self safely.

• Use [unowned self] only when the lifetime guarantee is explicit and reliable; it is not merely a way to avoid optional handling.

• Do not apply weak blindly: changing a required strong capture into a weak one can also change program semantics by allowing essential state to disappear.

• In Swift 6 language mode, strict concurrency checking diagnoses unsafe cross-isolation access and captures. When an API requires a @Sendable closure, use actor isolation or await appropriately and ensure captured mutable state satisfies the compiler’s Sendable requirements.

• @Sendable is a closure attribute, not a general guarantee that captured mutable state is safe; synchronization or actor isolation is still required where shared mutable state is involved.

Why ARC Needs Weak and Unowned References

• ARC keeps a count: every strong reference to a class instance (the default for stored properties, variables, constants and closure captures) increments its retain count, and the instance is deallocated when the count reaches zero.

• Retain cycles leak: if two instances hold strong references to each other, neither count ever reaches zero, so neither is deallocated. This is the classic parent-child or delegate relationship, and it is also common when an object stores a closure that captures the object itself.

• The fix is a non-owning reference: one side of the relationship must not add a retain. Swift gives you exactly two tools for that, weak and unowned, and both are restricted to reference types such as classes — structs and enums are value types and cannot hold them.

How weak References Work

• Zeroing: a weak reference is registered with the runtime and is set to nil the moment the referenced instance is deallocated, so it never dangles.

• Declaration rules: it must be declared with var and its type must be optional (weak var delegate: MyDelegate?), because the value can become nil. weak let is not possible.

• Type restriction: the referenced type must be a class type, or a class-bound protocol (protocol MyDelegate: AnyObject). Without the AnyObject constraint, an existential protocol type could be satisfied by a struct and weak would not compile.

• Typical uses: delegates and data sources, back-references to a parent, and [weak self] capture lists in escaping closures, Task { } bodies and stored callbacks.

How unowned References Work

• No zeroing: an unowned reference does not keep the instance alive and is not set to nil; it assumes the referenced instance always outlives it.

• Failure mode: touching an unowned reference after the instance has been deallocated traps at runtime (a crash), which is far safer than the legacy unowned(unsafe) form, which is no longer recommended because it leaves a dangling pointer and gives undefined behaviour.

• Declaration: it is written as a non-optional stored property (unowned let customer: Customer), so no unwrapping is needed at the use site.

• Typical uses: a child pointing back at a parent that owns it, or [unowned self] in a closure that is owned by self and released together with it. Use it only when the lifetime guarantee is obvious and documented in the code.

weak vs unowned

Best Practices and Common Pitfalls

• Default to weak: it is safe, self-documenting and cheap enough for almost every case; reach for unowned only when a crash on misuse is acceptable and the lifetime rule is certain.

• Watch escaping closures: [weak self] followed by guard let self else { return } is the standard pattern, but the closure then holds self strongly for its remaining body. Using [unowned self] in a completion handler that can outlive self is a common source of crashes.

• Do not try to break cycles in deinit: by the time deinit runs the objects are already being torn down; the reference must be non-owning from the start.

• Do not use unowned just to avoid optionals, and avoid unowned(unsafe) entirely.

• Swift 6 concurrency: weak and unowned control memory lifetime only — they do not make a type Sendable or bypass actor isolation. Under strict concurrency checking, captured values in a @Sendable closure are still checked for Sendable conformance, and calling an isolated member through a weak or unowned reference still requires await.

• SwiftUI note: SwiftUI views are structs, so they cannot hold weak or unowned properties; use these references in the class-based model or coordinator layer, and prefer @State/@StateObject ownership in the view itself.

How It Works

• Queues, not threads: Work is submitted as a closure or DispatchWorkItem. The system schedules that work on worker threads, so applications do not create a thread for every operation.

• Serial queues: A serial queue executes one task at a time in submission order. The main dispatch queue is a serial queue bound to the main thread. On Apple platforms, UIKit work must run on the main thread, while SwiftUI state updates should be performed from a MainActor context.

• Concurrent queues: A concurrent queue may execute several tasks simultaneously. DispatchQueue.global(qos:) returns shared concurrent queues, and custom concurrent queues can be created with the .concurrent attribute.

• Quality of Service: QoS values such as .userInteractive, .userInitiated, .utility, .background, .default, and .unspecified communicate the workload’s urgency to the scheduler.

• Synchronization primitives: DispatchGroup supports fan-in and completion notification; DispatchSemaphore provides a counting gate; async(flags: .barrier) schedules exclusive work on a concurrent queue; and DispatchSourceTimer provides timer-based events.

GCD and Swift Concurrency in Swift 6

• Different roles: GCD is queue-oriented and particularly useful for legacy integration, C callbacks, dispatch sources, timers, and existing synchronization code. Swift concurrency provides structured asynchronous workflows with async/await, Task, TaskGroup, and actor.

• Strict concurrency checking: In the Swift 6 language mode, GCD closure captures receive Sendable checking. However, GCD does not provide actor-style isolation: the compiler cannot enforce that all mutable state is accessed only through a particular queue.

• Main-actor work: For new Swift concurrency code, prefer Task { @MainActor in ... } or await MainActor.run { ... } over dispatching directly with DispatchQueue.main.async.

• Cancellation: GCD does not automatically cancel dispatched work. DispatchWorkItem.cancel() marks an item as cancelled but does not stop an executing closure, so work must check cancellation and stop cooperatively.

• Blocking hazard: Blocking a cooperative-pool thread with DispatchSemaphore.wait() or synchronous dispatch can cause starvation or deadlock. Prefer Swift concurrency when the operation can be represented with async/await.

Comparison

Common Pitfalls

• Updating UI off the main thread: Return to the main thread or MainActor before performing UIKit work or changing observable SwiftUI state.

• Synchronous reentrancy: Calling sync on the current serial queue can deadlock. Libdispatch detects some main-queue reentrancy cases and terminates the process.

• Using semaphores as an async substitute: A semaphore blocks a thread rather than suspending it. Prefer async/await when possible.

• Assuming a serial queue protects all state: Its guarantees hold only when every access goes through that queue. Mixing direct access with tasks or actors can reintroduce races.

• Creating excessive queues or blocking workers: Reuse a small number of appropriately prioritized queues and avoid blocking worker threads, which can reduce throughput or exhaust the pool.

Dispatch Queues: Serial, Concurrent and the Main Queue

• Serial queue — DispatchQueue(label: "com.example.cache"). Runs one task at a time in FIFO order; a private serial queue is the classic way to protect mutable state without a lock.

• Concurrent queue — created with attributes: .concurrent. Tasks start in FIFO order but several run at once on the system thread pool, so they finish in an unpredictable order.

• Main queue — DispatchQueue.main is serial and bound to the main thread. UIKit and SwiftUI work belongs there.

• Global queues — DispatchQueue.global(qos: .userInitiated) gives shared concurrent queues per quality-of-service class (.userInteractive, .userInitiated, .default, .utility, .background). Use them for fire-and-forget work; use a private queue when you need barriers.

• async vs sync — async returns immediately; sync blocks the calling thread until the block returns, and deadlocks if you are already on that queue. Prefer async.

• Barriers — async(flags: .barrier) on a private concurrent queue waits for in-flight tasks, runs alone, then resumes them: a reader/writer lock.

Dispatch Groups: How They Work

• DispatchGroup() starts a group with an internal counter at zero.

• enter() increments the counter and leave() decrements it. When it reaches zero, every block registered with notify(queue:execute:) is submitted to that queue; notify itself never blocks.

• DispatchQueue.async(group:execute:) associates a single block with the group automatically, so no manual enter()/leave() pair is needed. Use enter()/leave() only when the wait spans several calls, such as a callback-based completion handler.

• Every enter() must be matched by exactly one leave(). Put leave() in a defer so it runs on every path: a missing leave() means notify never fires, and an extra one crashes the process with “Unbalanced call to dispatch_group_leave”.

• wait() and wait(timeout:) block the calling thread — never call them on the main thread.

• A group is independent of queues: tasks submitted to different queues can belong to the same group.

DispatchGroup vs Swift Concurrency

Prefer withTaskGroup, withThrowingTaskGroup or async let in new Swift 6 code. Keep DispatchGroup for wrapping callback-based APIs or existing GCD code, often together with withCheckedThrowingContinuation.

Common Pitfalls

• Deadlock: DispatchQueue.main.sync { } on the main thread, or queue.sync on the serial queue you are already running on.

• Unbalanced groups: always pair enter() with leave() via defer.

• Blocking the UI: group.wait() on the main thread freezes the app; use notify or await instead.

• Ordering assumptions: on a concurrent queue, completion order is not submission order.

• Shared state: guard it with a serial queue, a lock or an actor — never with a plain var.

• Swift 6 strict concurrency: closures passed to async are @Sendable, so capturing or mutating non-Sendable state is a compile-time error. In async contexts prefer @MainActor isolation or await MainActor.run { } over DispatchQueue.main.async.

Linear Control Flow and Direct Results

• No nested callbacks: a sequence of completion handlers becomes a sequence of try await statements that reads from top to bottom.

• Values and errors flow naturally: an async throws function returns its value directly or throws an error, instead of supplying separate success, failure, and Result callbacks.

• Synchronous entry points remain simple: a direct call to an asynchronous function requires an asynchronous context, but a button action or lifecycle callback can start one with Task { ... }.

• Cancellation is structured: cancellation propagates to child tasks and can be observed through Task.checkCancellation(). Cancellation remains cooperative: it does not stop suspended work by itself, and an awaited API throws CancellationError only if it checks for cancellation, so application code must check it and stop work appropriately.

• Existing APIs can still participate: APIs without asynchronous interfaces may still require completion handlers or GCD, although Swift concurrency provides a cleaner abstraction when an async alternative is available.

Structured Task Lifetimes

• async let: starts a fixed set of child operations concurrently and awaits their results together. It is suitable when the number of operations is known in advance.

• Task groups: withTaskGroup and withThrowingTaskGroup manage a dynamic number of child tasks and collect their results.

• Scoped lifetime: a structured scope waits for its child tasks before returning. If the scope exits with an error, its remaining children are cancelled and awaited.

• Better failure handling: child-task errors can propagate through try await or be handled individually, avoiding manually paired DispatchGroup.enter() and leave() calls. Unlike structured tasks, a DispatchGroup does not provide group-wide child-task cancellation.

Actors and Sendable

• actor: protects mutable actor state by serializing access to it. Accessing actor state from outside the actor requires await.

• @MainActor: isolates UI-related state and work on the main actor, making the intended executor explicit rather than relying on manual DispatchQueue.main dispatch.

• Sendable: identifies values that can be safely shared across concurrency domains. A struct or enum can conform when all stored properties are Sendable; the compiler may infer this for suitable non-public value types.

• Reference types require care: a final class can use ordinary Sendable conformance only when its state is immutable and Sendable. A mutable, synchronized class generally needs @unchecked Sendable with a correct concurrency-safety justification.

• Task context is explicit: Task { ... } inherits the current actor context, while Task.detached { ... } does not inherit actor isolation, priority, or task-local values.

What Swift 6 Checks

• Stronger diagnostics: in Swift 6 language mode, passing unsafe non-Sendable state across actor boundaries or otherwise violating isolation rules produces build errors rather than warnings.

• Region-based isolation: permits certain transfers of non-Sendable values when the compiler can prove that the relevant region is isolated and no conflicting access remains.

• nonisolated declarations: explicitly opt selected declarations out of actor isolation when they do not access isolated state.

• Incremental migration: projects can enable complete strict-concurrency checking per target while remaining in the Swift 5 language mode before adopting Swift 6 mode.

• Not a complete proof: compile-time checking catches many potential races, but runtime locking or serialization is still required for mutable state shared outside an actor.

Best Practices and Common Pitfalls

• Avoid blocking the cooperative pool: waiting on a DispatchSemaphore or performing synchronous blocking work inside an async function can cause severe stalls or deadlocks.

• Do not confuse unstructured and structured tasks: Task { ... } has no lexical scope tied to the surrounding function. Its handle can be awaited or cancelled, but errors are not propagated automatically unless its result is observed.

• Keep heavy work off the main actor: an unstructured task inherits @MainActor isolation when created there. Use an appropriate task group or explicitly nonisolated worker for CPU-intensive work.

• Use @unchecked Sendable sparingly: it suppresses a compiler check and is correct only when the type’s synchronization guarantees have been reviewed.

• Keep GCD where it fits: GCD is not deprecated and remains useful for legacy interfaces and certain queue-based designs, but async/await generally provides clearer cancellation, error propagation, and isolation for new code.

Nullability and Optionals

• Unannotated pointers: Objective-C parameters and returns without _Nullable / _Nonnull become implicitly unwrapped optionals (Type!), forcing the caller to handle nil safely.

• Collection elements: Unparameterized NSArray, NSDictionary, NSSet import as [Any], [AnyHashable: Any], Set<AnyHashable>; parameterized ones such as NSArray<NSString *> import as [String].

• Audited frameworks: Apple frameworks are largely audited; third-party code often is not, so expect ! until annotations are added.

Generics and Type Erasure

• Missing annotations: When a header omits lightweight generics, Swift sees only [Any] and code must downcast.

• Lightweight generics: Any Objective-C class can declare them (NSArray<ObjectType>, custom classes), but the type parameters are erased at runtime.

• Swift generics invisible: A Swift struct Container<T> cannot be subclassed or instantiated from Objective-C.

Value Types and Swift-Only Constructs

• Structs, tuples, enums with associated values: Opaque to Objective-C; they cannot appear in @objc signatures.

• Protocols with associatedtype or Self requirements: Cannot be marked @objc; only class-only protocols (@objc protocol) are visible.

• Property wrappers, result builders, macros: No representation in Objective-C.

Memory Management and Retain Cycles

• ARC interoperability: Works automatically, but weak/unowned references to Objective-C objects require the object to support weak references (most NSObject subclasses do).

• Block vs closure capture: Objective-C blocks capture self strongly by default; Swift closures require explicit [weak self] to avoid cycles.

• __unsafe_unretained: Rarely needed; prefer weak in Swift.

Concurrency and Sendable

• @MainActor inference: Objective-C APIs marked NS_SWIFT_UI_ACTOR (such as many UIKit and AppKit classes) import as @MainActor, which can cause isolation errors when called from non-main contexts.

• Sendable conformance: Objective-C classes do not automatically conform to Sendable; mark them @unchecked Sendable only after verifying thread safety.

• Async/await bridging: Objective-C methods with a completion handler import automatically as async alternatives, and @objc methods can be async; use continuation APIs (withCheckedContinuation) for callback APIs that don’t follow the convention.

Selectors, KVO, and Dynamic Dispatch

• #selector: Only works for members exposed to the Objective-C runtime (@objc or dynamic).

• KVO: Requires @objc dynamic properties on NSObject subclasses; Swift-native Observable (Swift 5.9+) is preferred for new code.

• Method swizzling: Still possible but discouraged; use protocol extensions or composition instead.

Platform and Availability

• Minimum deployment: Bridging works on all Apple platforms (iOS 13+, macOS 10.15+, tvOS 13+, watchOS 6+).

• Linux/Windows: Objective-C interop is unavailable; Swift code targeting non-Apple platforms cannot use @objc.

Best Practices and Common Pitfalls

• Annotate nullability in Objective-C headers (NS_ASSUME_NONNULL_BEGIN, _Nullable, _Nonnull) to get clean Swift optionals.

• Wrap callback APIs in async wrappers using withCheckedThrowingContinuation for structured concurrency.

• Avoid @objc on Swift-only types; use protocol witnesses or type erasure (AnyPublisher, AnyView) when crossing the boundary.

• Test strict concurrency (-strict-concurrency=complete) to catch @MainActor and Sendable issues early.

• Prefer Swift-native frameworks (SwiftUI, SwiftData, Foundation URLSession async) over bridging legacy Objective-C code when possible.

Code Example

// Wrapping an Objective-C callback API into async/await
// Objective-C: - (void)fetchDataWithCompletion:(void (^)(NSArray<NSString *> * _Nullable, NSError * _Nullable))completion;

func fetchStrings() async throws -> [String] {
    try await withCheckedThrowingContinuation { continuation in
        legacyObjCClient.fetchData { objects, error in
            if let error = error {
                continuation.resume(throwing: error)
            } else {
                // Safe because the Objective-C side promises NSString elements
                let strings = (objects as? [String]) ?? []
                continuation.resume(returning: strings)
            }
        }
    }
}

// Marking an Objective-C class as Sendable after verifying thread safety
// In the bridging header or module map:
// @interface ThreadSafeCache : NSObject
// @end

// Swift extension:
extension ThreadSafeCache: @unchecked Sendable {}

How Generics Work

A generic function or type declares one or more type parameters using angle brackets:

func largest<T: Comparable>(_ values: [T]) -> T? {
    values.max()
}

The compiler can instantiate this function for types such as Int, String, or Double, as long as each type satisfies the Comparable constraint. Generic code is type-safe and checked at compile time; it does not accept arbitrary values at runtime.

The generic parameter is inferred from the arguments in many cases:

let number = largest([3, 9, 2])       // T is Int
let word = largest(["Swift", "API"]) // T is String

If inference is ambiguous, specify the type explicitly:

let result = largest<Decimal>([1.5, 2.5])

Constraints and Protocol-Oriented Programming

Constraints define the minimum requirements of a generic type:

• Conformance constraint: T: Equatable requires the type to conform to Equatable.

• Protocol composition: T: Collection & Sendable requires both conformances.

• Associated-type constraint: T.Item refers to a type associated with the protocol.

• Base-class constraint: T: SomeClass is available when a class type is required.

Generic constraints work naturally with protocol-oriented programming. A protocol can describe behavior without requiring a concrete implementation:

protocol Describable {
    var description: String { get }
}

The generic code depends only on the protocol requirement, making it easier to test and reuse.

Generic Types and Value Semantics

A generic type stores values of its element type:

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

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

    func peek() -> Element? {
        storage.last
    }
}

Use it with a concrete type:

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

Structs, including generic structs, are value types. Copying one copies its stored values, although reference-type properties inside it still refer to the same referenced objects. Generic classes use ARC in the same way as other classes: stored reference-type properties are normally strongly retained, so avoid ownership cycles between objects.

Type Erasure and Concurrency

Swift provides two related features for working with protocol-based types:

• some Protocol: an opaque type that hides the concrete type while preserving it for type checking.

• any Protocol: an existential type that erases the concrete type.

For example, a function returning some Container can use the concrete container’s associated types internally, while a caller only sees the protocol’s requirements. Existential types may have limitations when a protocol contains associated types.

Generic types do not automatically satisfy concurrency requirements merely because they are declared generically. In Swift 6 language mode, strict concurrency checking makes data-race violations compile-time errors. Use Sendable constraints and conditional conformances when a generic type may cross concurrency domains:

extension Stack: Sendable where Element: Sendable {}

This conformance is valid only when the element type is itself safe to transfer between concurrency domains.

Code Example

The following example combines a generic container, an associated type, and a constrained generic function:

protocol Container {
    associatedtype Item
    var elements: [Item] { get }
}

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

    var elements: [Element] {
        storage
    }

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

func firstElement<C: Container>(_ container: C) -> C.Item? {
    container.elements.first
}

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

if let first = firstElement(stack) {
    print(first)
}

Best Practices

• Prefer generic constraints over concrete types so APIs remain reusable.

• Use associated types when the result depends on a type relationship; use type erasure only when the concrete type is intentionally hidden.

• Add Sendable constraints when values cross actor or task boundaries.

• Remember that generic value types have value semantics, while classes and stored class references participate in ARC.

• Let type inference handle simple cases, but specify generic arguments when inference could become ambiguous.

Why Associated Types Are Useful

An associated type acts as a type placeholder inside a protocol:

• Each conforming type resolves it to one concrete type.

• Generic algorithms can operate on that type without knowing its implementation beforehand.

• The compiler retains complete type information and can catch incorrect arguments or return values.

• It is especially useful in protocol-oriented designs where behavior is shared but the underlying models differ.

For example, a repository protocol can define the type of item it stores, while separate implementations use User or Product as that item.

How They Work

A protocol declares its associated types with associatedtype, e.g., protocol Repository { associatedtype Item; associatedtype Identifier: Hashable; func find(id: Identifier) -> Item? }. A conforming type can explicitly declare the concrete types with typealias Item = User and typealias Identifier = Int. The compiler can often infer these aliases from the implementation, so explicit declarations are optional when the evidence is sufficient. Constraints can also be added directly, e.g., associatedtype Identifier: Hashable & Sendable.

Comparison with Other Type Mechanisms

An associated type therefore differs from a generic parameter: the protocol determines the associated type through its conformance, whereas the caller normally chooses a generic argument.

Best Practices and Common Pitfalls

• Prefer associated types when the protocol’s behavior has a meaningful dependency on a concrete model type.

• Use some Protocol when callers need one concrete implementation but do not need to name its type.

• Avoid any Protocol when code must access a specific associated type, because existential type erasure limits that information.

• Constrain associated types only when necessary: broad requirements such as Hashable or Sendable make protocols more reusable but can prevent valid conformances.

• In the Swift 6 language mode, strict concurrency checking is enforced. An associated type does not automatically imply Sendable; add Sendable constraints when values cross concurrency domains, and use an actor for mutable shared state.

How It Works

Conditional conformance is declared in an extension using a where clause:

extension Array: Summary where Element: Summary

This states that [Element] conforms to Summary only when Element: Summary is satisfied. Swift therefore permits protocol operations on [Product] but rejects them for [String] if String does not conform to Summary.

The condition evaluates generic requirements, not the runtime values stored in the collection. It can constrain generic parameters, associated types, or their relationships.

Why It Matters

Conditional conformance avoids unnecessary wrappers and repetitive conditional logic. A generic library can expose a uniform API while requiring callers to provide compatible element types.

Common examples in the Swift standard library include:

• Array conforms to Equatable when Element is Equatable.

• Array conforms to Hashable when Element is Hashable.

• Array conforms to Encodable when Element is Encodable.

• Array conforms to Decodable when Element is Decodable.

Because the requirement is checked statically, invalid uses produce compile-time errors rather than runtime failures.

Code Example

The following custom protocol is conditionally adopted by Array:

protocol Summary {
    func summary() -> String
}

struct Product: Summary {
    let name: String

    func summary() -> String {
        name
    }
}

extension Array: Summary where Element: Summary {
    func summary() -> String {
        map { $0.summary() }.joined(separator: ", ")
    }
}

let products = [
    Product(name: "Keyboard"),
    Product(name: "Mouse")
]

print(products.summary()) // "Keyboard, Mouse"

// This does not compile because String does not conform to Summary:
// let names = ["Swift", "iOS"]
// print(names.summary())

This implementation also works for an empty array as long as the array’s element type is known:

let emptyProducts: [Product] = []
print(emptyProducts.summary()) // ""

Common Patterns

• Generic collections: A collection adopts a protocol when every supported element can satisfy it.

• Protocol composition: A type conditionally conforms to one protocol while providing a separate implementation for another.

• Custom generic types: A wrapper such as Box<Value> can adopt a protocol only when Value satisfies a particular requirement.

• Multiple conformances: Different extensions can provide different conditional conformances for the same generic type.

Conditional conformance is different from using a runtime type check such as element is Summary. It provides compile-time guarantees and lets the compiler resolve protocol calls directly.

Best Practices and Pitfalls

• Keep constraints precise: Express only the requirements needed by the protocol implementation.

• Do not rely on runtime value inspection: A where clause describes type relationships, not whether particular collection contents satisfy a condition.

• Remember extension limitations: Conditional conformance is normally declared in an extension and cannot add stored properties to the conforming type.

• Avoid redundant conformances: Check whether the standard library already provides the conditional conformance you need.

• Consider Sendable separately: Conditional conformance does not automatically make a type safe to transfer across concurrency domains. In Swift 6 language mode, require Element: Sendable when that is genuinely required and enforce it through strict concurrency checking.

• Use generics when callers need abstraction: If callers store heterogeneous protocol existentials, the existential type itself must provide the required conformance; conditional conformance for Array does not automatically make every possible element valid.

How It Works

• View protocol: A type with a single requirement, var body: some View. You never call body yourself; the framework does.

• Opaque return type: some View means “one specific concrete type, hidden from the caller”. It lets body return a deeply nested composite type without you naming it.

• Result builder: The closure contents of body are transformed by @ViewBuilder, so you just list views one after another (since Swift 5.9 parameter packs there is no fixed limit; older SDKs capped a group at 10).

• Value types: Views are lightweight structs, not reference types like UIView. They are disposable descriptions, so SwiftUI can diff and recreate them cheaply.

• App entry point: An @main struct conforming to App declares the scenes, typically a WindowGroup that hosts your root view.

• Modifiers: Methods like .padding() or .font(.title) return a new view wrapping the previous one, so order matters.

State and Data Flow

• @State: Local, view-owned mutable storage. SwiftUI re-renders the view when it changes.

• @Binding: A read/write reference to state owned elsewhere; created from a @State with the $ prefix.

• @Observable (Observation framework, iOS 17+): Marks a reference-type model. Views track exactly the properties they read, which is more precise than the older ObservableObject / @Published pattern. Use @State to own an @Observable instance and @Bindable when you need bindings into it.

• @Environment: Reads values injected by ancestors, such as color scheme or dynamic type size.

Composition and Navigation

• Stacks and containers: VStack, HStack, ZStack, List, ScrollView, and LazyVGrid arrange children.

• Navigation: Use NavigationStack with .navigationDestination (iOS 16+). NavigationView is deprecated and should be replaced by NavigationStack or NavigationSplitView.

• Extract and reuse: Pull complex subtrees into their own View structs rather than long body expressions; this keeps the type checker fast and makes views testable.

• Previews: The #Preview macro (Xcode 15+, iOS 17+) replaces PreviewProvider.

Concurrency in Swift 6

• body is @MainActor-isolated, so UI code runs on the main actor by default.

• With strict concurrency checking in the Swift 6 language mode, anything crossing actors must be Sendable. View structs are value types and can be Sendable; observable model classes should be @MainActor or otherwise isolated.

• The .task modifier starts an async task tied to the view’s lifetime and cancels it when the view disappears, which is the recommended way to load data.

Code Example

import SwiftUI

// @Observable tracks which properties each view reads (iOS 17+).
// @MainActor keeps all mutation on the main actor under Swift 6 checking.
@MainActor
@Observable
final class CounterModel {
    var count = 0
    func increment() { count += 1 }
}

struct ContentView: View {
    // @State owns the model for this view's lifetime.
    @State private var model = CounterModel()
    @State private var name = ""

    var body: some View {                       // composed by @ViewBuilder
        NavigationStack {
            VStack(spacing: 16) {
                Text("Count: \(model.count)")   // re-renders when count changes
                    .font(.title)
                Button("Increment") { model.increment() }
                // $name produces a Binding<String> for two-way editing.
                TextField("Your name", text: $name)
                    .textFieldStyle(.roundedBorder)
            }
            .padding()
            .navigationTitle("SwiftUI")
        }
    }
}

@main
struct CounterApp: App {
    var body: some Scene {
        WindowGroup { ContentView() }           // root view of the scene
    }
}

#Preview { ContentView() }                      // Xcode 15+ preview macro

Best Practices and Pitfalls

• Keep body cheap: No networking, file I/O or heavy computation there; it can run many times per second.

• Prefer @Observable over ObservableObject/@Published for new code; the older pair still works but is the previous generation of the pattern.

• Avoid AnyView: It erases type information and hurts diffing performance; use @ViewBuilder or generics instead.

• Mutate state from the main actor: Off-main mutation causes runtime warnings and inconsistent UI.

• Watch for retain cycles: Use [weak self] in escaping closures held by long-lived objects, and align with ARC rules.

• Mind List identity: Provide stable id values so SwiftUI animates and recycles rows correctly.

How It Works

The protocol requires a body(content:) method that receives the original content and returns a modified view:

• Content: The type of content being wrapped.

• body(content:): Produces the transformed view.

• Body: An associated type that must conform to View. Implementations commonly declare an opaque result with some View, but the protocol itself requires the associated type.

SwiftUI evaluates the result as a new view description rather than mutating the original view in place. Most SwiftUI views are value types, so a modifier returns a new value representing the original content with the requested transformation.

Modifier order matters because each modifier receives the output of the previous one. For example, placing padding before a background makes the background include the padded area, while placing it afterward adds space outside the background.

Built-in and Custom Modifiers

A custom ViewModifier does not replace built-in modifiers. It usually composes several existing modifiers behind an application-specific name.

When to Use One

Custom modifiers are appropriate when:

• The same styling or behavior appears in multiple views.

• Several modifiers must always be used together.

• A view’s intent should be clearer than a long modifier chain.

• A reusable abstraction benefits from configurable inputs.

For example, instead of repeating padding, a background, and corner clipping throughout an app, a team could expose a .cardStyle() modifier that applies those transformations together.

Use an environment value when values need to flow down through a view hierarchy, and use preferences when child views need to communicate values to ancestors. A modifier is primarily a view transformation, not a general state-management or dependency-injection system.

Best Practices and Common Pitfalls

• Keep modifiers focused: Avoid creating one modifier that changes unrelated properties.

• Expose meaningful configuration: Accept values such as spacing, radius, or enabled state rather than hard-coding every detail.

• Preserve accessibility: Ensure a modifier does not unintentionally hide or replace accessibility traits, labels, or values.

• Watch modifier order: Place modifiers according to their intended effect, especially around padding, backgrounds, clipping, and shadows.

• Avoid hidden state: A modifier should usually wrap content rather than own unrelated mutable state. Store UI state in the view with @State or another appropriate property wrapper.

• Follow Swift 6 concurrency rules: Keep custom modifier configuration immutable and preferably value-based. Avoid capturing non-Sendable mutable references where strict concurrency checking can identify unsafe transfers between concurrency domains.

Handling Taps with Button

A Button provides a label and an action that runs when the user taps it:

Button("Add Tap") {
    // Runs in response to the tap.
}

The label can be text, an icon, or a custom view. Using Label gives the control both a visible title and a system image while preserving accessibility semantics.

State and Interface Updates

The @State property wrapper stores view-owned state:

@State private var tapCount = 0

When the button action changes tapCount, SwiftUI invalidates the view and recomputes its body as needed. The displayed interface then reflects the new value.

@State is appropriate when the state belongs to the view and does not need to survive the view’s destruction. For data owned by an observable reference model, use @Observable with @State, or @StateObject with an ObservableObject, depending on the model’s ownership.

Asynchronous Work After a Tap

A tap action may start asynchronous work. In Swift 6 language mode, strict concurrency checking is enabled by default, so asynchronous operations should respect isolation and Sendable requirements.

Button("Load Profile") {
    Task {
        // Await a Sendable service API.
        // Update SwiftUI state on the main actor.
    }
}

Because the button action runs in the main-actor context, the Task inherits that actor unless it explicitly leaves it. If the work is long-running or cancellable, store and cancel the task when appropriate. Avoid performing blocking I/O directly inside the action closure.

Button or Gesture?

• Button: Use for standard controls such as submitting, adding, deleting, opening, or confirming. It automatically provides keyboard support, focus behavior, and accessibility traits.

• DragGesture or TapGesture: Use for specialized surfaces such as a canvas, map annotation, game board, or custom drawing area.

• .onTapGesture: Useful for a custom view that should react to a tap, but it does not automatically provide all of the semantics of a Button. Prefer Button when the interaction represents an action.

Code Example

import SwiftUI

struct TapCounterView: View {
    @State private var tapCount = 0

    var body: some View {
        VStack(spacing: 16) {
            Text("Tap count")
                .font(.headline)

            Text("\(tapCount)")
                .font(.largeTitle)
                .monospacedDigit()

            Button {
                tapCount += 1
            } label: {
                Label("Add Tap", systemImage: "plus")
            }
            .buttonStyle(.borderedProminent)
        }
        .padding()
    }
}

#Preview {
    TapCounterView()
}

Best Practices and Common Pitfalls

• Keep the button action focused on user intent and move substantial work into suitable methods or services.

• Use @State for small pieces of local UI state rather than synchronizing several independent stored properties manually.

• Preserve accessibility by preferring Button over gesture-only handling. The system automatically exposes the control as an accessible button.

• Avoid placing network requests, file reads, or other blocking operations directly in the action closure; use async/await.

• Remember that views are value types. A view does not automatically own a separate mutable copy of an external reference-type model merely because it reads from it.

Core Principles

• Single source of truth: Store each piece of state in one clearly identified place rather than duplicating it across views.

• Reactive updates: When SwiftUI observes a change to state used by a view’s body, it reevaluates that body and refreshes the affected interface.

• Value semantics for local state: @State commonly holds a value type. Mutations create a new value that SwiftUI uses to update the view.

• Explicit ownership: The view that creates state owns it. Child views receive values, bindings, or models rather than independently managing competing copies.

• Identity matters: SwiftUI preserves state according to the view’s identity. Changing a view’s identity, for example with .id(_:), can discard its existing state.

Choosing the Right Mechanism

@State is appropriate for temporary interface values such as a selected tab, text-entry field, or toggle. @Binding is appropriate when a child must edit state owned by its parent, but the child should not become another independent source of truth.

For shared or structured data, the current SwiftUI approach uses the Observation framework. An @Observable class tracks property reads and notifies SwiftUI when observed properties change. This replaces the older ObservableObject and @Published model for new Observation-based code, although those APIs remain available for compatibility.

Modern Observation Pattern

In this example, the model is isolated to the main actor because it drives user-interface state. The view retains it with @State, while child views can receive the model directly.

import Observation
import SwiftUI

@MainActor
@Observable
final class CounterModel {
    var count = 0

    func increment() {
        count += 1
    }
}

@MainActor
struct CounterView: View {
    @State private var model = CounterModel()

    var body: some View {
        VStack(spacing: 16) {
            Text("Count: \(model.count)")
                .font(.title)

            Button("Increment") {
                model.increment()
            }
        }
        .padding()
    }
}

If a child view needs a two-way binding to a property of an @Observable model, use @Bindable. It creates bindings without making the child the owner of the underlying value:

@MainActor
struct CountEditor: View {
    let model: CounterModel

    var body: some View {
        @Bindable var model = model

        Stepper(
            "Count: \(model.count)",
            value: $model.count
        )
    }
}

Common Pitfalls and Best Practices

• Do not duplicate state: If a child displays and edits the same value, pass the owner’s state through a binding or pass an observable model.

• Do not confuse ownership with access: @Binding grants access; it does not transfer ownership or create a persistent copy of the source of truth.

• Keep mutable UI state on the main actor: Marking observable view models with @MainActor makes their isolation explicit and supports Swift 6 strict concurrency checking.

• Avoid unnecessary global state: Prefer environment injection for dependencies, while reserving app-wide singletons for genuinely shared services.

• Do not treat @State as persistence: It survives view updates but not application termination. Use appropriate storage such as UserDefaults, files, or a database for durable data.

• Avoid excessive invalidation: Large observable models can cause broad updates. Structure models around coherent features and avoid storing values that the view does not need.

Choosing a Navigation Container

Value-Based Navigation

1. Create the stack with an optional path binding: NavigationStack(path: $path).

2. Mark your destination model as Hashable — a Product struct, or an enum Route of cases for heterogeneous screens.

3. Attach .navigationDestination(for:) inside the stack’s content, and switch on the value to build the right view.

4. Push with NavigationLink(value:). SwiftUI resolves the destination from the registered modifier, so no closure captures a view.

NavigationLink(destination:label:) still exists and is not deprecated, but it is the older eager-destination form: it cannot be driven by a path, so Apple recommends NavigationLink(value:label:) inside a NavigationStack or NavigationSplitView for new code.

Programmatic Navigation

Store the path as state: NavigationPath (type-erased, Codable, mixes types) or a typed array such as [Route] when you want to inspect it.

• path.append(route) pushes; use it for deep links, onboarding flows, or “continue” buttons.

• path.removeLast() pops one level; path = NavigationPath() resets to the root (useful after login or logout).

• @Environment(\.dismiss) pops the current pushed view or dismisses a sheet, so a child never needs to know the path type.

navigationDestination(for:) must be placed inside the stack’s hierarchy — putting it outside, or behind a lazily loaded container that has not appeared, silently fails to resolve.

Swift 6 Concurrency Notes

Views are @MainActor-isolated, so path state and route values are read on the main actor, and strict concurrency checking in the Swift 6 language mode turns violations of that isolation into compile-time errors rather than warnings. Route values should be Sendable if they cross actor boundaries (for example, when a repository actor returns them), and mutations of the path must happen on the main actor.

Code Example

import SwiftUI

struct Product: Hashable, Identifiable {
    let id: UUID
    let name: String
}

enum Route: Hashable {          // destination values must be Hashable
    case settings
}

struct ProductListView: View {
    @State private var path = NavigationPath()   // main-actor isolated stack state
    @State private var showingFilters = false
    let products: [Product]

    var body: some View {
        NavigationStack(path: $path) {
            List(products) { product in
                NavigationLink(value: product) { Text(product.name) }
            }
            .navigationTitle("Products")
            .toolbar {
                Button("Filters") { showingFilters = true }          // modal
                Button("Settings") { path.append(Route.settings) }   // programmatic push
            }
            .navigationDestination(for: Product.self) { ProductDetailView(product: $0) }
            .navigationDestination(for: Route.self) { route in
                switch route {
                case .settings: SettingsView()
                }
            }
            .sheet(isPresented: $showingFilters) { FiltersView() }
        }
    }
}

struct ProductDetailView: View {
    let product: Product
    @Environment(\.dismiss) private var dismiss   // pops the pushed view

    var body: some View {
        Text(product.name)
            .toolbar { Button("Back") { dismiss() } }
    }
}

struct SettingsView: View { var body: some View { Text("Settings") } }

struct FiltersView: View {
    @Environment(\.dismiss) private var dismiss
    var body: some View { Button("Done") { dismiss() } }
}

Best Practices and Pitfalls

• Keep destinations as plain data; never pass a View value into a path (it is neither Hashable nor Codable).

• Prefer NavigationPath when paths mix types or must be saved; NavigationPath is Codable, so encode it for state restoration.

• Use one stack per tab, and do not nest a NavigationStack inside another.

• Prefer .sheet for anything the user must complete or cancel; use a push when the new screen is part of a hierarchy.

• Avoid NavigationLink inside a List row that also has a tap gesture — the link wins and the gesture may never fire.

How @ObservedObject Works

• @ObservedObject is a property wrapper applied to a view’s stored property.

• The wrapped value must be a class conforming to ObservableObject.

• SwiftUI subscribes to the model’s objectWillChange publisher and re-evaluates the view when a @Published property changes.

• The view observes the model but does not create or own it. The parent view, initializer, or another dependency provider supplies the instance.

• This makes @ObservedObject suitable for models created by a parent and passed directly to one or more child views.

A model can expose observable state through the @Published property wrapper. Changes to ordinary stored properties do not automatically invalidate views, so important mutable state should be published.

How @EnvironmentObject Works

• @EnvironmentObject reads an observable model from the SwiftUI environment.

• An ancestor injects the model with the environmentObject modifier.

• Descendant views can then access it without receiving it through every initializer.

• The retrieved model is also observed, so published changes cause affected views to refresh.

• If no matching object is present when the property is read, SwiftUI reports a runtime environment error (a precondition failure). There is no way to supply a default value.

This approach is particularly useful for application-wide or feature-wide models, such as authentication state, settings, shopping carts, or shared session data.

Key Differences

The same model should normally use one access pattern rather than being exposed concurrently through both wrappers.

Relationship to Other Property Wrappers

• @StateObject creates and owns an ObservableObject, preserving it across view redraws. It is usually the preferred choice when a view is responsible for the model’s lifetime.

• @ObservedObject is appropriate when the model already exists and must be supplied by a parent.

• @EnvironmentObject combines environment-based dependency delivery with observation.

• @Environment retrieves ordinary environment values. Unlike @EnvironmentObject, it is not itself an observable-object mechanism.

Because observable models are commonly reference types, ARC manages their lifetime. SwiftUI retains the model while the relevant view hierarchy references it. Closures capturing the model strongly can still introduce retain cycles, so use weak references when a closure owns another object that owns the closure.

Best Practices and Common Pitfalls

• Use @StateObject for view-owned models, @ObservedObject for explicitly injected models, and @EnvironmentObject for shared hierarchical state.

• Keep published state limited to values whose changes should update the UI.

• Avoid placing every dependency in the environment; direct dependencies can be clearer through initializer injection.

• Use optional @Environment values when the object may legitimately be absent, rather than relying on @EnvironmentObject which will crash if missing.

• In Swift 6 language mode, strict concurrency checking is enabled. Keep mutable UI-facing observable models isolated to the main actor when appropriate, and coordinate background work explicitly rather than allowing unrelated tasks to mutate view state concurrently.

Popular Options

Vapor

Vapor is generally the first framework to consider when a project needs batteries-included server-side development. It provides:

• Routing and request handling

• Middleware and dependency injection

• JSON serialization through Codable

• Database integrations and package-based extensions

• Authentication, caching, logging, and testing utilities

• Swift concurrency support through async and await

Vapor packages are distributed through Swift Package Manager. It is especially popular for REST APIs and services that need to run on Linux as well as Apple platforms.

Kitura

Kitura is an established alternative that separates HTTP handling from core application logic. It supports routing, middleware, request and response processing, authentication, and server deployment.

Kitura is useful when working in an IBM-oriented environment or when maintaining an existing Kitura service. For a new project, teams should compare its current maintenance status and package ecosystem with Vapor before making a final choice.

SwiftNIO

SwiftNIO is not primarily an end-to-end application framework; it is a scalable, event-driven networking framework. It supplies channels, event loops, byte buffers, and asynchronous I/O.

Application frameworks such as Vapor are commonly built on SwiftNIO. Choose it directly when the project requires a custom network protocol, unusually specific concurrency behavior, or control over the server’s networking layer.

Choosing a Framework

• Vapor: Best default for most new HTTP services and APIs.

• Kitura: Reasonable for existing Kitura systems or environments already standardized around it.

• SwiftNIO: Best for networking libraries, custom server protocols, and infrastructure-level components.

• Consider deployment constraints, required database drivers, observability tooling, team experience, and the health of each package ecosystem.

Swift 6 and Concurrency

In Swift 6 language mode, strict concurrency checking is enabled by default. Server applications should use async/await, isolate mutable state appropriately, and ensure values crossing concurrency boundaries conform to Sendable.

Framework-owned mutable state should normally remain inside its actor or event-loop context. Avoid sharing unsynchronized reference types between request handlers, and define explicit shutdown behavior so tasks, connections, and event loops terminate cleanly.

Common Pitfalls

• Treating SwiftNIO as a ready-made web framework when only low-level networking primitives are needed.

• Assuming framework packages are compatible with Swift 6 without checking each package’s manifest and release notes.

• Blocking an event-loop thread with synchronous database or file-system calls.

• Storing credentials in source code; secrets should come from environment variables or a managed secret store.

• Ignoring Linux deployment differences when a service is primarily developed on macOS.

Why SwiftPM Suits Server-Side Swift

• One manifest, two platforms: Package.swift replaces the Xcode project, which is Apple-only. SwiftPM runs from the command line on macOS, Linux and Windows; mainstream server deployment is Linux.

• Git-based, versioned dependencies: .package(url:from:) expresses semantic-version ranges, and the resolved graph is written to Package.resolved so CI and production get byte-identical dependency versions.

• Self-contained toolchain: SwiftPM is both the dependency manager and the build system, so swift build, swift run and swift test work in CI and containers without extra build scripts.

• Ecosystem alignment: the server stack (SwiftNIO, Vapor, Hummingbird) is published as SwiftPM packages, so a server is a normal package rather than a special project type.

Manifest, Targets and Dependencies

• Package.swift is Swift source evaluated at build time, so target lists can be computed conditionally.

• Target types: .executableTarget for the server entry point, .target for libraries such as routes, models and persistence, .testTarget for tests, plus plugin targets and products that expose libraries to other packages.

• Entry point: an executable target can declare an @main type with static func main() async throws instead of a top-level main.swift file, which fits async server bootstrapping.

• Splitting logic into library targets keeps business logic testable without starting the HTTP server.

Concurrency and the Swift 6 Language Mode

• The manifest’s swift-tools-version sets the default language mode: with tools version 6.0, targets compile in Swift 6 mode with strict concurrency checking, turning data races in server code (for example shared mutable state touched from several event loops) into compile-time errors.

• Types crossing isolation domains must be Sendable; mutable shared state belongs in an actor or behind a lock. A target can be kept in Swift 5 mode while migrating incrementally.

• Recent releases of the server frameworks are annotated for Swift 6 concurrency, so their APIs are usable from async code without warnings.

Tooling, Tests and Plugins

• Swift Testing is bundled with the Swift 6 toolchain (import Testing, @Test), so modern tests run alongside XCTest inside swift test.

• Plugins: build tool plugins generate code at build time; command plugins add subcommands invoked as swift package <command>.

• Resources are accessed through Bundle.module; on a server, avoid reading bundled files per request.

Deployment and Best Practices

• Build in the same Linux image you deploy on (official swift:6.0 Docker images); Swift on Linux links its runtime dynamically by default, so a binary built on one distribution may not start on another. swift build -c release --static-swift-stdlib links the Swift runtime statically for a more portable binary.

• Commit Package.resolved for applications (not for libraries), and avoid branch: or revision: dependencies in production.

• Use from: ranges rather than exact pins so security patches can be adopted with swift package update, and prefer multi-stage Docker builds that copy only the release binary into a slim runtime image.

Ecosystem and Library Maturity

Swift’s package ecosystem is growing, and Swift Package Manager provides a consistent dependency and build system. However, backend developers may encounter fewer choices for databases, authentication, payments, messaging, cloud services, and observability than in larger ecosystems.

• Quality varies: A small package may have limited releases, tests, documentation, security maintenance, or production adoption.

• Versioning requires care: Applications should pin dependency versions and regularly test upgrades because transitive dependencies can affect server builds.

• Framework lock-in can limit options: Popular server frameworks such as Vapor and Hummingbird can accelerate development, but applications may need framework-specific conventions to use them effectively.

• Commercial support is less standardized: Finding engineers experienced with a particular Swift server stack can be harder than hiring for a widely adopted language.

Native C interoperability is a major strength, so existing database clients, cryptographic libraries, and other native components can often be integrated safely. It does not, however, eliminate the work required to package, monitor, update, and secure those dependencies.

Portability and Deployment

Swift supports server development on macOS, Linux, and Windows, but behavior is not completely identical across these platforms. The greatest production experience is generally on Linux and Apple platforms.

• Foundation differs by platform: Networking, filesystem, process, locale, and operating-system integration may behave differently on macOS, Linux, and Windows.

• System-library dependencies matter: A Linux deployment may require compatible versions of libc, ICU, OpenSSL or the platform TLS implementation, and other native libraries.

• Container images need testing: Static linking can simplify distribution, while dynamically linked applications must ensure every required shared library is present in the image.

• Local development can hide differences: A service tested on macOS should also be exercised in the same container image and operating-system configuration used in production.

Swift compilation tools are available on Linux, so CI does not require macOS, although Apple-platform integration may still require specialized infrastructure.

Concurrency and Shared State

Swift 6’s strict concurrency checking provides valuable compile-time protection against data races, but adopting it requires deliberate architectural changes.

• Actor isolation: Mutable server state should generally belong to an actor rather than being shared through unsynchronized classes.

• Sendable boundaries matter: Values crossing concurrency domains must be safe to transfer or share; mutable reference types usually require additional isolation.

• Blocking work needs care: Synchronous database calls, file operations, or CPU-heavy work can block a cooperative thread. Such operations should be isolated from request-processing tasks or moved to appropriate worker mechanisms.

• Third-party APIs may lag: Dependencies that are not concurrency-safe can produce warnings or errors in Swift 6 language mode and may require wrappers or isolation boundaries.

Strict concurrency reduces one class of defects, but it does not replace load testing, cancellation handling, timeouts, or back-pressure design.

Memory Management and Data Modeling

Swift’s automatic reference counting, or ARC, manages most object lifetimes without manual allocation. It also creates challenges that are less prominent in garbage-collected server runtimes.

• Reference cycles retain memory: Closures, delegates, and parent-child relationships can keep objects alive unexpectedly; weak or unowned may be appropriate where ownership is not shared.

• Value types reduce shared-state risks: Models and domain data are often clearer as structs, enums, and other value types.

• Copying has a cost: Large value types may be copied more often than expected, although the compiler can often optimize copies.

• Native boundaries require ownership rules: Objects retained across Objective-C, C, or C++ interfaces need careful lifetime and thread-safety handling.

Operational Tooling and Team Considerations

Swift’s runtime performance and deployment efficiency are generally strong, but server operations are still less standardized around the language.

• Observability conventions are fragmented: Structured logging through swift-log is established, while metrics, tracing, profiling, and crash-reporting choices may vary by framework or organization.

• Production support requires platform expertise: Engineers must understand native linking, system libraries, container images, TLS termination, and Linux diagnostics in addition to Swift itself.

• Hiring pool is narrower: Swift backend experience is less common than general backend experience, although Swift fundamentals transfer well to other server languages.

• Some existing backend tooling assumes another runtime: APM agents, managed SDKs, database tooling, and infrastructure templates may not support Swift directly.

The strongest adoption strategy is to use Swift for high-throughput services where its type safety, performance, and native interoperability provide clear value, while choosing mature libraries, designing around actors and value types, and validating the complete deployment path on the intended platform early.

Why Swift Changes the Classic Patterns

• Protocols over inheritance: Swift has no abstract classes. Shared behaviour comes from protocols plus extensions that supply default implementations, so “abstract factory” and “template method” usually become a protocol and a generic function.

• Value types: struct and enum are copied on assignment, so immutability and value semantics remove whole categories of bugs; standard-library collections such as Array and Dictionary add copy-on-write as an optimisation. Patterns that existed to protect mutable shared state (mutable singletons, prototype cloning) are often unnecessary.

• Extensions and generics: you can make a type conform to a protocol it does not own, which is the idiomatic form of the Adapter and Decorator patterns.

• ARC: reference types are reference-counted, so any pattern that stores a back-reference (delegate, observer, closure callback) must think about weak/unowned and retain cycles.

Structural and Creational Patterns

Behavioural Patterns

• Delegate: a class-bound protocol (protocol FeedDelegate: AnyObject) held as weak var delegate: FeedDelegate? so the delegator does not retain its owner. Still standard in UIKit; in SwiftUI you often replace it with a closure or @Binding.

• Observer / reactive: NotificationCenter and Combine remain, but the Observation framework (@Observable, iOS 17+) or ObservableObject with @Published is the modern way to make model changes drive SwiftUI views.

• Strategy: a protocol with interchangeable conforming types, or simply a closure property. Preferred over subclassing to swap algorithms.

• Coordinator: centralises navigation flow in UIKit apps; in SwiftUI, state-driven navigation with NavigationStack(path:) and a typed path array usually covers the same need with less machinery.

• Iterator: Sequence/IteratorProtocol for synchronous iteration and AsyncSequence/AsyncStream for asynchronous streams.

Concurrency Patterns in Swift 6

• Actor isolation: an actor serialises access to its mutable state, replacing manual locks. @MainActor marks UI-facing code.

• Sendable: types that cross concurrency domains must conform to Sendable (value types with Sendable members do so implicitly). In the Swift 6 language mode, strict concurrency checking turns data races into compile-time errors rather than runtime surprises.

• Structured concurrency: async let and withTaskGroup express fan-out/fan-in work and guarantee cancellation propagates to child tasks.

• Dependency injection: pass protocols into initializers instead of reaching for a global singleton, which also makes the injected type easy to mark Sendable.

Best Practices and Common Pitfalls

• Avoid retain cycles: use [weak self] in escaping closures that are stored by an object that self also owns; use unowned only when the referenced object is guaranteed to outlive the closure.

• Do not over-apply patterns: a protocol with one implementation and no test double is just indirection. Start with a struct and a function; introduce the pattern when variation or substitution actually appears.

• Watch mutable globals: a singleton holding mutable state must be isolated (@MainActor or an actor) to be safe under Swift 6 concurrency checking.

• Prefer composition and value types for models; reserve classes for identity, shared mutable state, or interoperability with Objective-C APIs.

• Keep UI patterns consistent: MVC is still Apple’s baseline for UIKit; MVVM with @Observable is the common choice for SwiftUI. Mixing several architectures in one feature set is a frequent source of confusion.

Injection Techniques

• Initializer injection: the dependency is an initializer parameter stored in a let. It is the default choice because the compiler guarantees the object is fully configured and the dependency cannot change afterwards.

• Property injection: a mutable property or a defaulted initializer parameter is set after construction. Useful for SwiftUI views and for framework-instantiated types you cannot control, but it allows an unconfigured object to exist.

• Method injection: the dependency is passed to the single method that needs it, which keeps the type stateless; awkward when many methods need it.

• Environment injection (SwiftUI): .environment(object) / .environment(\.key, value) publish dependencies to the view tree, read back with @Environment. This is SwiftUI’s built-in mechanism for view-level dependencies; for custom value types define a key conforming to EnvironmentKey and an EnvironmentValues property.

• Containers / service locators: third-party resolvers such as Swinject, Factory or Needle, added with Swift Package Manager. They centralise a large graph, but they hide dependencies from the compiler and from readers, so prefer a hand-written composition root until the graph genuinely justifies a container.

Protocol-Oriented Abstractions

Depend on a protocol, not a concrete class, so tests and previews can substitute a fake. Define the smallest protocol the consumer needs (interface segregation), keep it in the same module as the consumer, and let the concrete implementation live at the composition root — the single place, usually the App type or a factory, that knows about concrete types.

Concurrency and Sendable in Swift 6

• Under strict concurrency checking, a dependency that crosses an isolation boundary must be Sendable. Immutable structs are Sendable automatically; actors are Sendable.

• Mark UI-facing dependencies @MainActor, and mark injected closures @Sendable.

• Global mutable singletons are diagnosed as data races in Swift 6. If you need shared state, isolate it in an actor or a @MainActor type and inject it rather than referencing it globally.

• Actor dependencies naturally express async work; declare protocol requirements as async throws and call them with await.

Code Example

import Foundation
import Observation

struct User: Identifiable, Sendable, Decodable {
    let id: Int
    let name: String
}

// Abstraction the rest of the app depends on.
protocol UserRepository: Sendable {
    func fetchUsers() async throws -> [User]
}

struct HTTPUserRepository: UserRepository {          // Sendable: immutable struct
    private let url = URL(string: "https://api.example.com/users")!

    func fetchUsers() async throws -> [User] {
        let (data, response) = try await URLSession.shared.data(from: url)
        guard let http = response as? HTTPURLResponse, http.statusCode == 200 else {
            throw URLError(.badServerResponse)
        }
        return try JSONDecoder().decode([User].self, from: data)
    }
}

struct FakeUserRepository: UserRepository {          // injected in tests and previews
    let users: [User]
    func fetchUsers() async throws -> [User] { users }
}

@MainActor
@Observable
final class UserListViewModel {
    private let repository: UserRepository           // constructor injection
    private(set) var users: [User] = []

    init(repository: UserRepository) { self.repository = repository }

    func load() async {
        users = (try? await repository.fetchUsers()) ?? []
    }
}

@main
struct UsersApp: App {
    // Composition root: the only place that names a concrete implementation.
    @State private var viewModel = UserListViewModel(repository: HTTPUserRepository())

    var body: some Scene {
        WindowGroup { UserListView().environment(viewModel) }
    }
}

struct UserListView: View {
    @Environment(UserListViewModel.self) private var viewModel

    var body: some View {
        List(viewModel.users) { user in Text(user.name) }
            .task { await viewModel.load() }
    }
}

Best Practices and Common Pitfalls

• Inject through initializers with let properties by default; reserve property and environment injection for objects the framework creates.

• Keep the composition root unique; scattering HTTPUserRepository() construction across the app defeats the pattern.

• Avoid resolving dependencies inside body or in a view’s initializer, which re-runs frequently; build them once at the root.

• Do not use @unchecked Sendable to silence concurrency errors — make the type immutable or actor-isolated instead.

• In tests with Swift Testing, create the type under test with a fake (UserListViewModel(repository: FakeUserRepository(users: [...]))) rather than reaching for the real network.