When you start learning about actors in Swift, you’ll find that explanations will always contain something along the lines of “Actors protect shared mutable state by making sure the actor only does one thing at a time”. As a single sentence summary of actors, this is great but it misses an important nuance. While it’s true that actors do only one thing at a time, they don’t always execute function calls atomically. In this post, we’ll explore the following: Exploring what actor reentrancy is Understanding why async functions in actors can be problematic Generally speaking, you’ll use actors for objects...

A while ago I’ve published a post that explains how you can use AsyncStream to build your own asynchronous sequences in Swift Concurrency. Since writing that post, a new approach to creating AsyncStream objects has been introduced to allow for more convenience stream building. In this post, I’ll expand on what we’ve already covered in the previous post so that we don’t have to go over everything from scratch. By the end of this post you will understand the new and more convenient makeStream method that was added to AsyncStream. You’ll learn how and when it makes sense to build...

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...

Swift’s current concurrency model leverages tasks to encapsulate the asynchronous work that you’d like to perform. I wrote about the different kinds of tasks we have in Swift in the past. You can take a look at that post here. In this post, I’d like to explore the rules that Swift applies when it determines where your tasks and functions run. More specifically, I’d like to explore how we can determine whether a task or function will run on the main actor or not. We’ll start this post by very briefly looking at tasks and how we can determine where...

When you just start out with learning Swift Concurrency you’ll find that there are several ways to create new tasks. One approach creates a parent / child relationship between tasks, another creates tasks that are unstructured but do inherit some context and there’s an approach that creates tasks that are completely detached from all context. In this post, I will focus on unstructured and detached tasks. If you’re interested in learning more about child tasks, I highly recommend that you read the following posts: Running tasks in parallel with Swift Concurrency’s task groups Running tasks concurrently with Swift Concurrency’s async...

Swift Concurrency heavily relies on a concept called Structured Concurrency to describe the relationship between parent and child tasks. It finds its basis in the fork join model which is a model that stems from the sixties. In this post, I will explain what structured concurrency means, and how it plays an important role in Swift Concurrency. Note that this post is not an introduction to using the async and await keywords in Swift. I have lots of posts on the topic of Swift Concurrency that you can find right here. These posts all help you learn specific bits and...

In iOS 13, we gained the ability to easily send and receive data using web sockets through URLSession. With async/await, we gained the ability to fetch data from servers using the await keyword and we can iterate over asynchronous sequences using async for loops. We can even read data from a URL one line at a time by calling the lines property on URL: let url = URL(string: "https://donnywals.com")! for try await line in url.lines { // use line } While this is really cool and allows us to build apps that ingest data in real time if the server...

In an earlier post, I wrote about different ways that you can bridge your existing asynchronous code over to Swift’s new Concurrency system that leverages async / await. The mechanisms shown there work great for code where your code produces a single result that can be modeled as a single value. Since writing this post we've gained AsyncStream.makeStream which makes stream creation a lot smoother. Learn more in this post. However in some cases this isn’t possible because your existing code will provide multiple values over time. This is the case for things like download progress, the user’s current location,...

If you want to make sure that your code adopts Swift concurrency as correctly as possible in Swift 5.x, it's a good idea to enable the Strict Concurrency Checking (SWIFT_STRICT_CONCURRENCY) flag in your project. To do this, select your project's target and navigate to the Build Settings tab. Make sure you select All from the list of settings that is shown (Basic is the default) and type Strict Concurrency in the searchbar to find the Strict Concurrency Checking build setting. The screenshot below shows all the relevant parts for you to see: The default value for this setting is Minimal...

One of the goals of the Swift team with Swift’s concurrency features is to provide a model that allows developer to write safe code by default. This means that there’s a lot of time and energy invested into making sure that the Swift compiler helps developers detect, and prevent whole classes of bugs and concurrency issues altogether. One of the features that helps you prevent data races (a common concurrency issue) comes in the form of actors which I’ve written about before. While actors are great when you want to synchronize access to some mutable state, they don’t solve every...