Swift 6 Strict Concurrency: Enabling Strict Mode in a Small App Without Downtime

Background

Swift 6 introduces a language mode that enforces strict data‑race safety by default. When a target is compiled with swiftLanguageMode = v6, many diagnostics that were merely warnings in Swift 5.9 become build‑time errors. For a small Swift application that must remain available, the question is how to activate this mode incrementally without triggering a full‑app redeploy.

Configuration Pathways

Two documented pathways exist:

• Per‑target language mode – setting SWIFT_LANGUAGE_VERSION or swiftLanguageMode in the target’s build settings allows a mix of Swift 5 and Swift 6 code.
• @preconcurrency imports – importing a non‑Sendable module under @preconcurrency suppresses diagnostics for that module while the rest of the app remains in strict mode.

Sendable Conformance Dilemma

When strict mode is enabled, all shared types must conform to Sendable. The trade‑off is between enforcing this requirement throughout the codebase and using @unchecked Sendable to opt out of checks for legacy types. The decision impacts long‑term safety versus short‑term migration cost.

Unresolved Decision Points

1. How can a small app enable strict concurrency for new modules while keeping existing modules compiled under Swift 5, ensuring no runtime downtime?
2. Which strategy offers the best balance between safety and migration effort: full Sendable enforcement or selective @unchecked Sendable opt‑outs?
3. Does activating strict concurrency affect binary compatibility with the current deployment target, and if so, what constraints must be considered?