Migrate to Swift 6 while you are already in the code

Swift 6 migration belongs in an application's maintenance plan. For an established app, the sensible starting point is a dependency and module inventory, followed by a small migration attached to work the team already needs to do. A proposal to rewrite the application should carry a separate justification.

The reason to adopt stricter concurrency checks is substantial: shared mutable state is difficult to reason about when several tasks can reach it. But the benefit of stronger checks does not establish the cost or urgency of migrating a particular app. An owner needs a plan that connects technical changes to continued delivery.

Place the announcement in its actual week

Apple discussed Swift 6 in its 10 June 2024 developer-tools announcement. That date falls at the end of the editorial period beginning 5 June. It was an announcement of the direction and tools, not evidence that an existing application had already migrated.

The WWDC24 migration session demonstrates incremental adoption by module. It also distinguishes enabling complete concurrency checking in Swift 5 mode from enabling Swift 6 language mode. Those are different milestones, and an estimate should say which one it promises.

Current recommendations should be checked against the toolchain the project actually uses. Copying build settings from a 2024 presentation into a newer project without examining its isolation settings is poor maintenance. Equally, a newer compiler's availability does not mean the app has enabled the corresponding language mode everywhere.

Find the boundaries before counting warnings

Start with the build targets, shared modules and external packages. Record which are maintained, which supply source code and which arrive as binaries. Note the code that crosses into older callback APIs or code the team cannot change.

This inventory affects the migration order. A warning inside a small module owned by the team is different from an uncertain contract in an abandoned dependency. The latter may require a wrapper, replacement or a documented boundary assumption. Each option carries different risk and effort.

Do not start by dividing a warning count by an assumed number of fixes per day. Several diagnostics may arise from one design decision about shared state. Conversely, one warning at a widely used boundary can require careful investigation. A count is useful for tracking a known module, not for pricing an unknown codebase.

A good first task produces an inventory and a bounded trial migration. Choose a module whose behavior is understood and whose external dependencies can be examined. It need not be the smallest module if it teaches little about the difficult boundaries ahead.

Attach the work to an actual product change

A planned change to synchronization or data loading may already require reading the relevant concurrency code. That creates an opportunity to improve isolation while context is fresh. It avoids repeatedly rediscovering the same assumptions in separate projects.

Keep the scope explicit. Implementing a customer feature and migrating an entire application in one change makes review and diagnosis harder. Instead, define the migration boundary, preserve the intended behavior and explain which adjacent modules remain unchanged. Schedule another slice when there is a reason to enter that code.

There are exceptions. A confirmed concurrency defect, a blocking dependency change or a toolchain requirement can justify dedicated migration work. Waiting for unrelated feature work in those circumstances may be more expensive. The principle is to tie timing to a concrete risk or delivery need, rather than the novelty of a language version.

Removing a diagnostic is not the whole acceptance test

Compiler diagnostics can lead to better ownership of mutable data. They can also tempt a rushed team to suppress checks without resolving the underlying assumption. In particular, an @unchecked Sendable declaration should be treated as a claim the developer must explain, not a routine way to make the build pass.

Ask what protects the state, where that protection is enforced and why callers cannot bypass it. If the justification relies on a library's behavior, record which version and contract support it. Unsupported assumptions at external boundaries limit what the compiler can establish.

The guarantee also has a scope. Data-race checking does not prove that the application performs the right business operation, never deadlocks or always presents results in the desired order. A programme can access memory safely and still overwrite a newer screen result with an older response. Keep behavioral verification alongside compiler checks.

For a migrated module, request evidence from the real project: successful builds in the intended configuration, review of escape hatches and relevant behavior checks. Demonstrate those acceptance conditions on the application's actual toolchain.

Make the estimate legible to an owner

An estimate should separate discovery, a representative migration slice and the remaining rollout. It should explain the dependency assumptions that could change the price. That gives the owner a useful decision point before authorizing a broad effort.

The strongest argument for a dedicated programme is consistency. A team living indefinitely between modes can accumulate awkward boundaries and postponed work. Incremental migration therefore needs an owner and a completion criterion. “We will fix warnings whenever convenient” is not a plan.

For a small, stable app, the initial conclusion may be that the urgent work is replacing an unsupported dependency. For an actively developed app, it may be appropriate to require new modules to meet stricter checks while existing modules follow a schedule. Neither decision follows from the app's age alone.

In an iPhone application project, ask for the module map and the first reviewable slice. Budget the migration as maintenance that protects future changes. Approve a rewrite only when its wider costs and benefits have been argued independently of Swift 6 adoption.