Don’t be caught by the marketing hype in Apple’s long list of new features coming in macOS 15. Just as Sonoma’s biggest change came not in its emoji count, but in how iCloud works, something glossed over at the time, there will hardly be a mention of this year’s biggest change, with the arrival of Swift 6 and its deep concurrency.

It’s generally expected that the first beta-release of Xcode 16 made to support macOS 15, and provided to developers during WWDC next week, will bring the first beta of Swift 6. If Apple sticks to its normal timetable, that would bring the release of Xcode 16 with Swift 6 in mid-September.

This is the first major version of Swift for five years; version 5 was distinguished with its introduction of a stable binary interface (ABI), a key milestone in its evolution since its first release ten years ago. Central to the changes in Swift 6 is structured concurrency that encapsulates threads with proper controls.

Getting the best out of Apple silicon chips requires apps formed of multiple threads that can be run concurrently on different cores, and move between them freely, to make optimum use of processing power available without blocking other threads.

Structured concurrency didn’t become a feature of Swift until recently, in version 5.5 last September. Prior to that, support for multiple threads was largely achieved using closures and features in macOS, including the Process class in Foundation, dating back to the first release of Mac OS X. Swift now provides direct language support using async and await, in common with other modern languages.

For the moment, developers can opt to apply strict concurrency checks to their Swift code, an additional feature that can already be enabled in Xcode 15.

For anyone with code written in Swift, the results can come as quite a shock. While the source for SilentKnight breezed through with just a few minor changes required, other apps can generate hundred of warnings that will shortly become errors in Swift 6.

If you care to zoom in on this image, you’ll see that every one of those warnings for Swift 5 will become errors in Swift 6. That app, Skint, currently has a total of well over a hundred such warnings, and that’s in far less source code than most small apps. For those working with larger apps and legacy code dating back to early versions of Swift, strict concurrency checks can be even more alarming in their scale.

This doesn’t just apply to third-party code. There are still plenty of parts of macOS that aren’t yet ‘thread-safe’, and can only be called in safety from an app’s main thread. Swift 6 should accelerate their revision too. SwiftUI also has a role, as its declarative architecture forces you to code for concurrency from the outset, and makes it harder to lapse into bad habits that will quickly be found out by checks.

The good news is that these strict concurrency checks aren’t required for macOS 15, and developers can continue to work in Swift 5 while still building their apps in Xcode 16 for macOS 15. Instead, this helps guide us towards making our apps fully fit for the coming of deep concurrency. As more and more satisfy strict concurrency checks, so we’ll all see the benefits coming in how those apps make best use of all the cores and co-processors in Apple silicon chips.

Performance isn’t about benchmarks, but about how the apps you run every day make the best of your Mac’s hardware. The effects of Swift 6 will be felt on every Mac for years to come, even if it’s deemed too technical to mention alongside those new emoji.