When Apple launched Xcode 16 final yr, they made the Swift 6 compiler accessible together with it. Which means that we are able to create new initiatives utilizing Swift 6 and its compile-time information race protections.
Nonetheless, the large query for a lot of builders is: Is 2025 the proper time to undertake Swift 6 absolutely, or ought to we follow Swift 5 for now?
On this put up, I received’t provide you with a definitive reply. As an alternative, I’ll share my perspective and reasoning that can assist you resolve whether or not adopting Swift 6 is best for you and your mission(s).
The best reply is determined by a great deal of variables just like the mission you’re employed on, the group you’re employed with, and your information of Swift Concurrency.
Xcode 16, current initiatives, and Swift 6
When you’ve opened an current mission in Xcode 16, you may not have observed any fast adjustments. Whereas the Swift 6 compiler is utilized in Xcode 16 for all initiatives, Xcode defaults to the Swift 5 language mode for current initiatives.
When you’ve skilled earlier main migrations in Swift, you’ll keep in mind that Xcode would often immediate you to make adjustments to your mission with a purpose to ensure your mission nonetheless works. This occurred for the migration from Swift 1.2 to Swift 2, and from Swift 2 to Swift 3.
We obtained a brand new compiler, and we had 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 imposing all of the stricter guidelines of Swift 6. For instance, the Swift 5 language mode will make it in order that compile-time information race protections should not turned on.
So, once we discuss adopting Swift 6, we’re actually speaking about opting into the Swift 6 language mode.
Present initiatives which can be opened in Xcode 16 will, robotically, use the Swift 5 language mode. That’s why your mission nonetheless compiles completely advantageous with out adopting Swift 6.
What about new initiatives?
New initiatives in Xcode 16 additionally default to Swift 5 language mode. Nonetheless, Swift packages created with the Swift 6 toolchain default to Swift 6 language mode except explicitly configured in any other case. This distinction is necessary, as a result of whenever you create new packages you’re working in a special language mode than mission (and that’s completely advantageous).
When you’re curious about enabling the Swift 6 language mode for current initiatives or packages, I’ve some weblog posts about that right here:
Challenges of Adopting Swift 6
Switching to Swift 6 language mode could make initiatives that compiled simply advantageous 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 features into actors. Nonetheless, different points, particularly these involving crossing isolation boundaries, may 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 features as a result of actors function in their very own isolation contexts.
Adopting actors is often a process that may take a lot, for much longer than you may count on initially.
Resolving errors with @MainActor
A typical 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 at all times the answer that you simply’re on the lookout for. Whereas not inherently fallacious, this strategy ought to be used with warning.
Decreasing crossing of isolation boundaries
Apple acknowledges the challenges of adopting Swift 6, particularly for current initiatives. One vital facet of Swift Concurrency that may make adoption difficult is how non-isolated asynchronous features inherit isolation contexts. At present, nonisolated async features run on a background thread except explicitly remoted, which might result in pointless crossing of isolation boundaries.
Apple is exploring methods for such features to inherit the caller’s isolation context, doubtlessly lowering sendability errors and making adoption of Swift 6 rather more easy.
So, ought to we undertake Swift 6?
For current initiatives, I like to recommend continuing cautiously. Persist with Swift 5 language mode except:
• Your mission is small and manageable for migration.
• You may have a powerful understanding of concurrency ideas and might decide to resolving sendability points.
New initiatives may 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 help.
When you’re modularizing your codebase with Swift packages, I like to recommend utilizing Swift 6 language mode on your (new) packages, as packages usually have fewer dependencies on Apple’s frameworks and are simpler to adapt and you’ll have Swift 5 and Swift 6 modules in the identical mission.
On the point of undertake Swift 6
Earlier than adopting Swift 6, make sure you perceive:
• Sendability and tips on how to resolve associated errors.
• Using actors and their affect on isolation and asynchronicity.
• Methods to navigate ambiguous compiler errors.
I cowl all of those subjects and extra in my ebook, Sensible Swift Concurrency in addition to my workshops. You too can overview and research Swift evolution proposals and discussion board discussions to get a superb sense of how Swift Concurrency works.
When 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.
