Swift — Cradle to Mastery

Swift was designed by Chris Lattner, the creator of the LLVM compiler infrastructure, over four years of secret development inside Apple before its surprise unveiling at WWDC 2014 — replacing Objective-C with a language built from the start around safety (optionals, value types) without giving up the performance Apple's platforms needed.

The Swift compiler and toolchain run natively on Linux and Windows with no Xcode involved at all; Xcode is required only when you're actually building and submitting an iOS or macOS app, not for learning or writing Swift itself.

Swift treats <code>let</code> as the default reach for most values, with <code>var</code> reserved for the genuine exception where reassignment is actually needed — a small syntactic nudge, like Kotlin's <code>val</code>, toward writing more code that simply can't be accidentally mutated.

Swift's <code>switch</code> makes two real, compiler-enforced departures from C's classic version: every possible case must genuinely be covered (exhaustiveness), and execution never silently falls through into the next case unless you explicitly ask for it with <code>fallthrough</code>.

A Swift function parameter can carry an external name the caller writes at the call site and a completely different internal name the function body actually uses — letting a call read like a natural sentence while the implementation still gets a name that makes sense to it.

The compiler requires the <code>@escaping</code> annotation the exact moment a closure might be stored and called after the function that received it has already returned — a real, enforced distinction from a closure that only runs synchronously during the call, not just documentation.

A Swift function that can fail must be explicitly marked <code>throws</code>, and every call site must use <code>try</code> to acknowledge that — a real, compiler-enforced requirement, though genuinely lighter-weight than Java's checked-exception system since there's no exception-type hierarchy to declare.

Swift's <code>Optional</code> makes the possibility of absence part of a value's actual type, checked at compile time through <code>if let</code>, <code>guard let</code>, the nil-coalescing operator <code>??</code>, and optional chaining — and that same safety-first design extends to value types, where assigning a struct to a new variable produces a genuine, independent copy rather than a shared reference.

Assigning a struct instance to a new variable produces a genuine, fully independent copy — change one and the other is untouched — while assigning a class instance makes both variables point at exactly the same underlying object, so a change through either one is visible through both.

A Swift enum case can carry genuinely different associated data of its own — unlike most languages' plain named-constant enums — which is what lets a single enum model something like a network response's several distinct shapes without a separate class hierarchy at all.

Because <code>Array</code>, <code>Set</code>, and <code>Dictionary</code> are all themselves structs, they inherit exactly the same copy-on-assignment guarantee every other Swift struct has — implemented efficiently under the hood through copy-on-write, so the actual copy only happens the moment one side is genuinely mutated.

<code>if case</code> lets you check a single pattern — say, one specific enum case with associated values — without writing out a full <code>switch</code> and its other, irrelevant branches, which is genuinely useful exactly when only one case actually matters to the code at hand.

Indexing a Swift string with a plain integer doesn't even compile, a deliberate design choice made because a single visible character (grapheme cluster) can genuinely be composed of multiple Unicode scalar values — so Swift forces you through its <code>String.Index</code> type rather than pretending integer indexing is safe when it silently isn't.

A Swift extension can add a genuinely new computed property, method, or even protocol conformance to an existing type like <code>Int</code> — including ones you don't own — but it can never add a stored property, a real structural limitation rooted in how existing instances' memory layout can't retroactively grow.

<code>public</code> lets code in a different module use your class, but that alone is not enough to subclass or override it there — <code>open</code> is Swift's separate, deliberately stronger access level specifically required before another module can do that.

A protocol's <code>associatedtype</code> lets it require that conforming types provide some type, without the protocol itself ever naming what that type actually is — each conforming type fills in its own concrete answer, inferred automatically from how it's used, which is what makes protocols like <code>Collection</code> genuinely generic.

Conforming a struct or class to <code>Codable</code> makes the compiler automatically synthesize its entire JSON encoding and decoding logic, matching property names to JSON keys — zero manual key-by-key mapping code required for the common case.

This lesson is the synthesis for the stage: protocol conformance, default implementations via protocol extensions, the <code>some</code> and <code>any</code> keywords for working with protocol types, generics with <code>where</code> clauses from the previous lesson, and <code>Codable</code> &mdash; Swift's protocol-oriented style seen as one coherent whole rather than separate features.

An <code>async</code> function cannot simply be called from ordinary synchronous code the way a regular function can; <code>Task { }</code> is the actual bridge that starts a new piece of asynchronous work running from synchronous context, which is worth understanding before async/await otherwise seems to mysteriously not compile.

A Swift <code>actor</code> automatically serializes every access to the state it owns, so two pieces of code can never race on the same actor's data — and that safety guarantee is exactly why reading even a simple property from outside the actor requires <code>await</code>, not a stylistic quirk.

Two class instances each holding a strong reference to the other create a retain cycle that ARC can never break on its own — not a bug in automatic reference counting, but genuinely its single most common real-world failure mode, and exactly what <code>weak</code> and <code>unowned</code> references exist to prevent.

This lesson is the synthesis for the stage: async/await and <code>Task</code> from two lessons ago, actors and <code>@MainActor</code> for safe state access, <code>Sendable</code> for safely crossing concurrency domains, structured concurrency's guarantees, and ARC's memory model including the retain cycles the previous lesson covered &mdash; concurrency and memory management seen as the one connected system they actually are in real Swift code.

<code>@propertyWrapper</code> is a genuine, ordinary language mechanism you can write yourself — SwiftUI's <code>@State</code> is not special, hidden compiler magic at all, just an ordinary struct that happens to use this exact same mechanism, which is worth knowing before SwiftUI's property wrappers otherwise feel like unexplainable magic.

A SwiftUI <code>View</code>'s <code>body</code> is not a UI-building function that runs once — it is a declarative description of what the UI should look like for the current state, and SwiftUI automatically redraws it whenever any state the body reads actually changes.

Combine models values that arrive over time as a genuine reactive stream — but for the common case of a single, one-shot asynchronous result, Swift's own <code>async</code>/<code>await</code> is now usually the simpler, more direct choice, which is worth knowing before reaching for Combine out of habit.

<code>Result&lt;Success, Failure&gt;</code> is genuinely just an enum with two cases, no hidden compiler magic involved, offering a real typed alternative to Swift's own <code>throws</code> mechanism for situations where you want to store, pass around, or defer handling of a fallible outcome.

<code>@objc</code> cannot bridge everything: a Swift struct, or an enum carrying associated values, genuinely cannot be exposed to and used from Objective-C code at all, which matters directly for any codebase still mixing the two languages during a gradual migration.

Vapor, a genuine server-side Swift framework, runs on the identical Swift toolchain used to build iOS apps — the same <code>async</code>/<code>await</code> and structured concurrency work exactly the same way on a Linux server as they do in an iOS app, with no separate server-flavored dialect of the language to learn.

Unlike almost every other language's dependency manifest — typically JSON, YAML, or XML — <code>Package.swift</code> is itself real, compiled Swift code, which means it can use conditionals, variables, and any other language feature to describe a package's dependencies and targets.

Swift Testing needs no test class, no inheritance from a base test case, and no method name that starts with <code>test</code> — the <code>@Test</code> attribute alone is enough to mark any ordinary function as a real, runnable test, a genuinely lighter-weight model than XCTest's class-based approach.