If you've worked with Combine in your applications you'll know what it means when I tell you that you should always retain your cancellables. Cancellables are an important part of working with Combine, similar to how disposables are an important part of working with RxSwift. Interestingly, Swift Concurrency's AsyncSequence operates without an equivalent to cancellable (with memory leaks as a result). That said, in this post we'll only focus on Combine.

For example, you might have built a publisher that wraps CLLocationManagerDelegate and exposes the user's current location with a currentLocation publisher that's a CurrentValueSubject<CLLocation, Never>. Subscribing to this publisher would look look a bit like this:

struct ViewModel {
    let locationProvider: LocationProvider
    var cancellables = Set<AnyCancellable>()

  init(locationProvider: LocationProvider) {
        self.locationProvider = locationProvider
        locationProvider.currentLocation.sink { newLocation in 
            // use newLocation
        }.store(in: &cancellables)
    }
}

For something that's so key to working with Combine, it kind of seems like cancellables are just something we deal with without really questioning it. Thats why in this post, I'd like to take a closer look at what a cancellable is, and more specifically, I'd like to look at what the enigmatic AnyCancellable that's returned by both sink and assign(to:on:) is exactly.

Understanding the purpose of cancellables in Combine

Cancellables in Combine fulfill an important part in Combine's subscription lifecycle. According to Apple, the Cancellable protocol is the following:

A protocol indicating that an activity or action supports cancellation.

Ok. That's not very useful. I mean, if supporting cancellation is all we want to do, why do we need to retain our cancellables?

If we look at the detailed description for Cancellable, you'll find that it says the following:

Calling cancel() frees up any allocated resources. It also stops side effects such as timers, network access, or disk I/O.

This still isn't great, but at least it's something. We know that an object that implements Cancellable has a cancel method that we can call to stop any in progress work. And more importantly, we know that we can expect any allocated resources to be freed up. That's really good to know.

What this doesn't really tell us is why we need to retain our cancellables in Combine. Based on the information that Apple provides there's nothing that even hints towards the need to retain cancellables.

Let's take a look at the documentation for AnyCancellable next. Maybe a Cancellable and AnyCancellable aren't quite the same even though we'd expect AnyCancellable to be nothing more than a type-erased Cancellable based on the way Apple chose to name it.

The short description explains the following:

A type-erasing cancellable object that executes a provided closure when canceled.

Ok. That's interesting. So rather it being "just" a type erased object that conforms to Cancellable, we can provide a closure to actually do something when we initialize an AnyCancellable. When we subscribe to a publisher we don't create our own AnyCancellable though, so we'll need to dig a little deeper.

There's once sentence in the AnyCancellable documentation that tells us exactly why we need to retain cancellables. It's the very last sentence in the discussion and it reads as follows:

An AnyCancellable instance automatically calls cancel() when deinitialized.

So what exactly does this tell us?

Whenever an AnyCancellable is deallocated, it will call cancel() on itself. This will run the provided closure that I mentioned earlier. It's safe to assume that this closure will ensure that any resources associated with our subscription are torn down. After all, that's what the cancel() method is supposed to do according to the Cancellable protocol.

Based on this, we can deduce that the purpose of cancellables in Combine, or rather the purpose of AnyCancellable in Combine is to associate the lifecycle of a Combine subscription to something other than the subscription completing.

When we retain a cancellable in an instance of a view model, view controller, or any other object, the lifecycle of that subscription becomes connected to that of the owner (the retaining object) itself. Whenever the owner of the cancellable is deallocated, the subscription is torn down and all resources are freed up immediately.

Note that this might not be quite intuitive when you think of that original description I quoted from the Cancellable documentation:

A protocol indicating that an activity or action supports cancellation.

Cancelling a subscription by calling cancel() on an AnyCancellable is not a graceful operation. This is already hinted at because the documentation for Cancellable mentions that "any allocated resources" will be freed up. You need to interpret this broadly.

You won't just cancel an in flight network call and be notified about it in a receiveCompletion closure. Instead, the entire subscription is torn down immediately. You will not be informed of this, and you will not be able to react to this in your receiveCompletion closure.

To sum up the purpose of cancellables in Combine, they are used to tie the lifecycle of a subscription to the object that retains the cancellable that we receive when we subscribe to a publisher.

This description might lead to you thinking that an AnyCancellable is a wrapper for a subscription. Unfortunately, that's not quite accurate. It's also not flat out wrong, but there's a bit of a nuance here; Apple chose the name AnyCancellable instead of Subscription on purpose.

What's inside an AnyCancellable exactly?

If an AnyCancellable isn't a subscription, then what it is? What's inside of an AnyCancellable?

The answer is complicated...

When I first learned Combine I was lucky enough to run into an Apple employee at a conference. We got talking about Combine, and I explained that I was working on a Combine book. I started firing off a few questions to validate my understanding of Combine and I was very lucky to get an answer or two.

One of my questions was "So is an AnyCancellable a subscription then?" and the answer was short and simple "No. It's an AnyCancellable".

You might think that's unhelpful, and I would fully understand. However, the answer is fully correct as I learned in our conversation and it makes Apple's intent with AnyCancellable perfectly clear.

Combine intentionally does not specify what's inside of AnyCancellable because we simply don't need to know exactly what is wrapped and how. All we need to know is that an AnyCancellable conforms to the Cancellable protocol, and when its cancel() method is called, all resources retained by whatever the Cancellable wrapper are released.

In practice, we know that an AnyCancellable will most likely wrap an object that conforms to Subscription and possibly also one that conforms to Subscriber. One of the two might even have a reference to a Publisher object.

We know this because we know that these three objects are always involved when you subscribe to a publisher. I've outlined this in more detail in this post as well as my Combine book.

This is really a long-winded way of me trying to tell you that we don't know what's inside an AnyCancellable, and it doesn't matter. You just need to remember that when an AnyCancellable is deallocated it will run its cancellation closure which will tear down anything it retains. This includes tearing down your subscription to a publisher.

If you're interested in learning about Swift Concurrency's AsyncSequence, and how it compares to publishers in Combine, I highly recommend that you start by looking at this post.

In Summary

In this post you learned about a key aspect of Combine; the Cancellable. I explained what the Cancellable protocol is, and from there I moved on to explain what the AnyCancellable is.

You learned that subscribing to a publisher with sink or assign(to:on:) will return an AnyCancellable that will tear down your subscription whenever the AnyCancellable is deallocated. This makes sure that your subscription to a publisher is deallocated when the object that retains your AnyCancellable is deallocated. This prevents your subscriptions from being deallocated immediately when the scope where they're created exits.

Lastly, I explained that we don't know what exactly is inside of the AnyCancellable objects that we retain for our subscriptions. While we can be pretty certain that an AnyCancellable must somehow retain a subscription, we shouldn't refer to it as a wrapper for a subscription because that would be inaccurate.

Hopefully this post gave you some extra insights into something that everybody that works with Combine has to deal with even though there's not a ton of information out there on AnyCancellable specifically.

One of my favorite concurrency problems to solve is building concurrency-proof token refresh flows. Refreshing authentication tokens is something that a lot of us deal with regularly, and doing it correctly can be a pretty challenging task. Especially when you want to make sure you only issue a single token refresh request even if multiple network calls encounter the need to refresh a token.

Furthermore, you want to make sure that you automatically retry a request that failed due to a token expiration after you've obtained a new (valid) authentication token.

I wrote about a flow that does this before, except that post covered token refreshes with Combine rather than async await.

In this post, we'll build the exact same flow, except it'll use Swift Concurrency rather than Combine.

Understanding the flow

Before I dive into the implementation details, I want to outline the requirements of the token refresh flow that we'll build. The following chart outlines the flow of the network object that I want to build in this post:

Whenever a network request is made, we ask an AuthManager object for a valid token. If a valid token was obtained, we can proceed with the network call. If no valid token was obtained we should present a login screen. When the request itself succeeds, we're all good and we'll return the result of the request. If the request fails due to a token error, we'll attempt to refresh the token. If the refresh succeeds, we'll retry the original request. If we couldn't refresh the token, an error is thrown. When the request is retried and it fails again we'll also throw an error even if the error is related to the token. Clearly something is wrong and it doesn't make sense to refresh and retry endlessly.

The AuthManager itself is pro-active about how it deals with tokens as shown in the following diagram:

When the AuthManager is asked for a valid token, we'll check if a token exists locally. If not, we'll throw an error. If it does exist, we check if the token is valid. If it isn't, a refresh is attempted so we can obtain a valid token. If this succeeds the valid token is returned. In cases where the token refresh fails we'll throw an error so the user can authenticate again.

This flow is complex enough as it is, but when we add the requirement that we should only have one request in progress at any given time, things can get a little hairy.

Luckily, Swift's concurrency features are incredibly helpful when building a flow like this.

We'll implement the AuthManager object first, and after that I'll show you how it can be used in the Network object.

Note that all of this is somewhat simplified from how you might structure things in the real world. For example, you should always store tokens in the keychain, and your objects are probably a lot more complex than the ones I'm working with in this post.

None of that changes the flow and principles of what I intend to describe, hence why I chose to go with a simplified representation because it allows you to focus on the relevant parts for this post.

Implementing the AuthManager

Because we want to make sure that our AuthManager handles concurrent calls to validToken() in such a way that we only have one refresh request in flight at any time, we should make it an actor. Actors ensure that their internal state is always accessed in a serial fashion rather than concurrently. This means that we can keep track of a currently in-flight token refresh call and check whether one exists safely as long as the manager is an actor.

If you want to learn more about Swift's actors and how they are used, I recommend you take a look at my post on actors before moving on with the implementation of AuthManager.

Now that we know we're going to make AuthManager an actor, and we already know that it needs a validToken() and a refreshToken() method, we can implement a starting point for the manager as follows:

actor AuthManager {
    private var currentToken: Token?
    private var refreshTask: Task<Token, Error>?

    func validToken() async throws -> Token {        

    }

    func refreshToken() async throws -> Token {

    }
}

This skeleton shouldn't be too surprising. Note that I'm storing the token as an instance variable on AuthManager. Do not do this in your own implementation. You should store the token in the user's Keychain, and read it from there when needed. I'm only storing it as an instance variable for convenience, not because it's good practice (because it's not).

Before we move on, I want to show you the error I might throw from within the AuthManager:

enum AuthError: Error {
    case missingToken
}

The validToken() implementation is probably the simplest implementation in this post, so let's look at that first:

func validToken() async throws -> Token {
    if let handle = refreshTask {
        return try await handle.value
    }

    guard let token = currentToken else {
        throw AuthError.missingToken
    }

    if token.isValid {
        return token
    }

    return try await refreshToken()
}

In this method, I cover four scenarios in the following order:

