How to Migrate to Swift 6 Strict Concurrency with AI (Without Losing Control)

• Turn on Swift 6.2’s approachable concurrency settings first. In app targets they can remove a large share of errors before any code changes.
• Migrate one module at a time, in Swift 5 mode with strict checking set to Complete.
• Let the agent fix errors in small batches, not the whole project in one go.
• Tell it which shortcuts are off-limits, and ask it to list any it had to use.
• Review every diff for unsafe escape hatches before you approve it.
• Test on real devices, because a passing build proves the compiler is happy, not that your app is thread-safe.

Swift 6 language mode turns data-race safety from a suggestion into a rule. Code that could let two threads touch the same mutable state at once, which Swift 5 mostly allowed, now fails to compile. The checks existed as warnings before. In Swift 6 mode they become errors.

You’ll meet the same few ideas again and again:

• Sendable.A type is Sendable if it’s safe to pass between concurrency domains. Value types made of Sendable parts usually qualify. Classes with mutable state usually don’t.
• Actor isolation.An actor protects its own state by running one task at a time. @MainActor is the actor for UI work, and most SwiftUI and UIKit code belongs there.
• Isolation boundaries.Most errors happen where a value crosses from one isolation domain to another, for example from the main actor into a background task.
• Global and static state.A mutable global or static variable shared across concurrency domains needs appropriate isolation or synchronization. A singleton can be safe when its state is protected by an actor, a lock, or another sound synchronization mechanism.

Swift 6.2, which shipped with Xcode 26, added what the Swift team calls approachable concurrency. In Xcode it comes down to two build settings:

• Default Actor Isolation (SWIFT_DEFAULT_ACTOR_ISOLATION).Set it to MainActor and code in that module runs on the main actor unless you say otherwise. For app targets, where most code touches the UI anyway, this removes a large share of errors in one step.
• Approachable Concurrency (SWIFT_APPROACHABLE_CONCURRENCY).Under Swift Compiler – Upcoming Features. Turning it on enables a set of upcoming features. One key feature lets nonisolated async functions run on the caller’s actor by default rather than automatically switching to a generic executor. This can reduce unnecessary executor hops, but it does not guarantee background execution. Use @concurrent when an async function needs to execute on a concurrent executor.

When a nonisolated async function needs to execute on a concurrent executor rather than inherit the caller’s actor isolation, use @concurrent. Actual parallelism depends on the work and concurrency structure. Concurrency becomes something you opt into, not something that happens by surprise.

The Swift migration guide recommends a simple loop: pick a module, turn on stricter checking while still in Swift 5 mode, fix the warnings, and repeat. Its advice is to express what is true now, with the smallest changes that reach a warning-free state, rather than redesigning your code mid-migration. That advice matters even more when an agent is writing the changes.

• Volume.A concurrency migration is hundreds of small, similar fixes: adding @MainActor to a view model, marking a struct Sendable, moving a UI update onto the main actor. An agent does these quickly and consistently.
• Finding root causes.One non-Sendable model type can cause errors in 40 files. An agent that reads the whole build log and knows how your types depend on each other spots the shared cause and fixes it once, instead of patching 40 call sites.
• The build-fix loop.Concurrency fixes cascade. Marking one type @MainActor can create new errors wherever it’s used from a background task. An agent that rebuilds after every batch catches those knock-on errors straight away.
• Explaining the errors.Swift’s concurrency messages are precise but dense. Asking the agent "why is this an error?" before "fix it" is a fast way to learn the model as you migrate.

The compiler checks that your code claims to be safe. It can’t always check that the claim is true. Swift gives you escape hatches for the rare cases where you know better than the compiler, and an agent under pressure to get the build green may reach for them far too often:

• @unchecked Sendabletells the compiler "trust me, this class is thread-safe." If it isn’t, you’ve hidden a data race rather than fixed it.
• nonisolated(unsafe)switches off checking for a variable. Fine for a truly immutable global; dangerous for anything that changes.
• @preconcurrency importsilences errors from a library that hasn’t adopted Sendable yet. Sometimes right, but it should be a deliberate choice.
• MainActor.assumeIsolatedasserts you’re already on the main thread. If you’re wrong, the app crashes at runtime.
• Blanket @MainActor on everything,including networking and heavy processing, can make the errors vanish while moving slow work onto the UI thread.
• Wrapping code in Task { } to escape an isolation error.Creating an unstructured task solely to silence an isolation error can hide the underlying design problem. Tasks may outlive the screen that created them, and cancellation and lifetime management should be deliberate.

