With Swift 6.2, Apple has made a several improvements to Swift Concurrency and its approachability. One of the biggest changes is that new Xcode projects will now, by default, apply an implicit main actor annotation to all your code. This essentially makes your apps single-threaded by default. I really like this change because without this change it was far too easy to accidentally introduce loads of concurrency in your apps. In this post I'd like to take a quick look at how you can control this setting as well as the setting for nonisolated(nonsending) from Xcode 26's build settings menu....

It's no secret that Swift concurrency can be pretty difficult to learn. There are a lot of concepts that are different from what you're used to when you were writing code in GCD. Apple recognized this in one of their vision documents and they set out to make changes to how concurrency works in Swift 6.2. They're not going to change the fundamentals of how things work. What they will mainly change is where code will run by default. In this blog post, I would like to take a look at the two main features that will change how your...

Once you start using Swift Concurrency, actors will essentially become your standard choice for protecting mutable state. However, introducing actors also tends to introduce more concurrency than you intended which can lead to more complex code, and a much harder time transitioning to Swift 6 in the long run. When you interact with state that’s protected by an actor, you have to to do so asynchronously. The result is that you’re writing asynchronous code in places where you might never have intended to introduce concurrency at all. One way to resolve that is to annotate your let's say view model...

Singletons generally speaking get a bad rep. People don’t like them, they cause issues, and generally speaking it’s just not great practice to rely on globally accessible mutable state in your apps. Instead, it’s more favorable to practice explicit dependency passing which makes your code more testable and reliable overall. That said, sometimes you’ll have singletons. Or, more likely, you’ll want to have a a shared instance of something that you need in a handful of places in your app: class AuthProvider { static let shared = AuthProvider() // ... } In Swift 6, this will lead to issues because...

Swift Concurrency provides us with loads of cool and interesting capabilities. For example, Structured Concurrency allows us to write a hierarchy of tasks that always ensures all child tasks are completed before the parent task can complete. We also have features like cooperative cancellation in Swift Concurrency which means that whenever we want to cancel a task, that task must proactively check for cancellation, and exit when needed. One API that Swift Concurrency doesn't provide out of the box is an API to have tasks that timeout when they take too long. More generally speaking, we don't have an API...

Swift 6 has been available to us for the better part of a year now, and more and more teams are considering or looking at migrating to the Swift 6 language mode. This typically involves trying to turn on the language mode or turning on strict concurrency, seeing a whole bunch of warnings or errors, and then deciding that today is not the day to proceed with this migration. Today I would like to propose an approach to how you can plan your migration in a way that won’t scare you out of attempting the migration before you’ve even started....

The Xcode 16.3 beta is out, which includes a new version of Swift. Swift 6.1 is a relatively small release that comes with bug fixes, quality of life improvements, and some features. In this post, I’d like to explore two of the new features that come with Swift 6.1. One that you can start using immediately, and one that you can opt-in on if it makes sense for you. The features I’d like to explore are the following: Changes to Task Groups in Swift 6.1 Changes to member visibility for imported code We’ll start by looking at the changes in...

When you turn on strict concurrency checking or you start using the Swift 6 language mode, there will be situations where you run into an error that looks a little bit like the following: Main actor-isolated property can not be referenced from a Sendable closure What this error tells us is that we're trying to use something that we're only supposed to use on or from the main actor inside of a closure that's supposed to run pretty much anywhere. So that could be on the main actor or it could be somewhere else. The following code is an example...

When Apple released Xcode 16 last year, they made the Swift 6 compiler available along with it. This means that we can create new projects using Swift 6 and its compile-time data race protections. However, the big question for many developers is: Is 2025 the right time to adopt Swift 6 fully, or should we stick with Swift 5 for now? In this post, I won’t give you a definitive answer. Instead, I’ll share my perspective and reasoning to help you decide whether adopting Swift 6 is right for you and your project(s). The right answer depends on loads of...

With Swift 6, we have an entirely new version of the language that has all kinds of data race protections built-in. Most of these protections were around with Swift 5 in one way or another and in Swift 6 they've refined, updated, improved, and expanded these features, making them mandatory. So in Swift 5 you could get away with certain things where in Swift 6 these are now compiler errors. Swift 6 also introduces a bunch of new features, one of these is the sending keyword. Sending closely relates to Sendable, but they are pretty different in terms of why...