1. If we're currently refreshing a token, await the value for our refresh task to make sure we return the refreshed token.
2. We're not refreshing a token, and we don't have a persisted token. The user should log in. Note that you'd normally replace currentToken with reading the current token from the user's keychain.
3. We found a token, and we can reasonably assume the token is valid because we haven't reached the expiration threshold yet.
4. None of the above applies so we'll need to refresh the token.

I didn't define a network nor a keychain property in my skeleton because we won't be using them for the purposes of this post, but I can't stress enough that tokens should always be stored in the user's keychain and nowhere else.

Let's start building out the refreshToken() method next. We'll do this in two steps. First, we'll handle the case where refreshToken() is called concurrently multiple times:

func refreshToken() async throws -> Token {
    if let refreshTask = refreshTask {
        return try await refreshTask.value
    }

    // initiate a refresh...
}

Because AuthManager is an actor, this first step is relatively simple. Normally you might need a sync queue or a lock to make sure concurrent calls to refreshToken() don't cause data races on refreshTask. Actors don't have this issue because they make sure that their state is always accessed in a safe way.

We can return the result of our existing refresh task by awaiting and returning the task handle's value. We can await this value in multiple places which means that all concurrent calls to refreshToken() can (and will) await the same refresh task.

The next step is to initiate a new token refresh and store the refresh task on AuthManager. We'll also return the result of our new refresh task in this step:

func refreshToken() async throws -> Token {
    if let refreshTask = refreshTask {
        return try await refreshTask.value
    }

    let task = Task { () throws -> Token in
        defer { refreshTask = nil }

        // Normally you'd make a network call here. Could look like this:
        // return await networking.refreshToken(withRefreshToken: token.refreshToken)

        // I'm just generating a dummy token
        let tokenExpiresAt = Date().addingTimeInterval(10)
        let newToken = Token(validUntil: tokenExpiresAt, id: UUID())
        currentToken = newToken

        return newToken
    }

    self.refreshTask = task

    return try await task.value
}

In this code, I create a new Task instance so that we can store it in our AuthManager. This task can throw if refreshing the token fails, and it will update the current token when the refresh succeeds. I'm using defer to make sure that I always set my refreshTask to nil before completing the task. Note that I don't need to await access to refreshTask because this newly created Task will run on the AuthManager actor automatically due to the way Structured Concurrency works in Swift.

I assign the newly created task to my refreshTask property, and I await and return its value like I explained before showing you the code.

Even though our flow is relatively complex, it wasn't very complicated to implement this in a concurrency-proof way thanks to the way actors work in Swift.

If actors are still somewhat of a mystery to you after reading this, take a look at my post on actors to learn more.

As a next step, let's see how we can build the networking part of this flow by creating a Networking object that uses the AuthManager to obtain and refresh a valid access token and retry requests if needed.

Using the AuthManager in a Networking object

Now that we have a means of obtaining a valid token, we can use the AuthManager to add authorization to our network calls. Let's look at a skeleton of the Networking object so we have a nice starting point for the implementation:

class Networking {

    let authManager: AuthManager

    init(authManager: AuthManager) {
        self.authManager = authManager
    }

    func loadAuthorized<T: Decodable>(_ url: URL) async throws -> T {
        // we'll make the request here
    }

    private func authorizedRequest(from url: URL) async throws -> URLRequest {
        var urlRequest = URLRequest(url: url)
        let token = try await authManager.validToken()
        urlRequest.setValue("Bearer \(token.value)", forHTTPHeaderField: "Authorization")
        return urlRequest
    }
}

The code in this snippet is fairly straightforward. The Networking object depends on an AuthManager. I added a convenient function to create an authorized URLRequest from within the Networking class. We'll use this method in loadAuthorized to fetch data from an endpoint that requires authorization and we'll decode the fetched data into decodable model T. This method uses generics so we can use it to fetch decoded data from any URL that requires authorization.

If you're not familiar with generics, you can read more about them here and here.

Let's implement the happy path for our loadAuthorized method next:

func loadAuthorized<T: Decodable>(_ url: URL) async throws -> T {
    let request = try await authorizedRequest(from: url)
    let (data, _) = try await URLSession.shared.data(for: request)

    let decoder = JSONDecoder()
    let response = try decoder.decode(T.self, from: data)

    return response
}

This code should, again, be fairly straightfoward. First, I create an authorized URLRequest for the URL we need to load by calling authorizedRequest(from:). As you saw earlier, this method will ask the AuthManager for a valid token and configure an authorization header that contains an access token. We prefix the call to this method with try await because this operation can fail, and could require us to be suspended in the case that we need to perform a token refresh proactively.

If we can't authorize a request, this means that AuthManager's validToken method threw an error. This, in turn, means that we either don't have an access token at all, or we couldn't refresh our expired token. If this happens it makes sense for loadAuthorized to forward this error to its callers so they can present a login screen or handle the missing token in another appropriate way.

Next, I perform the URLRequest. A URLRequest can fail for various reason so this call needs to be prefixed with try as well. Any network related errors that get thrown from this line are forwarded to our caller.

Once we've obtained Data from the URLRequest we decode it into the appropriate type T and we return this decoded data to the caller.

Before we move on, please take a moment to appreciate how much more straightforward this code looks with async/await when compared to a traditional callback based approach or even a reactive approach that you might implement with RxSwift or Combine.

As it stands, we've implemented about half of the request flow. I've made the implemented steps green in the image below:

To implement the last couple of steps we need to make a small change to the signature of loadAuthorized so it can take an allowRetry argument that we'll use to limit our number of retries to a single retry. We'll also need to check whether the response we received from URLSession is an HTTP 401: Unauthorized response that would indicate we ran into an authorization error so we can explicitly refresh our token one time and retry the original request.

While this should not be a common situation to be in, it's entirely possible that we believe our persisted token is valid since the device clock is pretty far from the token's expiration date while the token is, in fact, expired. One reason is that all tokens in the back-end were manually set to be expired for security reasons. It's also possible that your user's device clock was changed (either by the user or by travelling through timezones) which led to our calculations being incorrect.

In any event, we'll want to attempt a token refresh and retry the request once if this happens.

Here's what the updated loadAuthorized method looks like:

func loadAuthorized<T: Decodable>(_ url: URL, allowRetry: Bool = true) async throws -> T {
    let request = try await authorizedRequest(from: url)
    let (data, urlResponse) = try await URLSession.shared.data(for: request)

    // check the http status code and refresh + retry if we received 401 Unauthorized
    if let httpResponse = urlResponse as? HTTPURLResponse, httpResponse.statusCode == 401 {
        if allowRetry {
            _ = try await authManager.refreshToken()
            return try await loadAuthorized(url, allowRetry: false)
        }

        throw AuthError.invalidToken
    }

    let decoder = JSONDecoder()
    let response = try decoder.decode(T.self, from: data)

    return response
}

These couple of lines of code that I added implement the last part of our flow. If we couldn't make the request due to a token error we'll refresh the token explicitly and we retry the request once. If we're not allowed to retry the request I throw an invalidToken error to signal that we've attempted to make a request with a token that we believe is valid yet we received an HTTP 401: Unauthorized.

Of course, this is a somewhat simplified approach. You might want to take the HTTP body for any non-200 response and decode it into an Error object that you throw from your loadAuthorized method instead of doing what I did here. The core principle of implementing a mechanism that will proactively refresh your auth tokens and authorize your network requests shouldn't change no matter how you decide to deal with specific status codes.

All in all, Swift Concurrency's actors combined with async/await allowed us to build a complex asynchronous flow by writing code that looks like it's imperative code while there's actually a ton of asynchronisity and even synchronization happening under the hood. Pretty cool, right?

In Summary

In this post, you saw how I implemented one of my favorite networking and concurrency related examples with async/await and actors. First, you learned what the flow we wanted to implement looks like. Next, I showed you how we can leverage Swift's actors to build a concurrency proof token provider that I called an AuthManager. No matter how many token related methods we call concurrently on this object, it will always make sure that we only have one refresh call in progress at any given time.

After that, you saw how you can leverage this AuthManager in a Networking object to authorize network calls and even explicitly refresh a token and retry the original request whenever we encounter an unexpected token related error.

Flows like these are a really nice way to experiment with, and learn about, Swift Concurrency features because they can be applied in the real world immediately, and they force you to mix and match different concurrency features so you'll immediately see how things fit together in the real world.

Earlier, I published a post on Swift Concurrency's task groups. If you haven't read that post yet, and you're not familiar with task groups, I recommend that you read that post first because I won't be explaining task groups in this post. Instead, you will learn about a technique that you can use to work around a limitation of task groups.

Task groups can run a number of child tasks where every child task in the task group produces the same output. This is a hard requirement of the withTaskGroup function. This means that task groups are not the right tool for every job. Sometimes it makes more sense to use async let instead.

In the post where I introduced task groups, I used an example where I needed to fetch a Movie object based on an array of UUIDs. Now let's imagine that our requirements aren't as clear, and we write a function where we receive an array of Descriptor objects that informs us about the type of objects we need to load.

These objects could be either a Movie, or a TVShow. Here's what the Descriptor looks like:

enum MediaType {
    case movie, tvShow
}

struct Descriptor {
    let id: UUID
    let type: MediaType
}

The implementation of Movie and TVShow aren't really relevant in this context. All you need to know is that they can both be loaded from a remote source based on a UUID.

Now let's take a look at the skeleton function that we'll work with:

func fetchMedia(descriptors: [Descriptor]) async -> ???? {
    return await withTaskGroup(of: ????) { group in 
        for descriptor in descriptor {
            group.addTask {
                // do work and return something
            }
        }
    }
}

Notice that I used ???? instead of an actual type for the function's return type and for the type of the task group. We'll need to figure out what we want to return.

One approach would be to create a Media base class and have Movie and TVShow subclass this object. That would work in this case, but it requires us to use classes where we might prefer structs, and it wouldn't work if the the fetched objects weren't so similar.

Instead, we can define an enum and use that as our task output and return type instead. Let's call it a TaskResult:

enum TaskResult {
    case movie(Movie)
    case tvShow(TVShow)
}

Now we can switch on the Descriptor's type, fetch our object, and return a TaskResult where the fetched media is an associated type of our enum case:

func fetchMedia(descriptors: [Descriptor]) async -> [TaskResult] {
    return await withTaskGroup(of: TaskResult.self) { group in 
        for descriptor in descriptor {
            group.addTask {
                switch descriptor.type {
                    case .movie:
                        let movie = await self.fetchMovie(id: descriptor.id)
                        return TaskResult.movie(movie)
                    case .tvShow:
                        let tvShow = await self.fetchShow(id: descriptor.id)
                        return TaskResult.tvShow(tvShow)
                }
            }
        }

        var results = [TaskResult]()

        for await result in group {
            results.append(result)
        }

        return results
    }
}

