Build and Tooling

This section documents the Swift 6 language mode as shipped by Swift 6.3, as published in The Swift Programming Language at docs.swift.org, which is the reference these pages are written and verified against. 6.4-beta-only features are always flagged as such — never presented as baseline.

This content was generated with the assistance of AI and should be verified against docs.swift.org before being relied on in production.

This section’s bibliography lists the reference material consulted while preparing these pages.

Swift’s toolchain is swiftc (the compiler), driven either directly, through Swift Package Manager, or through an IDE that wraps both — Xcode on Apple platforms, or VS Code with the official Swift extension everywhere else. Which toolchain version is active is managed separately, by Swiftly.

swiftc Essentials

swiftc -swift-version 6 main.swift -o app             # compile under the Swift 6 language mode
swiftc -O main.swift -o app                           # optimise for speed (release-like)
swiftc -Osize main.swift -o app                       # optimise for binary size
swiftc -enable-upcoming-feature ExistentialAny main.swift
swiftc -strict-concurrency=complete main.swift        # surface Swift 6 data-race diagnostics as warnings
swiftc -warnings-as-errors main.swift                 # fail the build on any warning
Flag Effect

-swift-version <5|6>

Selects the language mode the source is checked and compiled under.

-O / -Osize / -Onone

Optimise for speed, size, or disable optimisation (the debug default).

-enable-upcoming-feature <Name>

Opt one specific future-language-mode feature into the current mode ahead of a full version bump — see below.

-strict-concurrency=<minimal|targeted|complete>

How aggressively the compiler checks data-race safety under the Swift 5 language mode; complete matches what Swift 6 mode enforces unconditionally.

-warnings-as-errors

Promote every warning to a build failure.

-g

Emit debug info for LLDB.

-emit-module / -emit-library

Produce a .swiftmodule or a shared library instead of an executable.

Language mode versus compiler version is the distinction worth internalising: the compiler you install (Swift 6.3, say) always understands both the Swift 5 and Swift 6 language modes, and -swift-version (or a target’s swiftLanguageMode setting, see Swift Package Manager) chooses which one a given file or target is checked under — upgrading the toolchain never silently changes a codebase’s language mode. -enable-upcoming-feature lets a Swift 5-mode target adopt one named Swift 6 behaviour early and individually (each shipped as its own Swift Evolution proposal), which is the recommended incremental path rather than flipping the whole target to Swift 6 mode at once — see Actors, Isolation and Sendable for the concurrency-checking half of that migration.

Toolchain Management with Swiftly

Swiftly is Swift’s official, cross-platform toolchain manager (macOS and Linux), replacing per-OS install methods with one command surface:

swiftly install 6.3.2          # install a specific toolchain
swiftly install latest         # install the newest stable release
swiftly use 6.3.2              # switch the active toolchain for this shell/directory
swiftly list                   # installed toolchains
swiftly list-available         # toolchains available to install, including snapshots

