Everything you need to know about Swift 5.10

Published on: March 7, 2024

The long awaited iOS 17.4 and iPadOS 17.4 have just been released which means that we could slowly but surely start seeing alternative app stores to appear if you’re an EU iOS user. Alongside the 17.4 releases Apple has made Xcode 15.3 and Swift 5.10 available.

There’s not a huge number of proposals included in Swift 5.10 but that doesn’t make this release less significant.

With Swift 5.10, Apple has managed to close some large gaps that existed in Swift Concurrency’s data safety features. In short, this means that the compiler will be able to catch more possible thread safety issue by enforcing actor isolation and Sendability in more places.

Let’s take a look at the two features that make this possible.

If you prefer to watch this content as a video, the video is avaialble on YouTube:

Enhanced concurrency checking

I’ve written about strict concurrency checking before but back then there were still some ways that your code could be unsafe without the compiler noticing. In Swift 5.10 Apple has patched these cases and the compiler will now correctly flag all of your unsafe code in strict concurrency mode.

Of course, that excludes code that you have marked with nonisolated(unsafe) or @unchecked Sendable because both of those markers indicate that the code should be safe but the compiler won’t be able to check that.

If you’ve worked with strict concurrency checking and you’ve resolved all of your warnings already (if you were able to, kudos to you! That’s not trivial) then Swift 5.10 might flag some edge cases that you’ve missed otherwise.

Better compile time checks to guard against data races are a welcome improvement to the language in my opinion and I can’t wait to see which other improvements Apple will make to strict concurrency checking in the near future. There are currently some active proposals that aim to address the usability of strict concurrency checking which is a very good thing in my opinion.

SE-0412 Strict concurrency for global variables

Proposal SE-0412 made its way into Swift 5.10 and it further strengthens Swift’s ability to guard against data races at compile time.

When you write code that involves shared state you open yourself up to data races from many locations if you don’t make sure that this shared state is safe to be used across threads.

In Swift 5.10, the compiler will only allow you to access shared mutable state from a concurrent context if:

  • This state is immutable and Sendable (learn more about Sendable here)
  • This state is isolated to a global actor (like @MainActor or an actor you’ve written yourself)

In any other cases, the compiler will consider accessing the shared state concurrently to be unsafe.

If you’ve taken measures that sidestep Swift Concurrency’s actors and Sendability (for example because you’re working with legacy code that uses Semaphore or DispatchQueue to synchronize access) you can opt out of concurrency checks for your global variables by marking them as nonisolated(unsafe). This marker will tell the compiler that it doesn’t need to do any safety checks for the marked property; you have made sure that the code is safe to be used from a concurrent context yourself.

Marking properties as nonisolated(unsafe) is a lot like force unwrapping a property. You might be certain that your code is safe and will work as expected but you’re on your own. You’ve told the compiler that you know what you’re doing and that you don’t need the compiler to perform any checks for you.

Whenever you’re tempted to use nonisolated(unsafe) you should always ask yourself whether it’s possible for you to actually make the type you’re marking isolated to a global actor or maybe you can make the type of the property Sendable and immutable.

In Summary

Swift 5.10 is a very welcome improvement to the language that makes Swift Concurrency slightly more reliable than it was in Swift 5.9. Swift 6.0 is slowly but surely being worked on and I think we’ll see the first Swift 6.0 beta around June when Apple announces iOS 18, Xcode 16.0, etc.

I’m excited to see Apple work on Concurrency and make (sometimes much needed) improvements with every release, and in my opinion Swift 5.10 is a fantastic milestone in achieving compile time safety for our asynchronous code.

Subscribe to my newsletter