The nice thing about this approach is that it's easy to scale it into as many types as you need without the need to subclass. That said, I wouldn't recommend this approach in all cases. For example, if you're building a flow similar to the one I show in my post on async let, task groups wouldn't make a lot of sense.

In Summary

Ideally, you only use task groups when all tasks in the group really produce the same output. However, I'm sure there are situations where you need to run an unknown number of tasks based on some input like an array where the tasks don't always produce the same output. In those cases it makes sense to apply the workaround that I've demonstrated in this post.

In last week's post, I demonstrated how you can use a task group in Swift to concurrently run multiple tasks that produce the same output. This is useful when you're loading a bunch of images, or in any other case where you have a potentially undefined number of tasks to run, as long as you (somehow) make sure that every task in your group produces the same output.

Unfortunately, this isn't always a reasonable thing to do.

For example, you might already know that you only have a very limited, predetermined, number of tasks that you want to run. These tasks might not even produce the same output which could make matters more complicated.

In these scenarios, it makes sense to use Swift's async let syntax instead of a task group.

If you're not yet familiar with task groups, make sure you take a look at the following posts if you want to understand the complete picture of what we're covering in this post.

• Running tasks in parallel with Swift Concurrency's task groups
• Using Swift Concurrency's task group for tasks with varying output

In this post, you will learn when it makes sense to use async let, how it's used, and you'll learn how async let fits into the bigger picture of an application that uses Swift Concurrency.

Knowing when to use async let

In my post on using a task group for multiple tasks with varying output, you saw how you could wrap the output from a task in a task group in a TaskResult enum that we defined ourselves. While this is convenient when we don't know how many tasks we might have to run exactly in a task group, you can imagine that this isn't always desirable.

For this exact reason, the Swift core team gave us a convenient tool to concurrently run a predetermined number of tasks and awaiting their results only when we actually need them.

This allows you to perform work as soon as possible, but not await it if you don't need it right away.

Let's look at an example.

Imagine that you're implementing a bootstrapping sequence for a movies app. When this sequence is kicked off, you want to do a bunch of stuff. For example:

• Fetch movies from a server
• Asynchronously fetch the current user
• Load user's favorites
• Load user's profile
• Load user's movie tickets

Without async let, and without task groups, you might write something like this:

func bootstrapSequence() async throws {
    let movies = await loadMovies() // will cache movies as well
    if let user = await currentUser() {
        let favorites = try await updateFavorites(user: user)
        let profiles = await updateUserProfile(user: user)
        let tickets = await updateUserTickets(user: user)
    }

    // use properties or ignore their output as needed
}

This code will work fine, but there's a bit of an optimization problem here. The steps in our sequence are run serially rather than concurrently.

Notice that the movies and user tasks can run concurrently. They don't depend on each other in any way.

The other three tasks depend on both movies and user. Or rather, they depend on user but it would be nice if movies are loaded too.

I don't want to spend too much time on the details of what each of these functions do, but the rest of this post makes a lot more sense if I explain my intention behind them at least a little bit.

• loadMovies() -> [Movie] will load movies a list of movies from a remote source and cache them locally.
• currentUser() -> User will check if a user exists locally or attempts to fetch the user from the server. User object is a bare-bones container of user info.
• updateFavorites(user:) -> [Movie] loads a list of movie ids that the user marked as favorite from the server, and associates them with a Movie object. If the Movie is not cached it will be fetched from a server.
• updateUserProfile(user:) -> UserProfile fetches and caches the user's profile information from a server (contains a lot more info than the object returned by currentUser)
• updateUserTickets(user:) -> [Ticket] updates the user's movie tickets in the local store. Tickets are associated with Movie objects from the local cache. If a specific movie doesn't exist locally it's fetched from the server.

As you can see, each of these steps in the sequence does a bunch of stuff and we want to do as many of these things concurrently as possible.

This means that we can divide the sequence into two steps, or sections:

• Load movies and current user object
• Update favorites, profile, and tickets

With a task group this would be rather tedious because every task has a different result, and we'd need to split our group in two somehow, or we'd need to use two task groups. Not ideal, especially because we're not dealing with an indeterminate number of tasks.

Let's see how async let helps us solve this problem.

Using async let in your code

As I mentioned earlier, async let allows us to run tasks concurrenly without suspending the calling context to await the task's output so we can only await their results when we need them.

The simplest usage of an async let is when you want to run a task as soon as a function starts, but you don't want to await it immediately. Let's take a look at an example of this before we go back to the more complex scenario I explained in the previous section.

Imagine that you're writing a function where you want to load some information from the network to update a local record, and while that happens you want to see if a local record exists so you know whether you'll need to create a new record. The network code will run asynchronously using async let so we can fetch the most up to date information from the server while checking our local store at the same time:

func fetchUserProfile(user: User) async -> UserProfile {
    // start fetching profile from server immediately
    async let remoteProfile = network.fetchUserProfile(user: user)

    // fetch (or create) and await local profile
    let localProfile = await localStore.fetchUserProfile(user: user)

    // update local profile with remote profile
    await localProfile.update(with: remoteProfile)
    await localStore.persist(localProfile)

    return localProfile
}

In this code, the network call is executed immediately and it will start running right away.

While this network call is executing, we'll attempt to load a user profile from the local cache which could take a little while too depending on what we're using to store the profile. The exact details of this aren't relevant for now.

Once we've obtained a local profile, we call await localProfile.update(with: remoteProfile). At this point, we want to wait for the profile that we loaded from the network and use it to update and persist the local version.

The network call might have already completed by the time we use await to wait for its result, but it could also still be in-flight. The nice part is that the network call runs concurrent with the rest of fetchUserProfile and we don't suspend fetchUserProfile until we don't have any other choice. In other words, we were able to do two things concurrently in fetchUserProfile (perform network call, and find the cached user profile) by using async let.

When you think about the flow I showed you in the previous section for example, we'll want to run loadMovies() and currentUser() concurrently, await their results, and then proceed with the next steps in our bootstrapping sequence.

Here's what this first part of the sequence would look like:

func bootstrapSequence() async throws {
    async let moviesTask = loadMovies()
    async let userTask = currentUser()

    let (_, currentUser) = await (moviesTask, userTask)

    // we'll implement the rest of the sequence soon
}

In this code, I create two tasks with the async let syntax. This essentially tells Swift to start running the function call that follows it immediately, without awaiting their results. You can have multiple of these async let tasks running at the same time simply by defining them one after the other like I did in the code snippet above.

Earlier, you saw that I needed to await remoteProfile to get the result of my async let remoteProfile. In this case, I want to await two tasks. I want to ignore the output of loadMovies() while assigning the output of currentUser() to a property that I can use later.

As you saw earlier, it's possible to use the output of an async let task inline by writing await before the expression that uses the task's output. For example, I could write the following to use the output of currentUser() without assigning the output to an intermediate property:

async let user = currentUser()
let tickets = await updateUserTickets(user: user)

The code above would await the value of user (which would be the output of currentUser()), and then run and await updateUserTickets(user:). This is very similar to how try works in Swift where you only need to write a single try to apply it to an entire expression even if it contains multiple throwing statements. For clarity, I'm going to keep using the approach you saw earlier where I explicitly awaited the result of a property called userTask.

Once the user and movies are loaded, we can concurrently run the second part of the sequence:

func bootstrapSequence() async throws {
    async let moviesTask = loadMovies()
    async let userTask = currentUser()

    let (_, currentUser) = await (moviesTask, userTask)

    guard let user = currentUser else {
        return
    }

    async let favoritesTask = updateFavorites(user: user)
    async let profilesTask = updateUserProfile(user: user)
    async let ticketsTask = updateUserTickets(user: user)

    let (favorites, profile, tickets) = try await (favoritesTask, profileTask, ticketsTask)

    // use the loaded data as needed
}

Notice how this follows the exact same pattern that you saw before. I define some aysnc let properties to create a bunch of tasks that will run concurrently as soon as they are created, and I use await to wait for their results.

Note that this time around, I had to write try await. That's because updateFavorites can throw. I applied the try to the entire expression because I think it reads a bit nicer and it makes it easier to change other tasks to be throwing later. It would have been equally valid for me to write the following:

let (favorites, profile, tickets) = await (try favoritesTask, profileTask, ticketsTask)

Which, in my opinion, just doesn't read as nicely as the version I showed you earlier.

In terms of usage, there really isn't much else to async let. You defined tasks with async let, they begin doing their work as soon as they are created, and you must use await whenever you want to use the async let task's value.

I love how easy to use this API is, and how it allows us to build relatively complex sequences and flows without a ton of effort. As an exercise, take a look at this post I wrote on running some tasks concurrently waiting for all tasks to be completed using DispatchGroup. You'll see that it's not nearly as nice and convenient as Swift Concurreny's async let.

While async let is easy to use, there's a lot going on behind the scenes to make it work. And there are some important rules you should understand. Let's explore those next.

Understanding how async let works

When you create an async let, you spawn a new Swift Concurrency task behind the scenes. This task will run as a child of the task that's currently running (ever async scope in Swift Concurrency is part of a task). This new task will inherit things like task local values, and it will run on the same actor as the actor that you spawned the task from.

It's important to understand this because it will help you reason about what's happening behind the scenes when you use async let since it's subtly different from calling an async function and using await to wait for the function's result.

When you normally await an async function's output, this is all done as part of the same task. Since async let will run concurrently with the function that you used it in, it'll be run in a new task. This means that, similar to how you spawn tasks in a task group, you spawn a new task every time you write async let.

With this in mind, it's important to think about what might happen when you spawn a task with async let without ever awaiting its result. For example:

func bootstrapSequence() async throws {
    async let moviesTask = loadMovies()
    async let userTask = currentUser()

    let (_, currentUser) = await (moviesTask, userTask)

    guard let user = currentUser else {
        return
    }

    async let favoritesTask = updateFavorites(user: user)
    async let profilesTask = updateUserProfile(user: user)
    async let ticketsTask = updateUserTickets(user: user)

    // we don't await any of the async let's above
}

Since we don't await the results of our async let tasks, the bootstrapSequence function will exit after the last async let task is started. When this happens, our tasks will go out of scope, and they get marked as cancelled which means that we should stop performing any work as soon as we can to respect Swift Concurrency's cooperative cancellation paradigm.

In other words, you should not use an async let as a means to run code asynchronously after your function has exitted its scope.

The last thing I want to cover in this post is the restriction of applying async only to let properties.

You can't write async var to have an asynchronous variable. The reason is that your created property will be bound to a task, and its value doesn't become available until it's awaited and the task produces a result. If you would be able to write async var this feature would become increasingly complex because of how the binding from task to property works.

In Summary

In this post you learned a lot about Swift Concurrency's async let. You learned that async let is a feature that helps you run unrelated asynchronous function calls concurrently as their own tasks. You learned that async let solves a propblem that's similar to the problem that's solved by task groups except it doesn't have the limitation of only being applicable for tasks that produce the same output.

