Swift Versions

Chris Lattner, LLVM, and the closed Swift years (2010–2014)

Swift began as an internal Apple project around July 2010, started by Chris Lattner — the creator of LLVM (started 2000 at the University of Illinois Urbana-Champaign as Lattner’s graduate research) and the architect of the Apple compiler-toolchain modernization that had been ongoing since Lattner joined Apple in 2005. By 2010 LLVM was the foundation of the Apple platform’s entire compiler stack: Clang as the C / C++ / Objective-C front-end, LLDB as the debugger, the LLVM optimizer, and the LLVM-based linker.

Swift the language was conceived as “Objective-C without the C” — modern type system with generics, optionals as a first-class type-system feature, value semantics for collections, type inference, closures, and seamless interop with the existing Objective-C codebase that Apple platforms had been built on since the 1990s NeXTSTEP era. Lattner described the early design goals as making the language “safer than C, faster than scripting languages, and as expressive as a modern functional language.”

Swift remained a closed-source internal project for nearly four years, with a small team (it grew from Lattner alone in 2010 to about a dozen by 2013) building both the language and the standard library. The public reveal happened at WWDC 2014 on June 2, 2014, where Apple announced Swift as a forthcoming developer-facing language. Xcode 6.0 shipped Swift 1.0 in September 2014. The closed-source period seeded a structural problem the open-source era then had to undo — Swift 1 and Swift 2 were not designed with cross-platform portability in mind, and Linux / Windows support didn’t begin in earnest until after the December 2015 open-sourcing.

The December 2015 open-sourcing and Swift Evolution

On December 3, 2015, Apple open-sourced Swift under the Apache 2.0 license with a Runtime Library Exception. The release covered the compiler, the standard library, the REPL, the debugger, the package manager (Swift Package Manager, new at the time), and the foundation libraries needed for cross-platform Swift. The project moved to github.com/apple/swift with public issue tracking, public design discussions on a swift-evolution mailing list, and a Linux toolchain that shipped on the same day as the macOS toolchain.

The open-sourcing came with the Swift Evolution process: every language change after this point would go through a formal Swift Evolution Proposal (SE-NNNN) reviewed by a community-and-Apple committee. The first batch of proposals (SE-0001 through SE-0050ish) were the design changes that produced Swift 3.0. The process has held since: every major language addition or breaking change is an SE-NNNN proposal with a public review window, recorded acceptance/rejection rationale, and a documented migration path. (Reference: github.com/apple/swift-evolution.)

The transition wasn’t smooth. Swift 3.0 in September 2016 shipped a deliberate source-incompatible reset that cleaned up the Swift API guidelines; existing 1.x and 2.x code needed extensive migration. Apple shipped an automated migrator inside Xcode 8, but it was incomplete — large codebases needed days of manual fix-up. Swift 3 was the last major source break before Apple committed to long-term backwards compatibility within major version lines; subsequent majors (4, 5, 6) preserve source compatibility through their entire 4.x / 5.x / 6.x runs.

Chris Lattner’s 2017 departure

Chris Lattner left Apple in January 2017, six months after the Swift 3.0 ship. He went briefly to Tesla to lead Autopilot software (a tenure that lasted six months), then to Google Brain to lead the team that built Swift for TensorFlow (an ambitious, ultimately unsuccessful, effort to make Swift the programming model for ML), then co-founded SiFive (the RISC-V chip company), and most recently founded Modular. Lattner’s departure didn’t derail Swift — the language and toolchain are now stewarded by a much larger team at Apple (Ted Kremenek as project lead since 2018; Doug Gregor on the type system; John McCall on runtime; Holly Borla on concurrency) plus the open-source community — but the conceptual founder isn’t the day-to-day project lead anymore. Swift Evolution proposals from Lattner have become rare since the Tesla move.

The Swift Server Workgroup and Linux maturity

The Linux toolchain had shipped on day one of the December 2015 open-sourcing, but ergonomically Swift on the server was rough through the late 2010s. The standard library’s Apple-platform-only assumptions (Foundation depending on CoreFoundation, certain types being Cocoa-flavored) bled through the Linux toolchain. Building a small Swift HTTP server on Linux in 2016–2017 was a project, not a recipe.

The Swift Server Workgroup, established in 2018, gave the server-side story a formal home. SwiftNIO (Apple’s low-level event-loop networking library, modeled on Netty) launched alongside it. Vapor (the leading server-side Swift framework, started in 2016) consolidated as the recommended high-level option. By the early 2020s, Swift on the server had a credible toolchain — a static-binary Linux build, mature HTTP / GRPC libraries, async/await integration, and competitive performance.