A .swift-version file in a project’s root pins the toolchain Swiftly activates automatically on cd, the same role Package.swift’s `swift-tools-version comment plays for the manifest API (see Getting Started) — the two are independent settings.

Xcode, VS Code and SourceKit-LSP

Xcode remains the full IDE on Apple platforms: project/scheme management, Interface Builder, Instruments, and its own debugger UI over LLDB. Everywhere else — and increasingly on macOS too — the Swift extension for VS Code talks to SourceKit-LSP, the open-source Language Server Protocol implementation that also powers Xcode’s own code completion: it provides diagnostics, jump-to-definition, refactoring and completion from the same compiler front-end swiftc uses, so behaviour is consistent between the two editors. SourceKit-LSP is started automatically by both editors; it can also be driven directly by any other LSP-capable editor.

Cross-Platform Builds

Platform Notes

Linux

First-class since Swift’s open-sourcing; install via Swiftly or a distribution package. The static Linux SDK links the Swift runtime and standard library statically, producing a binary with no runtime dependency on the target machine’s Swift installation — the default choice for container images and CI artifacts.

Windows

Official installers at swift.org, with Visual Studio Code (or Visual Studio itself, via the Swift extension) as the supported editor integration.

WebAssembly

The official WebAssembly SDK (swift sdk install, tracking the SwiftWasm project’s work upstreamed into swift.org) compiles to wasm32-unknown-wasi; build with swift build --swift-sdk wasm32-unknown-wasi. See swiftwasm.org.

Android

An official Swift SDK for Android (stable since Swift 6.1) installed the same way, targeting aarch64-unknown-linux-android and similar triples; see Getting Started with the Android Swift SDK.

Embedded Swift

A restricted language subset (-enable-experimental-feature Embedded) with no runtime type metadata or reflection, sized for microcontrollers and other constrained targets; see Embedded Swift.

swift sdk install <bundle-url-or-path> installs any of these cross-compilation SDKs, after which swift build --swift-sdk <triple> targets them from the host toolchain — no separate cross-compiler install is needed beyond the SDK bundle itself.

Debugging with LLDB

(lldb) po value                    # print using the type's description
(lldb) p someInt                   # print a scalar / expression
(lldb) expr value = 42             # evaluate an expression, with side effects
(lldb) bt                          # backtrace for this thread
(lldb) frame variable              # every local in the current frame
(lldb) b main.swift:17             # breakpoint by file and line
(lldb) b -[MyType myMethod]        # breakpoint on a method (bridged Objective-C-style spec also works)
(lldb) breakpoint set -E swift     # break on every Swift error thrown
(lldb) c / n / s / finish          # continue / step over / step in / step out

swift run/swift test and Xcode both launch under LLDB by default; swift build && lldb ./app attaches to a standalone binary directly. breakpoint set -E swift is the Swift analogue of an Objective-C exception breakpoint — it stops execution at the exact throw site instead of unwinding first, which is invaluable when an uncaught error’s surface location is unhelpful.

Reading Compiler Diagnostics

A Swift diagnostic names the file, line and column, underlines the exact span, and — where the compiler can propose one — attaches a fix-it: a concrete source edit shown inline in the terminal and applied with one keystroke in Xcode or VS Code. Errors block compilation; warnings do not, unless -warnings-as-errors is set. Reading the first error in a cascade first pays off disproportionately — a single missing type annotation or mismatched generic constraint routinely produces several downstream errors that vanish once the root cause is fixed.

DocC Documentation Comments

/// Fetches the forecast for a city.
///
/// - Parameter city: The city name to look up.
/// - Returns: The parsed forecast.
/// - Throws: ``WeatherError/notFound`` if the city is unknown.
func forecast(for city: String) throws -> Forecast { ... }

Triple-slash /// comments (or /* */ block form) use DocC’s Markdown-based markup — - Parameter(s):, - Returns:, - Throws:, and double-backtick SymbolName cross-references to other documented symbols. swift package generate-documentation (via the swift-docc-plugin dependency, see Swift Package Manager) renders a package’s doc comments into a browsable DocC archive; Xcode’s *Product ▸ Build Documentation (⌃⇧⌘D) does the same for a project without any extra dependency.

swift-format

Since Swift 6, swift format ships as a built-in toolchain subcommand — no separate install:

swift format lint --recursive Sources/            # report style violations, no changes
swift format --in-place --recursive Sources/      # reformat in place
// .swift-format
{
  "version": 1,
  "lineLength": 120,
  "indentation": { "spaces": 4 },
  "respectsExistingLineBreaks": true
}

A .swift-format JSON file at the project root configures both the standalone command and the SwiftPM build-tool plugin (the apple/swift-format package dependency mentioned in Swift Package Manager) that runs the same tool as part of swift build. Run lint in CI and reserve --in-place for local, reviewable reformatting passes.

See Also

  • Swift Package Manager — swiftLanguageMode target settings and the swift-format plugin.

  • Actors, Isolation and Sendable — -strict-concurrency and the Swift 6 language mode’s data-race checking in full.

  • Testing — swift test and the two testing frameworks it runs.

  • Macros — expanding and debugging a macro from the compiler’s point of view.

References

TSPL: no dedicated chapter — the toolchain is documented separately from the language; see Version Compatibility for the language-mode rules this page’s -swift-version flag selects. Swift compiler; Swiftly; VS Code Swift extension; platform SDK guides; LLDB; DocC.