I showed you how you can use async let to build a complex loading sequence that can run in two steps. The first step performs two concurrenct tasks, and the second step runs three concurrent tasks that depend on the first two tasks. You saw that this was fairly trivial to implement with async let and awaiting results where needed.

Lastly you gained some deeper insights into how async let works. You learned that an async let creates a child task of your current task under the hood, and you learned that this task is cancelled whwnever the function it's created in goes out of scope. To avoid this, you should always await the results of your async let tasks.

Overall I think async let is an incredibly useful feature for scenarios where you want to run several tasks concurrently before doing something else. A bootstrapping process like you saw in this post is a good example of that.

With Apple's overhaul of how concurrency will work in Swift 5.5 and newer, we need to learn a lot of things from scratch. While we might have used DispatchQueue.async or other mechanisms to kick off multiple asynchronous tasks in the past, we shouldn't use these older concurrency tools in Swift's new concurrency model.

Luckily, Swift Concurrency comes with many features already which means that for a lot of our old uses cases, a new paradigm exists.

In this post, you will learn what Swift Concurrency's task groups are, and how you can use them to concurrently perform a lot of work.

Which problem does TaskGroup solve?

Before I show you how you can use a task group, I'd like to explain when a task group is most likely the correct tool for your job. Or rather, I'd like to explain the problem that task groups were designed to solve.

Consider the following example.

Let's say that you fetched a list of ids from your server. These ids represent the ids of movies that your user has marked as a favorite. By returning ids instead of full-blown movie objects, your user can save a lot of data, assuming that clients can (and will) cache movie objects locally. This allows you to either look up a movie in your local cache, or to fetch the movie from the server if needed.

The code to fetch these movie ids might look a bit like this:

func getFavoriteIds(for user: User) async -> [UUID] {
    return await network.fetchUserFavorites(for: user)
}

func fetchFavorites(user: User) async -> [Movie] {
    // fetch Ids for favorites from a remote source
    let ids = await getFavoriteIds(for: user)

    // perform work to obtain `[Movie]`
}

So far so good. If you're somewhat familiar with Swift Concurrency's async/await concept this code shouldn't look too scary.

Now that we have an array of UUID, we need to somehow convert this array to Movie objects. In this case, I don't care about the order of the ids and the resulting movies matching. And I don't want to fetch movies one by one because that might take a while.

I'd like to fetch as many movies at the same time as I possibly can.

This sentence above is essentially the key to knowing when we should use a task group.

In this case, I want to run a variable number of tasks concurrently, and every task produces the same type of output. This use case is exactly what task groups are good at. They allow you to spawn as many tasks as you want, and all of these tasks will run concurrently. One constraint is that every task must produce the same output. In this case, that's not a problem. We want to convert from UUID to Movie every time, which means that our task will always produce the same output.

Let's take a look at an example.

Using a TaskGroup in your code

Task groups can either be throwing or non-throwing. This might sound obvious, but the (non-)throwing nature of your task group has to be defined when you create it. In this case, I'm going to use a non-throwing task group. Let's see how a task group can be created.

Defining a task group

A task group can be created as follows:

await withTaskGroup(of: Movie.self) { group in

}

The withTaskGroup function is a global function in Swift that takes two arguments. The first argument specifies the type of result that your tasks produce. If your tasks don't have any output, you would write Void.self here since that would be the return type for each individual task. In this case, it's Movie.self because all tasks will produce a Movie instance.

If the tasks in a task group can throw errors, you should use withThrowingTaskGroup instead of withTaskGroup.

The second argument is a closure in which we'll schedule and handle all of our tasks. This closure receives an instance of TaskGroup<Output> as its only argument. The Output generic will correspond with your task output. So in this case the actual type would be TaskGroup<Movie>.

The withTaskGroup function is marked async which means that need to await its result. In this case, we don't return anything from the closure that we pass to withTaskGroup. If we did return something, the returned object would be the return value for the call to withTaskGroup and we could assign this output to a property or return it from a function.

In this case, we'll want to return something from fetchFavorites. Here's what that looks like:

func fetchFavorites(user: User) async -> [Movie] {
    // fetch Ids for favorites from a remote source
    let ids = await getFavoriteIds(for: user)

    // load all movies concurrently
    return await withTaskGroup(of: Movie.self) { group in
        var movies = [Movie]()

        // obtain movies

        return movies
    }
}

While this code compiles just fine, it's not very useful. Let's add some tasks to our task group so we can fetch movies.

Adding tasks to a TaskGroup

The TaskGroup object that is passed to our closure is used to schedule tasks in the group, and also to obtain the results of these tasks if needed. Let's see how we can add tasks to the group first, and after that I'll show you how you can obtain the results of your tasks by iterating over the group's results.

To load movies, we'll call the following async function from a new task. This function would be defined alongside fetchFavorites and getFavoriteIds:

func getMovie(withId id: UUID) async -> Movie {
    return await network.fetchMovie(withId: id)
}

To call this function from within a new task in the task group, we need to call addTask on the TaskGroup as follows:

func fetchFavorites(user: User) async -> [Movie] {
    // fetch Ids for favorites from a remote source
    let ids = await getFavoriteIds(for: user)

    // load all movies concurrently
    return await withTaskGroup(of: Movie.self) { group in
        var movies = [Movie]()

        // adding tasks to the group and fetching movies
        for id in ids {
            group.addTask {
                return await self.getMovie(withId: id)
            }
        }

        return movies
    }
}

I added a for loop to the task group closure to iterate over the ids that were fetched. For every fetched id I call group.addTask and pass it a closure that contains my task. This closure is async which means that we can await the result of some function call. In this case I want to await and return the result of self.getMovie. Note that I don't need to capture self weakly in the closure I pass to addTask. The reason for this is that the task I created can never outlive the scope it's defined in (more on that later), this means that no retain cycles are created here. The Swift compiler guarantees that our tasks don't outlive the scope they're defined in so we can be absolutely sure that our tasks don't create retain cycles.

Every task that's added to the task group with group.addTask must return a Movie instance because that's the task output type that we passed to withTaskGroup. As soon as a task is added to the task group it will beginning running concurrently with any other tasks that I may have already added to the group.

You might notice that while I add a bunch of tasks to the group, I never actually await or return the output of my tasks. To do this, we need to iterate asynchronously over the task group and obtain the results of its tasks. The TaskGroup object conforms to AsyncSequence which means that we can iterate over it using for await as follows:

func fetchFavorites(user: User) async -> [Movie] {
    // fetch Ids for favorites from a remote source
    let ids = await getFavoriteIds(for: user)

    // load all favorites concurrently
    return await withTaskGroup(of: Movie.self) { group in
        var movies = [Movie]()
        movies.reserveCapacity(ids.count)

        // adding tasks to the group and fetching movies
        for id in ids {
            group.addTask {
                return await self.getMovie(withId: id)
            }
        }

        // grab movies as their tasks complete, and append them to the `movies` array
        for await movie in group {
            movies.append(movie)
        }

        return movies
    }
}

By using for await movie in group the task group will provide us with movies as soon as they are obtained. Note that the results will be gathered in completion order. In other words, whichever movie is fully fetched first, will be returned first. The order in which we added tasks to the group does not necessarily matter. Although for very small/quick tasks it may happen that completion order can be the same as the order in which we added the tasks but this is never guaranteed. This is why I mentioned I didn't care about ordering earlier.

Whenever a task completes, the group provides us with the task output, and we can append this output to the movies array. Once all tasks are completed and we have appended all output to the movies array, we return this array from our task group closure.

This means that we can return the result of awaiting withTaskGroup from fetchFavorites since the output is an array of movies.

Note that we don't return from the closure that's provided to withTaskGroup until all tasks have completed due to the asynchronous for loop. This loop doesn't complete until all tasks in the group complete, and all output has been provided to us. Of course, we could exit our loop early with a break just like you can in a normal loop.

The example you've seen so far follows a pretty happy path. Let's consider two additional situations, in which we'll have to deal with errors thrown by the tasks that were added to the group:

1. One of the tasks throws an error
2. The task group is cancelled

TaskGroups and throwing tasks

I already mentioned that a task group for tasks that can throw should be created with withThrowingTaskGroup. We'd need to do this if the getMovie function you saw earlier could throw an error. If it could, it would look like this:

func getMovie(withId id: UUID) async throws -> Movie {
    return try await network.fetchMovie(withId: id)
}

The code to fetch a user's favorite movies would in turn be updated as follows:

func fetchFavorites(user: User) async throws -> [Movie] {
    // fetch ids for favorites from a remote source
    let ids = await getFavoriteIds(for: user)

    // load all favorites concurrently
    return try await withThrowingTaskGroup(of: Movie.self) { group in
        var movies = [Movie]()
        movies.reserveCapacity(ids.count)

        // adding tasks to the group and fetching movies
        for id in ids {
            group.addTask {
                return try await self.getMovie(withId: id)
            }
        }

        // grab movies as their tasks complete, and append them to the `movies` array
        for try await movie in group {
            movies.append(movie)
        }

        return movies
    }
}

The changes we needed to make to handle throwing tasks are relatively small. All I had to do was to add try where appropriate, and use withThrowingTaskGroup instead of withTaskGroup. However, there's a huge difference here in terms of what might happen.

In this example, I'm fetching movies by calling try await self.getMovie(withId: id). This means that the getMovie operation might throw an error. When it does, it's not a big deal per se. A task can fail without impacting any of the other tasks in the task group. This means that failing to load one of the movie does not necessarily impact the other tasks in my task group. However, because I iterate over the fetched movies using for try await movie in group, a single failure does impact other tasks in my group.

As we iterate over the group's results, a failed task also counts as a result. However, when the group's next() function is called internally to obtain the next result, it will throw the error that was thrown by the failing task so we can inspect and handle it if needed. In a for loop, I can only write try await which means that when the group throws an error from its next() function, this error is thrown out from the withThrowingTaskGroup closure since we don't handle (or ignore) it.

When an error is thrown from the closure provided to withThrowingTaskGroup, the task group will fail with that error. Before this error is thrown, the task group will mark any unfinished tasks as cancelled to allow them to stop executing work as soon as possible in order to comply with Swift Concurrency's cooperative cancellation. Once all tasks have completed (either by finishing their work or throwing an error), the task group will throw its error and complete.

In the example we're working with here, we can prevent a single failure from cancelling all in progress work. The solution would be to make sure the closure I pass to addTask doesn't throw. I could handle the errors thrown by getMovie and return some kind of default movie which probably isn't the best solution, or I could return nil. If returning nil is reasonable for your use case, you could also write try? await self.getMovie(withId: id) to ignore the error and return nil instead of handling the error in a do {} catch {} block.