Adoption is still niche compared to Java / Kotlin / Go on the server. The Swift-on-server pitch is most compelling for shops that already have Swift talent (typically iOS / macOS teams looking to share code or move into backend) or for performance-critical workloads where Swift’s value semantics, ARC memory model, and zero-cost abstractions provide a clear advantage. Notable production users include Apple’s own services (parts of the App Store backend), and a small but growing roster of shops where a unified Swift codebase across mobile and server pays off.

The concurrency progression: GCD → async/await → strict

Swift inherited Objective-C’s concurrency model: Grand Central Dispatch (GCD), a queue-based work-stealing system Apple shipped in macOS 10.6 Snow Leopard (2009). The pattern: dispatch closures to queues, use barriers and semaphores for coordination, lift a result back to the main queue when ready. It was a productive model for the iOS / macOS app idiom but sharp-edged: deadlock risks, no compile-time enforcement of thread safety, and verbose escape syntax for any non-trivial coordination.

Swift 5.5 (September 2021) shipped async/await, structured concurrency, and actors. The design (led by Ben Cohen, John McCall, and others on the Apple compiler team, with substantial community input through the Swift Evolution process) drew on Kotlin’s coroutines (cross-link: Kotlin coroutines history), Rust’s async story, and the structured-concurrency literature that had been emerging in academia. Swift’s actor model went farther than either language in baking thread-isolation into the type system: an actor is a reference type whose state is implicitly protected by an isolation domain, accessible only via await from outside.

Swift 6.0 (September 2024) made strict concurrency the default. New projects compile with data-race-safety errors enforced at the type level: any potential data race — passing a non-Sendable type across an isolation boundary, accessing shared state from a non-isolated context — becomes a compile-time error. Existing projects can opt into the Swift 5 language mode for an interim period. The transition has been substantial migration work for production codebases, similar in scope to the Swift 3 source-break of 2016 but more incremental: Swift 6 ships with progressive opt-in flags so teams can migrate file-by-file. Java’s comparable answer is virtual threads (Project Loom, stable in Java 21); Kotlin’s is the structured-concurrency conventions on top of coroutines (stable since Kotlin 1.3); the three languages converge on similar ergonomics from different starting points.

Windows, Embedded, and the cross-platform reach

Windows support landed in the late 2010s and has steadily improved. Saleem Abdulrasool of Apple has been the driving figure on the Windows toolchain; Swift 5.3 (September 2020) shipped substantial Windows quality-of-life improvements, and Swift 5.5+ has been usable for Windows apps without significant friction. The story is still less polished than on Linux — some Foundation features lag, the IDE integration is via VS Code rather than a Microsoft-side IDE — but viable.

Embedded Swift shipped as a stable subset in Swift 6.0. The pitch: Swift compiled with a subset of the standard library, no ARC, no metadata, suitable for microcontrollers (ESP32, RP2040), kernel-mode code, and resource-constrained targets. The work draws on the SwiftPM toolchain’s ability to produce static binaries and on language-level work to make optional features truly optional. Adoption is early but the path is now clear: Swift can target the same range of systems Rust does, with a different ergonomic profile.

People who actually shaped Swift

Original team: Chris Lattner (project lead 2010–2017; LLVM creator; Tesla / Google / SiFive / Modular post-departure), Joe Groff (compiler and runtime; key contributor since the early years), John McCall (runtime; one of the longest-tenured engineers on the project), Doug Gregor (type system; Clang background; led much of the Swift 3 redesign), Ted Kremenek (project lead 2018–present; static analysis lineage from Clang).

Concurrency design: Ben Cohen (the structured-concurrency model and async/await proposal), Holly Borla (current concurrency lead, Swift 6 strict-concurrency push), Konrad Malawski (server-side Swift, distributed actors).

Server-side and platform reach: Saleem Abdulrasool (Windows toolchain), Tom Doron (Swift Server Workgroup founding), Tim Condon (Vapor framework). Community: Paul Hudson (Hacking with Swift; long-running tutorial blog and book series that has done as much as any single resource to bring Swift to working iOS developers), Tibor Bödecs (server-side advocacy), Hector Matos and the long roster of Swift Evolution proposers whose names recur on accepted SE-NNNN proposals. Conferences: SwiftCraft and the various try! Swift conferences are the canonical venues; Apple’s WWDC remains the single largest annual event.