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. We’ll start by looking at the concept from a high level before looking at a few examples of Swift code that illustrates the concepts of structured concurrency nicely. Understanding the concept of structured concurrency The concepts behind Swift’s structured concurrency are neither new...

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. 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, and other similar situations. Generally speaking, these kinds of patterns would be modeled as AsyncSequence objects that you can...

If you want to make sure that your code adopts Swift concurrency as correctly as possible in Swift 5.7, it's a good idea to enable the Strict Concurrency Checking (SWIFT_STRICT_CONCURRENCY) 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 which...

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

When you’re writing a conversion layer to transform your callback based code into code that supports async/await in Swift, you’ll typically find yourself using continuations. A continuation is a closure that you can call with the result of your asynchronous work. You have the option to pass it the output of your work, an object that conforms to Error, or you can pass it a Result. In this post, I won’t go in-depth on showing you how to convert your callback based code to async/await (you can refer to this post if you’re interested in learning more). Instead, I’d like...

Swift’s async/await feature is an amazing way to improve the readability of asynchronous code on iOS 13 and newer. For new projects, this means that we can write more expressive, more readable, and easier to debug asynchronous code that reads very similar to synchronous code. Unfortunately, for some of us adopting async/await means that we might need to make pretty significant changes to our codebase if it’s asynchronous API is currently based on functions with completion handlers. Luckily, we can leverage some of Swift’s built-in mechanisms to provide a lightweight wrapper around traditional asynchronous code to bring it into the...

In my previous post you learned about some different use cases where you might have to choose between an async sequence and Combine while also clearly seeing that async sequence are almost always better looking in the examples I’ve used, it’s time to take a more realistic look at how you might be using each mechanism in your apps. The details on how the lifecycle of a Combine subscription or async for-loop should be handled will vary based on how you’re using them so I’ll be providing examples for two situations: Managing your lifecycles in SwiftUI Managing your lifecycles virtually...

Swift 5.5 introduces async/await and a whole new concurrency model that includes a new protocol: AsyncSequence. This protocol allows developers to asynchronously iterate over values coming from a sequence by awaiting them. This means that the sequence can generate or obtain its values asynchronously over time, and provide these values to a for-loop as they become available. If this sounds familiar, that’s because a Combine publisher does roughly the same thing. A publisher will obtain or generate its values (asynchronously) over time, and it will send these values to subscribers whenever they are available. While the basis of what we...

The biggest features in Swift 5.5 all revolve around its new and improved concurrency features. There's actors, async/await, and more. With these features folks are wondering whether async/await will replace Combine eventually. While I overall do not think that async/await can or will replace Combine on its own, Swift 5.5 comes with some concurrency features that provide very similar functionality to Combine. If you're curious about my thoughts on Combine and async/await specifically, I still believe that what I wrote about this topic earlier is true. Async/await will be a great tool for work that have a clearly defined start...