Depending on how the tasks you add to your task group were written, cancelling one of your tasks might have a similar effect. In Swift Concurrency, it's perfectly acceptable to throw an error from a task when it's cancelled. This means that if your task throws a cancellation error, it could propagate through your task group in the exact same way that other thrown errors propagate through your task group if it ends up being thrown out of your withThrowingTaskGroup closure.

The bottom line here is that individual tasks throwing errors do not impact the task group and its enclosing task per se. It's only when this error ends up being thrown from your withThrowingTaskGroup closure that all unfinished tasks get cancelled, and the original error is thrown from the task group's task once all child tasks have finished. All this talk about errors and completing the task group's task segues nicely into the last topic I want to cover; the lifecycle of your task group's tasks.

Understanding the lifecycle of tasks in a TaskGroup

When you add tasks in a task group, you enter into a very important (explicit) contract. Swift's concurrency mechanisms are structured (pun intended) around the concept of Structured Concurrency. Async lets as well as task group child tasks both adhere to this idea.

The core idea behind structured concurrency is that a task cannot outlive the scope of its parent task. And similarily, no TaskGroup child task may outlive the scope of the withTaskGroup closure. This is achieved by implicitly awaiting on all tasks to complete before returning from the closure you pass to withTaskGroup.

When you know that tasks in a group cannot outlive the group they belong to, the error throwing / cancellation strategy I outlined above makes a lot of sense.

Once the task that manages the group throws an error, the scope of the task group has completed. If we still have running tasks at that time, the tasks would outlive their group which isn't allowed. For that reason, the task group will first wait for all of its tasks to either complete or throw a cancellation error before throwing its own error and exitting its scope.

When thinking of the code you've seen in this post, I've awaited the results of all child tasks explicitly by iterating over the group. This means that by the time we hit return movies all tasks are done already and no extra waiting is needed.

However, we don't have to await the output of our tasks in all cases. Let's say we have a bunch of tasks that don't return anything. We'd only write the following:

print("Before task group")
await withTaskGroup(of: Void.self) { group in
    for item in list {
        group.addTask {
            await doSomething()
            print("Task completed")
        }
    }
    print("For loop completed")
}
print("After task group")

Like I explained earlier, the task group's child tasks are always implicitly awaited before exitting the closure in which they were created in order to comply with the requirements of structured concurrency. This means that even if we don't await the result of our tasks, the tasks are guaranteed to be completed when we exit the withTaskGroup closure.

I've added some prints to the code snippet before to help you see this principle in action. When I run the code above, the output would look a bit like this:

print("Before task group")
print("For loop completed")
print("Task completed")
print("Task completed")
print("Task completed")
print("After task group")

The reason for that is the implicit awaiting of tasks in a group I just mentioned. The task group is not allowed to complete before all of the tasks it manages have also completed.

In Summary

In this post you learned a lot. You learned that tasks groups are a tool to concurrently perform an arbitrary number of tasks that produce the same output. I showed you how you can write a basic task group to concurrently fetch an arbitrary number of movies based on their ids as an example. You learned that task groups will run as many tasks at once as possible, and that you can obtain the results of these tasks using an async for loop.

After that, I explained how errors and cancellation work within a task group. You learned that whenever a task throws an error you can either handle or ignore this error. You also saw that if you throw an error from your task group closure, this will cause all unfinished tasks in the group to be marked as cancelled, and you learned that the original error will be thrown from task group once all tasks have completed.

Lastly, I explained how tasks within a task group cannot outlive the task group due to the guarantees made by Swift Concurrency, and that a task group will implicitly await all of its child tasks before completing to make sure none of its tasks are still running by the time the task group completes.

Huge thanks to Konrad for reviewing this post and providing some important corrections surrounding errors and cancellation.

This post applies to the version of SwiftUI that shipped with iOS 15, also known as Swift 3. To learn how you can present a bottom sheet on iOS 16 and newer, take a look at this post.

With iOS 15, Apple introduced the ability to easily implement a bottom sheet with UISheetPresentationController in UIKit. Unfortunately, Apple didn't extend this functionality to SwiftUI just yet (I'm hoping one of the iOS 15 betas adds this...) but luckily we can make use of UIHostingController and UIViewRepresentable to work around this limitation and use a bottom sheet on SwiftUI.

In this post, I will show you a very simple implementation that might not have everything you need. After I tweeted about this hacky little workaround, someone suggested this very nice GitHub repository from Adam Foot that works roughly the same but with a much nicer interface. This post's goal is not to show you the best possible implementation of this idea, the repository I linked does a good job of that. Instead, I'd like to explain the underlying ideas and principles that make this work.

The underlying idea

When I realized it wasn't possible to present a bottom sheet in SwiftUI with the new UISheetPresentationController I started wondering if there was some way around this. I know that there are some issues with presenting a CloudKit sharing controller from SwiftUI as well, and a popular workaround is to have a UIButton in your view that presents the sharing controller.

While not strictly needed to make the bottom sheet work (as shown by the repository linked in the intro), I figured I would follow a similar pattern. That way I would be able to create a UIViewController and present it on top of the view that the button is presented in. The nice thing about that over how Adam Foot implemented his bottom sheet is that we can use the button's window to present the popover. Doing this will ensure that our view is always presented in the correct window if your app supports multiple windows. The cost is that, unfortunately, our API will not feel very at home in SwiftUI.

I figured that's ok for this writeup. If you want to see an implementation with a nicer API, look at what Adam Foot did in his implementation. The purpose of this post is mostly to explain how and why this works rather than providing you with the absolute best drop-in version of a bottom sheet for SwiftUI.

Implementing the BottomSheetPresenter

As I mentioned, a useful method to present a UICloudSharingController in SwiftUI is to present a UIButton that will in turn present the sharing controller. The reason this is needed is because, for some reason, presenting the sharing controller directly does not work. I don't fully understand why, but that's way beyond the scope of this post (and maybe a good topic for another post once I figure it out).

We'll follow this pattern for the proof of concept we're building in this post because it'll allow me to present the bottom sheet on the current window rather than any window. The components involved will be a BottomSheetPresenter which is a UIViewRepresentable that shows my button, and a BottomSheetWrapperController that puts a SwiftUI view in a view controller that I'll present.

Let's implement the presenter first. I'll use the following skeleton:

struct BottomSheetPresenter<Content>: UIViewRepresentable where Content: View{
    let label: String
    let content: Content
    let detents: [UISheetPresentationController.Detent]

    init(_ label: String, detents: [UISheetPresentationController.Detent], @ViewBuilder content: () -> Content) {
        self.label = label
        self.content = content()
        self.detents = detents
    }

    func makeUIView(context: UIViewRepresentableContext<BottomSheetPresenter>) -> UIButton {
        let button = UIButton(type: .system)

        // configure button

        return button
    }

    func updateUIView(_ uiView: UIButton, context: Context) {
        // no updates
    }

    func makeCoordinator() -> Void {
        return ()
    }
}

The bottom sheet presenter initializer takes three arguments, a label for the button, the detents (steps) that we want to use in our UISheetPresentationController, and the content that should be shown in the presented view controller.

Note that I had to make my BottomSheetPresenter generic over Content so it can take a @ViewBuilder that generates a View for the presented view controller. We can't use View as the return type for the @ViewBuilder because View has a Self requirement which means it can only be used as a generic constraint.

Tip:
To learn more about generics, associated types, and generic constraints take a look at this post. For an introduction to generics you might want to read this post first.

The BottomSheetPresenter is a UIViewRepresentable struct which means that it can be used to present a UIKit view in a SwiftUI context.

The makeUIView method is used to create and configure our UIButton. We don't need any extra information so the makeCoordinator method returns Void, and the updateUIView method can remain empty because we're not going to update our view (we don't need to).

Let's fill in the makeUIView method:

func makeUIView(context: UIViewRepresentableContext<BottomSheetPresenter>) -> UIButton {
    let button = UIButton(type: .system)
    button.setTitle(label, for: .normal)
    button.addAction(UIAction { _ in
        let hostingController = UIHostingController(rootView: content)
        let viewController = BottomSheetWrapperController(detents: detents)

        viewController.addChild(hostingController)
        viewController.view.addSubview(hostingController.view)
        hostingController.view.pinToEdgesOf(viewController.view)
        hostingController.didMove(toParent: viewController)

        button.window?.rootViewController?.present(viewController, animated: true)
    }, for: .touchUpInside)

    return button
}

The implementation for makeUIView is pretty straightforward. We assign the button's title and add an action for touch up inside.

When the user taps this button, we create an instance of UIHostingController to present a SwiftUI view in a UIKit context, and we pass it the content that was created by the initializer's @ViewBuilder closure. After that, we create an instance of BottomSheetWrapperController. This view controller will receive the UIHostingController as its child view controller, and it's the view controller we'll present. We need this extra view controller so we can override its viewDidLoad and configure the detents for its presentationController (remember how we presented a bottom sheet in UIKit?).

The following lines of code add the hosting controller as a child of the wrapper controller, and I set up the constraints using a convenient method that I added as an extension to UIView. The pinToEdgesOf(_:) function I added in my UIView extension configures my view for autolayout and it pins all edges to the view that's passed as the argument.

Once all setup is done, I present my wrapper controller on the button's window. This will make sure that this implementation works well in applications that support multiple windows.

Lastly, I return the button so that it can be presented in my SwiftUI view.

Before we look at the SwiftUI view, let's look at the implementation for BottomSheetWrapperController.

Implementing the BottomSheetWrapperController

The implementation for the BottomSheetWrapperController class is pretty straightforward. It has a custom initializer so we can accept the array of detents from the BottomSheetPresenter, and in viewDidLoad we check if we're being presented by a UISheetPresentationController. If we are, we assign the detents and set the grabber to be visible.

Note that you might want to make the grabber's visibility configurable by making it an argument for the initializer and storing the preference as a property on the wrapper.

class BottomSheetWrapperController: UIViewController {
    let detents: [UISheetPresentationController.Detent]

    init(detents: [UISheetPresentationController.Detent]) {
        self.detents = detents
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) {
        fatalError("No Storyboards")
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        if let sheetController = self.presentationController as? UISheetPresentationController {
            sheetController.detents = detents
            sheetController.prefersGrabberVisible = true
        }
    }
}

I'm not going to go into the details of how this view controller works in this post. Please refer to the UIKit version of this post if you want to know more (it's very short).

Using the BottomSheetPresenter in SwiftUI

Now that we have everything set up, let's take a look at how the BottomSheetPresenter can be used in a SwiftUI view:

struct ContentView: View {
    var body: some View {
        BottomSheetPresenter("Tap me for a bottom sheet!!", detents: [.medium(), .large()]) {
            VStack {
                Text("This is a test")
                Text("Pretty cool, right")
            }
        }
    }
}

