/swift-programmer

name: swift-programmer
description: Swift-specific idioms, tooling, and philosophy for both application development and command-line scripting. Use when working with Swift code, including Swift scripts. Emphasizes protocol-oriented programming, value semantics, strict concurrency (Swift 6+), and compile-time safety guarantees.

Swift Programming

<skill_scope skill="swift-programmer"> **Related skills:**

• `software-engineer` — Core design principles and system architecture
• `macos-programmer` — macOS-specific patterns when building Mac apps
• `test-driven-development` — Testing philosophy and practices
• `functional-programmer` — Functional paradigm principles (Swift supports FP)
• `fish-shell-scripting` — Shell-scripting alternative when Swift's framework access isn't needed

This skill covers Swift-specific idioms, tooling, and philosophy for both application development and command-line scripting. It emphasizes protocol-oriented programming, value semantics, strict concurrency (Swift 6+), and compile-time safety guarantees. </skill_scope>

Core Philosophy

<core_philosophy> This section states the defaults this skill applies when writing Swift; the sections that follow give the judgment frameworks for the cases where a default doesn't fit.

**Let the compiler carry the safety argument.** Swift 6 adds compile-time data-race safety to memory safety, so design so that the checker can prove the code correct rather than suppressing its diagnostics; the working model for that — isolation domains rather than threads — is developed in `<concurrency_fundamentals>`.

**Prefer** protocol composition over inheritance, value semantics over reference semantics, and static dispatch over dynamic dispatch.

**Version targeting**: Use the latest Swift version available. For internal apps, target only the current version. For open-source libraries, support at most the current version and one or two prior ones. </core_philosophy>

Swift 6 Concurrency

<concurrency_fundamentals> **Think in isolation domains, not threads.** Each domain — a task, an actor, or a global actor such as the main actor — executes serially with exclusive access to its state, and every piece of mutable state belongs to exactly one domain at a time. An `await` marks a possible suspension point: the task may give up its thread there, and on resumption it may run on a different thread but always in the same isolation domain. Write the code after an `await` to tolerate suspension without depending on it having happened. The compiler reasons about logical isolation, not physical threading, so design for the former.

**Prefer structured concurrency.** Child tasks (`async let`, `TaskGroup`) inherit their parent's priority and cancellation and cannot outlive it. SE-0304 frames unstructured tasks — both `Task { }` and `Task.detached` — as the escape valve for work "whose lifetime is not bound to the creating task, for example in order to fire-and-forget some operation or to initiate asynchronous work from synchronous code."[^se-0304] The two differ in what they inherit: `Task.detached` inherits no actor isolation, priority, or task-local values, whereas `Task { }` inherits all three.[^tspl] Use `Task { }` for unstructured work that should keep its context, and `Task.detached` only when independence from that context is the point.

**Approachable Concurrency (opt-in, Swift 6.2+)**[^approachable-concurrency]: a configuration pairing SE-0461's caller's-actor default for `nonisolated async` functions[^se-0461] with SE-0466's default `@MainActor` inference.[^se-0466] Under it, unannotated code is inferred `@MainActor` and a `nonisolated async` function runs on whichever actor called it, so code that doesn't opt into parallelism runs sequentially and most data-race errors for naturally sequential code disappear. Parallelism still enters where you ask for it — `@concurrent`, `Task.detached`, a custom `actor`, or a concurrent API — and only the unannotated and `nonisolated async` cases change; explicitly isolated code behaves as before. Apple states that main-actor mode "is enabled by default for new app projects created with Xcode 26";[^wwdc25-268] existing targets and bare `-swift-version 6` builds do not enable it, and `swift package init` generates a manifest with the Swift 6 language mode but neither setting (observed with Swift 6.3.2; check the generated `Package.swift` on your toolchain). Check the target's settings before assuming either execution behavior. </concurrency_fundamentals>

Choosing an Isolation Strategy

<isolation_decision> Apple's own guidance sets the default: the main actor is "the most common way to protect global state," annotating a whole class `@MainActor` is common "especially in a project that doesn't have a lot of concurrent tasks," and default main-actor isolation is "recommended for apps, scripts, and other executable targets."[^apple-concurrency-updates] Reach for a custom `actor` when state is genuinely shared by concurrent work that runs off the main actor. The following table covers the common situations; it is not a complete list:

| Situation | Use | Why | |-----------|-----|-----| | UI state, SwiftUI observable models | `@MainActor` class (with `@Observable`) | SwiftUI reads state on the main actor; Apple DTS guidance is that view models "make sense … main-actor bound"[^dts-798211] | | Mostly single-threaded target (app, script, tool) | `-default-isolation MainActor` (Xcode: Default Actor Isolation) | Infers `@MainActor` project-wide, with concurrency encapsulated where you opt in[^apple-concurrency-updates] | | Mutable state shared by parallel workers | `actor` | A custom serialization domain; callers pay an `await` | | Global or static mutable state | `@MainActor` on the declaration or its type, or `let` of a `Sendable` type | SE-0412 requires every global to be actor-isolated or immutable-and-`Sendable`[^se-0412] | | No mutable shared state | `struct`, or a `final` class with only `l