Write Swift

Write Swift guides the writing and review of modern Swift across data modeling, errors, concurrency, protocols, API design, performance, memory, testing and migration. Its central rule is progressive disclosure: begin with the simplest static, synchronous implementation and introduce reference semantics, concurrency, existential types or unsafe memory only for an identifiable reason. It defaults to structs and enums for data, concrete types before abstractions, some P before any P, and safe collections before specialized storage.

The skill uses a Swift 6.3 compatibility baseline with version-gated guidance through Swift 6.4. This is not a guarantee that every feature works in a particular Xcode, SDK or deployment target. Its concurrency model assumes Swift 6.2; earlier projects need different rules. Compiler version, language mode and platform availability must be checked, and compatible older forms remain appropriate. When invoked without a specific question, the skill initially gives only a readiness response and waits for the actual request.

Use it to write or review Swift involving value semantics, concurrency, generic relationships, ownership or tests. The recommendations are opinionated starting points, subordinate to project conventions, user requirements and accessibility. Illustrative examples are not measured performance results or proof that every supported configuration compiles. The workflow does not justify unrelated edits, dependency installation or broad rewrites beyond the authorized task.

For modeling, let is preferred until mutation is needed; classes require identity, sharing, inheritance or resource-lifetime reasons. Mutable reference storage inside a struct needs deliberate handling, such as copy-on-write. Enums represent mutually exclusive states, while noncopyable types express unique ownership. Recoverable failures throw; programmer mistakes use explicit preconditions. Error values carry context, guard makes exits visible and forced unwraps require a stated invariant.

Concurrency progresses from synchronous main-actor work to asynchronous latency handling, then measured CPU offloading and only then separate state isolation. App-facing modules and general libraries have different isolation defaults. Under the stated model, async alone does not move work off the actor. Profiling precedes offloading; await breaks atomicity, so assumptions need rechecking and locks must not span suspension. Actors protect mutual exclusion rather than complete asynchronous transactions or FIFO ordering.

Inputs are the concrete Swift question or code, project conventions, compiler configuration and relevant performance evidence. The resulting implementation or review should explain why more advanced mechanisms are needed. Sendability guidance prefers avoiding shared objects, using transferable values or isolating state before resorting to locks or unchecked promises. Public concurrency contracts are explicit, and unsafe annotations must not merely silence warnings.

Structured concurrency uses async let for a fixed number of child operations and bounded task groups for dynamic work. Unstructured tasks need explicit lifetime and cancellation management. Cancellation is cooperative, continuations must resume exactly once on every path, and stream adapters clean up on termination. In SwiftUI, synchronous action callbacks preserve frame-sensitive state changes while longer work proceeds separately. Capture only needed values when sendable closures cannot capture isolated self:

.visualEffect { [pulse] effect, proxy in    // copy the Bool, don't capture self
  effect.blur(radius: pulse ? 2 : 0)
}

Protocols emerge from repeated concrete behavior. Requirements define customization points, extension-only methods have different dispatch behavior, and composition avoids unnecessary inheritance. Generic relationships should remain visible until heterogeneous storage genuinely requires type erasure. API design prioritizes clarity at the call site, useful access boundaries and models that cannot express invalid states.

Performance work starts with algorithmic complexity, then Instruments measurements of calls, layout, allocations and copies. Specialized storage, inlining and ownership features follow evidence and toolchain checks. ARC guidance distinguishes last use from scope end, prefers avoiding reference cycles and keeps externally meaningful side effects out of deinitialization.

Swift Testing is the default for new tests, with XCTest retained for its stated UI, performance and Objective-C needs. The guidance covers expectations, requirements, parameterized cases, parallel execution, known issues and incremental coexistence. Macros are reserved for derivable boilerplate, tested as syntax transformations and expected to emit useful diagnostics. Logger from os supplies privacy-aware structured diagnostics and correlation identifiers; LLDB and Instruments support task inspection.

Unsafe interop remains narrowly scoped, with safe spans preferred where supported and Address Sanitizer used for pointer code. Modern syntax suggestions remain version-gated, including newer ownership, cancellation and diagnostic features. Migration builds with the newer compiler first, enables complete checking target by target, fixes root causes, switches language mode and refactors separately afterward. Final changes still need project-specific API verification and checks of visible states and reduced motion where applicable.