That doesn't look bad at all, right? We create an instance of BottomSheetPresenter, we assign it a label, pass the detents we want to use and we use regular SwiftUI syntax to build the contents of our bottom sheet.

I agree, it doesn't feel very at home and it would be nicer to configure the bottom sheet with a view modifier. This is exactly what Adam Foot implemented in his version of BottomSheet. The only downside to that version is that it grabs the first window it can find to present the sheet. This means that it wouldn't work well in an application with multiple windows. Other than that, I really like his custom SwiftUI modifier, and I would recommend you take a look at the implementation if you're curious.

You'll find that it's very similar to what you learned in this post, except it has a bunch more configuration that I didn't include during my exploration to see if I could get this bottom sheet to work.

Keep in mind, this post isn't intended to show you the ultimate way of achieving this. My goal is to help you see how I got to my version of using UISheetPresentationController in SwiftUI through experimentation, and applying what I know from presenting a UICloudSharingController in SwiftUI.

We've seen bottom sheets in Apple's apps for a while now, and plenty of apps have followed this pattern. If you're not sure what I mean, it's the kind of sheet that takes up just a part of the screen and can be swiped upwards to take up the whole screen or downwards to be dismissed. Here's an example from Apple's Maps app:

To implement a sheet like this, we used to require third party tools, or we needed to get creative and implement this pattern ourselves.

With iOS 15, Apple introduced UISheetPresentationController which allows us to implement bottom sheets with just a few lines of code.

When you present a view controller as shown below, you know that your presented view controller will be shown as a "card" on top of the presenting view controller:

present(targetViewController, animated: true)

By default, the user can already swipe the presented view controller down to dismiss it interactively.

A view controller that is presented with present(_:animated:) on iOS 15 will have a UISheetPresentationController set as its presentation controller automatically. This presentation controller is responsible for managing the transition between the presented and the presenting view controller, and it handles interaction like interactive dismissal.

It also handles the bottom sheet behavior that we want to implement. So that our view controller will first take up half the screen, and then can be expanded to full height and back down again.

To implement this, you use so called detents. These detents are set on the UISheetPresentationController and will be used to determine how the view controller can be shown. We can choose between medium, large, or both. Using only a medium detent will make your presented view controller take up roughly half the height of the screen. A large detent is the default and it makes the presented view controller its full height. Using both will allow the user to swipe between medium and large.

Here's how you set the UISheetPresentationController's detents:

override func viewDidLoad() {
    super.viewDidLoad()

    if let sheetController = self.presentationController as? UISheetPresentationController {
        sheetController.detents = [.medium(), .large()]
    }
}

You simply check if the view controller's presentation controller is an instance of UISheetPresentationController, and if it is you assign its detents.

Apple's Maps implementation shows a nice grabber that indicates to users that they can drag the bottom sheet up or down. This grabber isn't shown by default so you'll need to enable it manually if you want it to be shown:

sheetController.prefersGrabberVisible = true

This new feature is very nice, and I love how easy Apple has made it to implement a bottom sheet in iOS 15.

Unfortunately, we can't (easily) use this feature in SwiftUI. But if you're interested in a workaround... I have one for you right here.

If you've been following along with Swift Concurrency in the past few weeks, you might have come across the term "task local values". Task local values are, like the name suggests, values that are scoped to a certain task. These values are only available within the context they're scoped to, and they are really only supposed to be used in a handful of use cases.

In this post, I will explain what task local are, and more importantly I will explain how and when they are useful. For a full rundown of task local values and their design I'd like to refer you to SE-0311: Task Local Values.

Understanding what task local values are

Task local values are a way to associate some state with a Swift Concurrency Task, or rather a specific context within a Task. We can create a scope for a task local value to live in, even if we're already in a task (or a child task). This doesn't quite explain what a task local value is, and to really understand this we need to zoom out a little bit. If we don't, this entire feature will be really hard to understand.

When you create a new Task in Swift Concurrency, either through Task.init (formerly async), or Task.detached (formerly detach), this task will have a priority property and an isCancelled property. We can read these values by obtaining and inspecting the current task:

withUnsafeCurrentTask { task in
    print(task?.isCancelled)
    print(task?.priority)
}

The withUnsafeCurrentTask checks if the context we're currently in runs as part of a Task instance, and if it does, the "current" task (the task that we're part of) is provided to the closure. We can then read the isCancelled property to check if the current task is cancelled, allowing is to act accordingly.

You can imagine that writing this code everywhere would be tedious, so the Swift team provided a more convenient way to check if the current task is cancelled: Task.isCancelled. This static member on Task will obtain the current task for us, and it will return that task's cancellation status (or false if no current task exists). Here's what that static variable looks like:

extension Task {
    static var isCancelled: Bool {
        return withUnsafeCurrentTask { task in
            return task?.isCancelled ?? false
        }
    }
}

This static isCancelled property is not quite the same as a task local value, but it's close enough to proceed with understanding what they are. Remember that Task.isCancelled is a regular static property that returns a different value depending on which task it's accessed from.

With task local values, we can achieve a similar feature that allows us to associate metadata about a task with a task. We can do this by annotating a static property with the @TaskLocal property wrapper. This property wrapper will make sure that the given static property's value is only assigned within the scope of a given task.

Let's see what this looks like:

enum Transaction {
    @TaskLocal static var id: UUID? = nil
}

This enum has a task local id that can be used to identify a transaction in our system. I'll explain what this can be used for later. I want to explain task locals a little bit more before I show you how to use them.

My task local value has a default value of nil. This default value is the value that I'll get when I try to read the transaction id from a task that does not explicitly have its Transaction.id set. Note that after I assign a default value to my id, I can not change it:

Transaction.id = UUID() // Cannot assign to property: 'id' is a get-only property

To assign a task local value, we need to call a method on $id as follows:

await Transaction.$id.withValue(UUID()) {
    print(Transaction.id)
}

The withValue(_:operation:) method creates a scope where Transaction.id will have the provided value as its value. This works very similar to how Task.isCancelled is implemented. The value that's returned when accessing Transaction.id is determined by checking the context that we're currently in. If we're not in a context where the value was explicitly set we'll receive the default value that we assigned in the declaration. In this case that would be nil.

The value that's assigned to Transaction.id when creating a scope is only valid during that scope.

You can temporarily override this value within the scope with a nested call to withValue(_:operation:):

await Transaction.$id.withValue(UUID()) {
    print(Transaction.id) // original value

    await Transaction.$id.withValue(UUID()) {
        print(Transaction.id) // new value
    }

    print(Transaction.id) // original value
}

Outside of the nested closure, the value for Transaction.id returns it's "orginal" value because the assigned value is scoped to the closure that you pass to withValue.

The way Swift Concurrency scopes this makes sure that you can't accidentally assign an expensive object to a task local value and forget to deallocate it when it's no longer needed. In other words, the scoping of withValue(_:operation:) makes sure that our task local value does not escape its scope.

If we start a new task from within a context created through withValue(_:operation:) this task will not inherit the task local values that were present in the context:

await Transaction.$id.withValue(UUID()) {
    print(Transaction.id) // assiged value

    Task {
        print(Transaction.id) // nil
    }

    Task.detached {
        print(Transaction.id) // nil
    }
}

If you want task local values to be copied into a detached task you'll need to explicitly copy this value:

await Transaction.$id.withValue(UUID()) {
    let transaction = Transaction.id
    Task {
        print(transaction) // the task local UUID
    }
}

You can also use this copied value as a new task local for the detached task:

await Transaction.$id.withValue(UUID()) {
    let transaction = Transaction.id
    Task {
        await Transaction.$id.withValue(transaction) {
            print(Transaction.id) // the task local UUID from the outer scope
        }
    }
}

Note that this allows multiple sources to read this value concurrently. For this reason task local values have to be save to use concurrently. This is enforced by the requirement that task local values are Sendable.

Okay. I think at this point you know enough about task local values to have an idea of what they are and how they're used. In short, they provide a scope where a certain "global" value is available.

Let's see when these values can (and more importantly should) be used.

Understanding how task local values can be used

When you've read the previous section, it might seem attractive to put shared state or information in a task local value. This would have a similar feel to SwiftUI's @Environment which is intended for sharing of state and dependencies in a view hierarchy.

Task local values are not intended to be used like this.

I feel like I should repeat this with different words.

Task local values should not be used to provide state that you depend on within the context of a task.

There are multiple reasons for this, and I reckon one most important ones is that it's extremely error prone to have to depend on setting this state outside of a function. It's easy to forget to call withValue(_:operation:) all the time, and this could mean that you introduce unnoticed bugs in your application.

Another, possibly more important, reason to not rely on task local values to provide state you depend on is that it's more expensive to look up task local values than it is to access a normal variable. The reason for this is that the task local value will have to reason about its current context before it can provide a value.

When you have an async function that depends on specific state to do its job, pass it to the function explicitly.

So what are task local value for then?

Well, they are intended to associate specific metadata with a given task. This means that task local values will mostly be useful if you want to debug your code, or if you want to be able to group a bunch of asynchronously produced logs together through something like a transaction ID.

Imagine that you have some object that can fetch user data. This object depends on a data provider, and the data provider relies on an Authorizer and Networking object to make authorized network requests.

We might have many concurrent calls in progress, and when you attempt to debug something in this flow, your logs might looks a little like this:

UserApi.fetchProfile() called
UserApi.fetchProfile() called
RemoteDataSource.loadProfile() called
RemoteDataSource.loadProfile() called
UserApi.fetchProfile() called
Authorizer.authorize(_ request: URLRequest) called
RemoteDataSource.loadProfile() called
Authorizer.authorize(_ request: URLRequest) called
Authorizer.accessToken() called
Authorizer.refreshToken(_ token: Token?) called
Authorizer.authorize(_ request: URLRequest) called
Authorizer.accessToken() called
Networking.load<T: Decodable>(_ request: URLRequest) called
Authorizer.accessToken() called
Networking.load<T: Decodable>(_ request: URLRequest) called
Networking.load<T: Decodable>(_ request: URLRequest) called

With this output it's impossible to see what the order of events is exactly. We don't know if the first loadProfile call lines up with the first load call, or whether it triggered the call to refreshToken.

Without task local values you might pass a UUID to every function, and pass the UUID down to the next functions so you can retrace your steps. With task local values, you can associate a transaction ID with your task using the Transaction.id from before so it propogates throughout your function calls automatically. Let's see what this looks like:

class UserApi {
    let dataSource: RemoteDataSource

    init(dataSource: RemoteDataSource) {
        self.dataSource = dataSource
    }

    func fetchProfile() async throws -> Profile {        
        return try await Transaction.$id.withValue(UUID()) {
            if let transactionID = Transaction.id {
                print("\(transactionID) UserApi.fetchprofile() called")
            }
            return try await dataSource.loadUserProfile()
        }
    }
}

