When Apple launched Xcode 16 final 12 months, they made the Swift 6 compiler out there together with it. Which means we will create new tasks utilizing Swift 6 and its compile-time knowledge race protections.
Nevertheless, the massive query for a lot of builders is: Is 2025 the appropriate time to undertake Swift 6 totally, or ought to we follow Swift 5 for now?
On this put up, I gained’t offer you a definitive reply. As a substitute, I’ll share my perspective and reasoning that can assist you resolve whether or not adopting Swift 6 is best for you and your challenge(s).
The suitable reply depends upon a great deal of variables just like the challenge you’re employed on, the crew you’re employed with, and your information of Swift Concurrency.
Xcode 16, current tasks, and Swift 6
In the event you’ve opened an current challenge in Xcode 16, you may not have observed any rapid adjustments. Whereas the Swift 6 compiler is utilized in Xcode 16 for all tasks, Xcode defaults to the Swift 5 language mode for current tasks.
In the event you’ve skilled earlier main migrations in Swift, you’ll do not forget that Xcode would normally immediate you to make adjustments to your challenge to be able to ensure that your challenge nonetheless works. This occurred for the migration from Swift 1.2 to Swift 2, and from Swift 2 to Swift 3.
We received a brand new compiler, and we have been pressured to undertake the brand new Swift language model that got here together with it.
Since then, the compiler has gained some “language modes”, and the Swift 6 compiler comes with a Swift 5 language mode.
The Swift 5 language mode permits the Swift 6 compiler to operate with out implementing all of the stricter guidelines of Swift 6. For instance, the Swift 5 language mode will make it in order that compile-time knowledge race protections will not be turned on.
So, after we discuss adopting Swift 6, we’re actually speaking about opting into the Swift 6 language mode.
Present tasks which can be opened in Xcode 16 will, routinely, use the Swift 5 language mode. That’s why your challenge nonetheless compiles completely wonderful with out adopting Swift 6.
What about new tasks?
New tasks in Xcode 16 additionally default to Swift 5 language mode. Nevertheless, Swift packages created with the Swift 6 toolchain default to Swift 6 language mode except explicitly configured in any other case. This distinction is vital, as a result of while you create new packages you’re working in a special language mode than challenge (and that’s completely wonderful).
In the event you’re focused on enabling the Swift 6 language mode for current tasks or packages, I’ve some weblog posts about that right here:
Challenges of Adopting Swift 6
Switching to Swift 6 language mode could make tasks that compiled simply wonderful with Swift 5 break fully. For instance, you’ll run into errors about capturing non-sendable parameters, sendable closures, and actor isolation.
Some fixes are easy—like making an immutable object explicitly sendable or refactoring objects which can be utilized in async capabilities into actors. Nevertheless, different points, particularly these involving crossing isolation boundaries, could be a lot trickier to repair.
For instance, including actors to resolve sendability errors typically requires refactoring synchronous code into asynchronous code, resulting in a ripple impact all through your codebase. Even seemingly easy interactions with an actor require await, even for non-async capabilities as a result of actors function in their very own isolation contexts.
Adopting actors is usually a job that can take a lot, for much longer than you would possibly count on initially.
Resolving errors with @MainActor
A standard workaround is to liberally apply @MainActor annotations. Whereas this reduces concurrency-related errors by forcing most code to run on the principle thread, it’s not all the time the answer that you just’re searching for. Whereas not inherently mistaken, this method needs to be used with warning.
Lowering crossing of isolation boundaries
Apple acknowledges the challenges of adopting Swift 6, particularly for current tasks. One vital facet of Swift Concurrency that may make adoption difficult is how non-isolated asynchronous capabilities inherit isolation contexts. At present, nonisolated async capabilities run on a background thread except explicitly remoted, which might result in pointless crossing of isolation boundaries.
Apple is exploring methods for such capabilities to inherit the caller’s isolation context, doubtlessly decreasing sendability errors and making adoption of Swift 6 far more easy.
So, ought to we undertake Swift 6?
For current tasks, I like to recommend continuing cautiously. Keep on with Swift 5 language mode except:
• Your challenge is small and manageable for migration.
• You’ve got a powerful understanding of concurrency ideas and might decide to resolving sendability points.
New tasks could be constructed with Swift 6 language mode from the beginning, however be ready for challenges, particularly when interacting with Apple’s frameworks, which can lack full concurrency assist.
In the event you’re modularizing your codebase with Swift packages, I like to recommend utilizing Swift 6 language mode on your (new) packages, as packages typically have fewer dependencies on Apple’s frameworks and are simpler to adapt and you may have Swift 5 and Swift 6 modules in the identical challenge.
On the point of undertake Swift 6
Earlier than adopting Swift 6, make sure you perceive:
• Sendability and how you can resolve associated errors.
• Using actors and their influence on isolation and asynchronicity.
• Easy methods to navigate ambiguous compiler errors.
I cowl all of those subjects and extra in my guide, Sensible Swift Concurrency in addition to my workshops. You may also evaluate and examine Swift evolution proposals and discussion board discussions to get a very good sense of how Swift Concurrency works.
In the event you’ve began adopting Swift 6 or determined to carry off, I’d love to listen to your experiences! Join with me on X, BlueSky, or Mastodon.