Every one of these produces a passing build. That’s why the rest of this guide focuses on scope, instructions and review. The agent does the typing; you stay in charge of the judgement calls.

Make sure the project builds cleanly in Swift 5 mode and everything is committed to Git. Create a branch for the migration. You’ll commit after every module, so you can always roll back one step instead of starting over. Phoenix also records each file before it first changes it, so rejecting a diff restores the original exactly.

Ask the agent to survey the codebase first, without changing anything: which modules exist, which depend on which, where the singletons and shared mutable state live, and which third-party packages haven’t adopted Sendable. Save the answer. It’s your migration plan, and it tells the agent where the hard parts are.

Phoenix starts every task by building a knowledge graph of your Swift code (types, methods, conformances and which files depend on which), so this survey is quick and grounded in your real structure. On a codebase you didn’t write, its App Information panel also gives you a written briefing on the architecture and the five files to read first.

If you’re on Xcode 26 or later, decide now whether each target should use Default Actor Isolation = MainActor and Approachable Concurrency = Yes. Do this before fixing anything by hand: it can remove a large share of errors in app code. Library and framework targets often shouldn’t be main-actor by default, so decide per target.

You can ask the agent to make the change. Phoenix asks for your confirmation before it edits build settings, so you’ll see exactly which setting changes on which target before it happens.

The Swift migration guide suggests starting with an outer module that nothing else depends on, so changes stay local. The exception is a low-level module full of shared models: fixing it first often clears warnings across the whole project. Your map from Step 2 shows which case you’re in.

In the target’s build settings, set Strict Concurrency Checking (SWIFT_STRICT_CONCURRENCY) to Complete while leaving the Swift language version at 5. You’ll see every Swift 6 problem as a warning, but the project still builds. That lets you fix issues in batches without a broken build blocking the rest of your work.

Hand the agent one module, or even one group of related files, at a time. Give it rules up front (see the prompts below): no @unchecked Sendable without explaining why, no nonisolated(unsafe) on mutable state, and a list of any escape hatches it did use.

Two practical tips for Phoenix:

• Choose a stronger model at High effort for this work.Concurrency fixes reward careful reasoning more than speed. Use a lighter model at Low effort for simple follow-ups like adding a missing await.
• Size batches to fit one task.Phoenix allows up to five build attempts per task and then stops to explain what’s left. If a batch regularly runs out of attempts, it’s too big: split it.

Phoenix shows each change as a diff you approve or reject. Read them with the checklist in the next section. Reject shortcuts and say why: "Don’t mark this class @unchecked Sendable; it has a mutable cache. Make it an actor instead." The agent will try again with that constraint.

Once the module has no concurrency warnings, change its Swift language version to 6 and build. Run your test suite, then run the app on a real device and exercise the screens that the module touches. Concurrency bugs often show up only under real timing.

Before you commit, check for leaks the migration may have introduced. New Task { } blocks and AsyncStreams are the usual suspects. Phoenix’s Memory Diagnostics flags unstructured tasks that nothing cancels and stream continuations that never finish, alongside classic retain cycles. Then commit and move on to the next module.

Any escape hatch you accepted, such as a @preconcurrency import for a library that isn’t ready yet, goes on a short list with a reason. Revisit it when the library updates. Ship safe code today, and tidy the remaining edges later.

Copy these and adapt them to your project.

That last prompt is worth running even on code people wrote by hand. It gives you a list of every place the project trusts itself instead of the compiler.

Review checklist: good fixes vs shortcuts

• Does this change what the code does, or only what the compiler thinks?Real fixes often change structure: a class becomes an actor, work moves to the right thread. Pure annotations deserve a second look.
• Would I be comfortable explaining this in code review?If an escape hatch needs a comment to justify it, ask the agent to add one, or pick a different fix.
• Did the agent stay inside the module I gave it?A concurrency fix that reaches into five other modules is harder to review and harder to roll back.

None of these escape hatches is banned. Each exists for real cases. The goal is to use them on purpose, with a reason written down, rather than by default.

Common questions