To print useful information, we check if Transaction.id is set. In this case we've set it with withValue(_:operation:) on the line before but we still unwrap it properly. Next, I simply prefix my old print statement with the transaction ID.

In the loadUserProfile function, I can also access the transaction ID because it runs as part of the same task:

func loadProfile() async throws -> Profile {
    if let transactionID = Transaction.id {
        print("\(transactionID): RemoteDataSource.loadRandomNumber() called")
    }

    let request = try await authorizer.authorize(URLRequest(url: endpoint))
    return try await network.load(request)
}

This logic can be written in all of the subsequent function calls too. So we'd add this same code to the authorize, accessToken, refreshToken, and load methods. When we run the code with all of this in place, here's what the same output from earlier would look like:

3F0A1FD9-D55D-4015-A7D0-8B054A1CF7A9: UserApi.fetchProfile() called
98365B1C-4176-44DA-806A-2D2BCB787111: UserApi.fetchProfile() called
3F0A1FD9-D55D-4015-A7D0-8B054A1CF7A9: RemoteDataSource.loadProfile() called
98365B1C-4176-44DA-806A-2D2BCB787111: RemoteDataSource.loadProfile() called
F02A7024-0B84-454C-9E23-E3DA0F8E3558: UserApi.fetchProfile() called
3F0A1FD9-D55D-4015-A7D0-8B054A1CF7A9: Authorizer.authorize(_ request: URLRequest) called
F02A7024-0B84-454C-9E23-E3DA0F8E3558: RemoteDataSource.loadProfile() called
98365B1C-4176-44DA-806A-2D2BCB787111: Authorizer.authorize(_ request: URLRequest) called
3F0A1FD9-D55D-4015-A7D0-8B054A1CF7A9: Authorizer.accessToken() called
3F0A1FD9-D55D-4015-A7D0-8B054A1CF7A9: Authorizer.refreshToken(_ token: Token?) called
F02A7024-0B84-454C-9E23-E3DA0F8E3558: Authorizer.authorize(_ request: URLRequest) called
98365B1C-4176-44DA-806A-2D2BCB787111: Authorizer.accessToken() called
3F0A1FD9-D55D-4015-A7D0-8B054A1CF7A9: Networking.load<T: Decodable>(_ request: URLRequest) called
F02A7024-0B84-454C-9E23-E3DA0F8E3558: Authorizer.accessToken() called
98365B1C-4176-44DA-806A-2D2BCB787111: Networking.load<T: Decodable>(_ request: URLRequest) called
F02A7024-0B84-454C-9E23-E3DA0F8E3558: Networking.load<T: Decodable>(_ request: URLRequest) called

Now that every sequence of method calls is associated with a transaction id, the logs that are produced by this program are far more useful than they were before.

This is a really good use of task local values because we're not using them to pass around important state. Instead, we use this for logging and retracing our steps. The transaction ID really is metadata rather than state. This is exactly what the Swift team has intended task local values for. They're a container for task metadata.

In Summary

While task local values will most likely not be a heavily used feature for most people, I'm sure some developers will make heavy use of it for debugging, logging, and other purposes. I personally find this transaction example very compelling because I've worked on a codebase not too long ago where we passed transaction IDs around to every method call that would make a network call so we could collect comprehensive logs in case something went wrong. Manually passing a transaction ID around really feels like busywork, and being able to associate a transaction ID with an entire chain of method calls that occur withing the scope of the operation passed to withValue(_:operation:) is a breath of fresh air.

If you every find yourself needing to untangle a bunch of concurrently active tasks, task local values might just be the tool you need to help you out.

Got any questions or feedback? Feel free to shoot me a message on Twitter.

We all know that async / await was one of this year’s big announcements WWDC. It completely changes the way we interact with concurrent code. Instead of using completion handlers, we can await results in a non-blocking way. More importantly, with the new Swift Concurrency features, our Swift code is much safer and consistent than ever before.

For example, the Swift team built an all-new threading model that ensures your program doesn’t spawn more threads than there are CPU cores to avoid thread explosion. This is a huge difference from GCD where every call to async would spawn a new thread and the CPU had to give each of your threads some time to run which caused significant overhead due to a lot of context switching.

While all this is interesting, and makes our concurrent code much better, this post is not about Swift concurrency as a whole. Instead, I want to focus on a smaller feature called Actors.

Understanding the problem that actors solve

An actor in Swift 5.5 is an object that isolates access to its mutable state. This means that anybody that wants to call a method on an actor where the method relies on mutable state, regardless of reading or writing, has to do so asynchronously.

But what does this mean? And why is this the case?

To answer that, let’s consider an example of code that you might write today.

class DateFormatterCache {
    static let shared = DateFormatterCache()

    private var formatters = [String: DateFormatter]()

    func formatter(with format: String) -> DateFormatter {
        if let formatter = formatters[format] {
            return formatter
        }

        let formatter = DateFormatter()
        formatter.locale = Locale(identifier: "en_US_POSIX")
        formatter.dateFormat = format
        formatters[format] = formatter
        return formatter
    }
}

This code is quite straightforward, and something that I have actually included in a project once. However, it got rejected in a PR. To find out why, let’s see how this code would be used.

Let’s emulate a situation where this code is used in a multithreaded environment.

Let’s add a few print statements first:

class DateFormatterCache {
    static let shared = DateFormatterCache()

    private var formatters = [String: DateFormatter]()

    func formatter(with format: String) -> DateFormatter {
        if let formatter = formatters[format] {
            print("returning cached formatter for \(format)")
            return formatter
        }

        print("creating new formatter for \(format)")
        let formatter = DateFormatter()
        formatter.locale = Locale(identifier: "en_US_POSIX")
        formatter.dateFormat = format
        formatters[format] = formatter
        return formatter
    }
}

This will tell us whether we’re reusing an existing formatter or creating a new one. These print statements will make it easier to follow what this code does exactly.

Here’s how I’ll emulate the multithreaded environment:

let formats = ["DD/MM/YYYY", "DD-mm-yyyy", "yyyy", "DD-MM", "DD-mm"]
DispatchQueue.concurrentPerform(iterations: 10) { iteration in
    let formatter = DateFormatterCache.shared.formatter(with: formats.randomElement()!)
}

I know these date formats might not be the best; it’s not the point for me to show you some clever date formats. Instead, I want to demonstrate a problem to you.

Running this code crashes most of the time for me. I get an EXC_BAD_ACCESS error on the formatters dictionary after a couple of iterations.

When looking at the console, the output looks a little like this:

creating new formatter for DD-mm-yyyy
creating new formatter for DD-mm
creating new formatter for DD-mm-yyyy
creating new formatter for yyyy
creating new formatter for DD-mm-yyyy
creating new formatter for DD-MM
creating new formatter for DD-MM
creating new formatter for DD-mm-yyyy
creating new formatter for DD-mm-yyyy
creating new formatter for DD/MM/YYYY

This makes it look like the cache is not doing anything. Clearly, we're creating a new formatter for every iteration.

Let’s run this code in a normal for loop to see if that’s any better.

for _ in 0..<10 {
    let formatter = DateFormatterCache.shared.formatter(with: formats.randomElement()!)
}

The first thing to note is that this code wouldn’t crash. There’s no bad access on formatters inside of the cache anymore.

Let’s look at the console:

creating new formatter for DD/MM/YYYY
creating new formatter for DD-mm-yyyy
returning cached formatter for DD/MM/YYYY
returning cached formatter for DD/MM/YYYY
creating new formatter for yyyy
returning cached formatter for DD/MM/YYYY
creating new formatter for DD-mm
returning cached formatter for yyyy
returning cached formatter for DD-mm
returning cached formatter for DD-mm

This looks much better. Apparently the caching logic should work. But not when we introduce concurrency…

The reason the formatter cache crashed in the concurrent example is a data race. Multiple threads attempt to read, and modify, the formatters dictionary. The program can’t handle these concurrent reads and writes which puts our program in an inconsistent state and eventually leads to a crash.

Another interesting aspect of this is the broken cache. This of course related to the data race, but let’s see what actually happens when the code runs.

I have explained issues with concurrency, mutable state, and dictionaries before in this post.

Because we’re running code concurrently, we call the formatter(with:) method ten times at roughly the same time. When this functions starts, it reads the formatters dictionary which will be empty, so no formatters are cached. And because we have ten concurrent reads, the dictionary will be empty for each of the ten calls.

Dictionaries are passed by value with reference characteristics. This means that the dictionary is not copied until you attempt to modify it. This is important to remember.

When each of the ten calls to formatter(with:) attempt to add the newly created formatter to the cache, the formatter will be copied and the new value is added to the copy. This means that each iteration will be adding to the dictionary that was read earlier. An empty dictionary that we'll add one entry to, and we'll make that the new value of formatters. This means that we'll end up with a different dictionary that has one value after each of these concurrent function calls.

Usually.

Because our concurrent code might also run slightly slower, we could sometimes have a dictionary with two, three, or more items. And this dictionary could be overwritten by a later iteration if our code happens to run that way.

There’s a ton of ambiguity here. We don’t control exactly how our formatter cache is accessed, by which thread, and how often. This means that my initial, simple implementation, can never work reliably in a multithreaded environment.

Solving data races without Actors

We can fix this without Swift’s new concurrency by synchronizing access to the formatters dictionary. Synchronizing means that we ensure that we execute the formatter(with:) function serially even if it’s called in parallel. This will ensure that the formatters dictionary is read, and updated, atomically. Or in one pass. Or in other words, without interruption. To gain a better understanding of what atomicity is, you can refer to this post I wrote earlier. By synchronizing code we'll know that once the formatter(with:) function has done its work, we’re ready to handle another call to formatter(with:). Basically callers to formatter(with:) will have to wait for their turn.

Synchronizing code like that can be done with a dispatch queue:

class DateFormatterCache {
    static let shared = DateFormatterCache()

    private var formatters = [String: DateFormatter]()
    private let queue = DispatchQueue(label: "com.dw.DateFormatterCache.\(UUID().uuidString)")

    func formatter(with format: String) -> DateFormatter {
        return queue.sync {
            if let formatter = formatters[format] {
                print("returning cached formatter for \(format)")
                return formatter
            }

            print("creating new formatter for \(format)")
            let formatter = DateFormatter()
            formatter.locale = Locale(identifier: "en_US_POSIX")
            formatter.dateFormat = format
            formatters[format] = formatter
            return formatter
        }
    }
}

By creating a private queue and calling sync on it in the formatter, we make sure the queue only runs one of these closures at a time. We can return the result of our operation from the closure, by returning queue.sync from the function because everything happens synchronously.

While this code runs we block the calling thread. This means that nothing else can run on that thread until the sync closure ran.

When we run the concurrent example code again with this private queue in place:

let formats = ["DD/MM/YYYY", "DD-mm-yyyy", "yyyy", "DD-MM", "DD-mm"]
DispatchQueue.concurrentPerform(iterations: 10) { iteration in
    let formatter = DateFormatterCache.shared.formatter(with: formats.randomElement()!)
}

It doesn’t crash and produces the following output:

creating new formatter for DD/MM/YYYY
returning cached formatter for DD/MM/YYYY
creating new formatter for yyyy
creating new formatter for DD-mm
returning cached formatter for DD-mm
creating new formatter for DD-mm-yyyy
returning cached formatter for DD/MM/YYYY
returning cached formatter for yyyy
returning cached formatter for DD-mm
creating new formatter for DD-MM

Clearly, the code works well! Awesome.

But there are a few problems here:

1. We block the thread. This means that GCD will spawn new threads to make sure the CPU stays busy with those threads instead of sitting completely idle. This means that we’ll potentially have tons of threads, which can be expensive if the CPU has to context switch between threads a lot.
2. It’s not clear to the caller of formatter(with:) that it’s a blocking function. A caller of this function might have to wait for many other calls to this function to complete which might be unexpected.
3. It’s easy to forget synchronization, especially if the formatters property should be readable from outside of the class. The compiler can’t help us so we have to rely on our own judgement and hope that any mistakes get caught in PR, just like my mistake was.

In Swift 5.5, we can leverage actors to achieve proper mutable state isolation with compiler support.

Solving data races with Actors

As I mentioned earlier, actors isolate access to their mutable state. This means that an object like the DateFormatterCache can be written as an actor instead of a class, and we’ll get synchronization for free:

actor DateFormatterCache {
    static let shared = DateFormatterCache()

    private var formatters = [String: DateFormatter]()

    func formatter(with format: String) -> DateFormatter {
        if let formatter = formatters[format] {
            print("returning cached formatter for \(format)")
            return formatter
        }

        print("creating new formatter for \(format)")
        let formatter = DateFormatter()
        formatter.locale = Locale(identifier: "en_US_POSIX")
        formatter.dateFormat = format
        formatters[format] = formatter
        return formatter
    }
}

Note how the object is completely unchanged from the initial version. All I did was change class to actor and I removed the queue that we added later. Also note that actors are reference types, just like classes are.

Now that DateFormatterCache is an actor, Swift will know that formatters is mutable and that any access to it will need to be synchronized. This also means that Swift knows hat formatter(with:) might not return immediately, even if the function isn’t marked async. This is very similar to what we had earlier with the private queue.

If I were to make formatters an internal or public property instead of private, accessing formatters directly from the outside would also be synchronized, and therefor be done asynchronously from the caller’s point of view.

Within the actor, we know that we’re already synchronized. So I don’t have to wait for formatters’s value to be read. I can just read it directly without doing any manual synchronization. I get all of this for free; there’s no work to be done by me to ensure correct synchronization.

Running the following test code from earlier produces an error though:

let formats = ["DD/MM/YYYY", "DD-mm-yyyy", "yyyy", "DD-MM", "DD-mm"]
DispatchQueue.concurrentPerform(iterations: 10) { iteration in
    let formatter = DateFormatterCache.shared.formatter(with: formats.randomElement()!)
}

Here’s the error:

Actor-isolated instance method ‘formatter(with:)’ can only be referenced from inside the actor

This error seems to suggest that we cannot access formatter(with:) at all. This isn’t entirely correct, but we’ll need access it asynchronously rather than synchronously like we do now. The easiest way to do this is to either already be in an async context, or enter one:

let formats = ["DD/MM/YYYY", "DD-mm-yyyy", "yyyy", "DD-MM", "DD-mm"]
DispatchQueue.concurrentPerform(iterations: 10) { iteration in
    Task {
        let formatter = DateFormatterCache.shared.formatter(with: formats.randomElement()!)
    }
}

Doing this provides us with a more useful compiler error:

Expression is ‘async’ but is not marked with ‘await’

Remember how I explained that formatter(with:) might not return immediately because it will be synchronized by the actor just like how the queue.sync version in the class didn’t return immediately?

In the old version of this code, the blocking nature of formatters(with:) was hidden.

With an actor, the compiler will tell us that formatter(with:) might not return immediately, so it forces us to use an await so that our asynchronous work can be suspended until formatter(with:) is run.

Not only is this much nicer due to the more expressive nature of the code, it’s also much better because we’re not blocking our thread. Instead, we’re suspending our function so its execution context can be set aside while the existing thread does other work. We don't create a new thread like we did with GCD. Eventually the actor runs formatter(with:) and our execution context is picked back up where it left off.

Here's what the corrected code looks like:

let formats = ["DD/MM/YYYY", "DD-mm-yyyy", "yyyy", "DD-MM", "DD-mm"]
DispatchQueue.concurrentPerform(iterations: 10) { iteration in
    Task {
        let formatter = await DateFormatterCache.shared.formatter(with: formats.randomElement()!)
    }
}

What’s interesting is that because Swift’s new concurrency model does not spawn more threads than CPU cores, simply wrapping the class based version of the cache in a Task.init or Task.detached block would already mask our bug most of the time. The reason for this is that it’s very likely that all of the task you create run on the same thread. This means that they won’t actually run concurrently like they do with Task.

You can try this out by making DateFormatter a class again and removing the await from the last code snippet. Keep the Task though since that will leverage Swift's new concurrency features.

However, you should not assume that the bug would actually be fixed by using a class, not synchronizing, and using Task. There is no guarantee that your closures would run on the same thread. And more importantly, in the really world you might have many tasks happening that are spawned from many different threads. This would make it far more likely for data races to occur than it is in my simple example.

Conclusion

In this post, I explained a little bit about what Swift's new Actors are, and what their roles is in this new async / await world that we can start exploring. You also learned when data races occur, and how you can solve them. First, you saw an approach without actors. After that, I showed you an approach that's much more expressive and without any of the hidden implications that the earlier version had.

Swift's actors are an extremely useful tool to ensure you don't run into data races by isolating mutatble state, and synchronizing access. What's even better is that the Swift language and compiler make sure of all this, and any potential errors can be raised as compiler error rather than bugs and runtime crashes. I’m extremely excited for concurrency in Swift 5.5, and can’t wait to explore this feature more over the coming weeks.

Meet async / await, explore structured concurrency, protect mutable state with actors should be watched first.

Threading model

Compares GCD to Swift. It’s not built on top of GCD. It’s a whole new thread pool.

GCD is very eager to bring up threads whenever we kick off work on queues. When a queue blocks its thread, a new thread will be spawned to handle work.

This means that the system can overcommit with more threads than there are CPU cores. This is also called Thread explosion and can lead to memory and performance issues.

There’s a lot of scheduling overhead during threads. There will likely be a ton of context switching which in turn will make the CPU run less efficiently.

Swift concurrency was designed to be more efficient than GCD.

The goal is to have no more threads than CPU cores. Instead, there are continuations that can be blocked. Instead of having the CPU context switch, the thread does this. It’s as simple as a method call so the overhead is much, much lower.

To make this happen, the language has to be able to guarantee that threads do not block through language features:

• await and non-blocking of threads
• Tracking of dependencies in Swift task model

Swift’s await does not block a thread like GCD’s sync does.

Every thread has a stack that keeps track of function calls. There are several stack frames. One for each function call. When a function returns, its stack frame is popped.

When an async function is called with await, it’s tracked as an async frame on the heap. The async frames keep track of state that’s needed when the awaited function returns. When another function is called, the topmost stack frame on the thread is replaced. Because async frames are stored on the heap, they can be put back on a thread and resumed. Async frames will be put back on the stack as needed. Calling sync code in an async fuck will add frames to the thread’s stack.

The block of code that runs after the await is called a continuation When execution should resume, the continuation is put back on a thread’s stack.

Interesting stuff, try to find out more and properly understand this.

Async work is modeled with tasks. Tasks can have child tasks. Tasks can only await other tasks in swifts. Awaited tasks are either continuations or child tasks.

Threads can track these task dependencies and they’ll know how to suspend tasks and schedule other work until the task can be resumed.

A cooperative thread pool is the default executor for Swift. The number of threads is limited to the number of CPU cores. Threads will always make forward progress and avoids thread explosion and excessive task switching.

Where with GCD you needed to be mindful of the number of queues you use, Swift concurrency ensures that you don’t have to worry about this anymore.

Concurrency always comes with a cost. It takes additional memory allocation and logic in the Swift runtime. Concurrency should only be used when its cost outweighs the cost of managing it.

For example, reading for user defaults is a super small task that should not be spawned into its own async task unless needed.

Measure performance to understand when you need concurrency.

await explicitly breaks atomicity because in the time between your await and calling the continuation, things might change. You should never hold locks across await. Thread specific data is also not preserved across await because you might resume on a different thread than the one you were suspended on.

The Swift language upholds the runtime contract that threads can always make forward progress. You have to make sure you don’t break this contract so the thread pool can do its best work.

• Use primitives like await, actors, and task groups so the compiler can enforce the contract.
• Locks can be used in sync code with caution. There’s no compiler support but does not break the contract as long as the thread is not fully blocked (for too long)
• Semaphores and NSCondition are not safe to use. They hide dependency information from the runtime so it cannot schedule work correctly which might result in blocking.

Don’t use unsafe primitives to wait across task boundaries. Like for example using a semaphore in an async context. This is not save.

The LIBDISPATCH_COOPERATIVE_POOL_STRICT=1 environment variable will run the app under a debug runtime that enforces forward progress for thread.

Synchronization with Actors

Actors synchronize access to their state through mutual exclusion.

When using DispatchQueue.sync, a current thread can be reused when there’s no contention. When there is, DispatchQueue.sync is blocking and new threads are spawned.

When you use DispatchQueue.async, you’re non-blocking under contention, but a new thread is always spawned.

Swift Actors always reuse threads and are non-blocking. If the thread is free, code is run. If not, function is suspended and run later.

Serial queues can be replaced with actors to manage access.

When you switch between different actors, you are thread hopping. An actor can be suspended and threads can easily hop from a running actor to a currently suspended actor. The runtime can handle this by creating work items for the thread without spawning a new thread.

Actor work items can remain pending until an in progress work item is completed.

Actors are designed to allow the system to prioritize work.

Actor reentrancy means that an actor might have pending work when it schedules and executes new work items. This can happen if a task is awaiting something, and this other thing awaits something on the actor.

The main actor runs on the main thread. The main thread is separated from the rest of the threads in the cooperative pol.

When you hop on and off the main actor often, you force hopping from and to the mean thread. This is expensive. If this happens it’s better to bundle work and run a bigger task to update UI from the main actor. For that reason, it’s not adviced to jump onto an actor and away from the main actor for small bits of work (often).