When writing asynchronous code using Swift’s new built-in concurrency system, creating a Task gives us access to a new asynchronous context, in which we’re free to call async-marked APIs, and to perform work in the background.

But besides enabling us to encapsulate a piece of asynchronous code, the Task type also lets us control the way that such code is run, managed, and potentially cancelled.

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Bridging the gap between synchronous and asynchronous code

Perhaps the most common way to use a Task within UI-based apps is to have it act as a bridge between our synchronous, main thread-bound UI code, and any background operations that are used to fetch or process the data that our UI is rendering.

For example, here we’re using a Task within a UIKit-based ProfileViewController to be able to use an async-marked API to load the User model that our view controller should render:

class ProfileViewController: UIViewController {
    private let userID: User.ID
    private let loader: UserLoader
    private var user: User?
    ...

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        Task {
            do {
                let user = try await loader.loadUser(withID: userID)
                userDidLoad(user)
            } catch {
                handleError(error)
            }
        }
    }
    
    ...

    private func handleError(_ error: Error) {
        // Show an error view
        ...
    }

    private func userDidLoad(_ user: User) {
        // Render the user's profile
        ...
    }
}

One thing that’s really interesting about the above code is that there are no self captures, no DispatchQueue.main.async calls, no tokens or cancellables that need to be retained, or any other kind of “bookkeeping” that we normally have to do when performing asynchronous operations using tools like closures or Combine.

So how exactly are we able to perform a network call (which is definitely going to be executed on a background thread), and then directly call UI-updating methods like userDidLoad and handleError, without first manually dispatching those calls using DispatchQueue.main?

This is where Swift’s new MainActor attribute comes in, which automatically ensures that UI-related APIs (such as those defined within a UIView or UIViewController) are correctly dispatched on the main thread. So, as long as we’re writing our asynchronous code using Swift’s new concurrency system, and within such a MainActor-marked context, then we no longer have to worry about accidentally performing UI updates on a background queue. Neat!

Another thing that’s interesting about our above implementation is that we’re not required to manually retain our loading task in order for it to complete. That’s because asynchronous tasks are not automatically cancelled when their corresponding Task handle is deallocated — they just keep executing in the background.

Referencing and cancelling a task

However, in this particular case, we probably do want to maintain a reference to our loading task, since we might want to cancel it when our view controller disappears, and we probably also want to prevent duplicate tasks from being performed in case the system calls viewWillAppear while a task is already in progress:

class ProfileViewController: UIViewController {
    private let userID: User.ID
    private let loader: UserLoader
    private var user: User?
    private var loadingTask: Task<Void, Never>?
    ...

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        guard loadingTask == nil else {
            return
        }

        loadingTask = Task {
            do {
                let user = try await loader.loadUser(withID: userID)
                userDidLoad(user)
            } catch {
                handleError(error)
            }

            loadingTask = nil
        }
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        loadingTask?.cancel()
loadingTask = nil
    }

    ...
}

Note how a Task has two generic types — the first indicates what type of output that it returns (which is Void in our case, since our task simply forwards its loaded User model onto our view controller’s methods), and the second is for its error type (and since we handle all errors within our task itself, that error type is Never in this case).

Calling the cancel method on a Task also marks all of its child-tasks as cancelled as well. So by cancelling our top-level loadingTask within our view controller, we’re also implicitly cancelling its underlying network operations at the same time.

Context inheritance

That relationship between a given Task and its parent can be quite important, at least within @MainActor-marked classes, such as views and view controllers. That’s because child tasks are not only connected to their parents in terms of cancellation — they also automatically inherit the same execution context as their parent uses.

To illustrate when that behavior can become somewhat problematic, let’s imagine that our ProfileViewController was loading its User model from a local database, rather than over the network, and that our Database API is currently completely synchronous.

At first glance, it could seem like the following implementation will be completely fine, since we might expect that our asynchronous work will still be executed on a background thread (even if we no longer perform any await-based calls within our Task):

class ProfileViewController: UIViewController {
    private let userID: User.ID
    private let database: Database
    private var user: User?
    private var loadingTask: Task<Void, Never>?
    ...

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        guard loadingTask == nil else {
            return
        }

        loadingTask = Task {
            do {
                let user = try database.loadModel(withID: userID)
                userDidLoad(user)
            } catch {
                handleError(error)
            }

            loadingTask = nil
        }
    }

    ...
}

However, although the above Task will indeed be performed asynchronously, it will still be executed on the main thread, since it’s being dispatched using the MainActor (it inherits that context from the viewWillAppear method that it was created in). So, essentially, our above Task is more or less equivalent to performing that same database call within a DispachQueue.main.async closure.

Since we probably want to move our database call away from the main thread (to prevent that call from interfering with the responsiveness of our UI), we could instead use a detached task — which will be executed within its own, stand-alone context. When doing so, we’ll also have to use await when calling back into our view controller’s methods, since those methods are isolated by the MainActor (we can also no longer set our loadingTask property to nil directly within our task):

class ProfileViewController: UIViewController {
    ...

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        guard loadingTask == nil else {
            return
        }

        loadingTask = Task.detached(priority: .userInitiated) { [weak self] in
            guard let self = self else { return }

            do {
                let user = try self.database.loadModel(withID: self.userID)
                await self.userDidLoad(user)
            } catch {
                await self.handleError(error)
            }

            await self.loadingTaskDidFinish()
        }
    }

    ...

    private func loadingTaskDidFinish() {
        loadingTask = nil
    }
}

In general, it’s recommended to only use detached tasks when we explicitly want to create a new top-level task that uses its own execution context. In other situations, simply using Task {} to encapsulate our asynchronous code is the recommended way to go.

Awaiting the result of a task

Finally, let’s take a look at how we can await the result of a given Task instance. For example, let’s say that we wanted to extend our above Database-based view controller implementation with support for loading the current user’s image over the network.

To do that, we’ll wrap our detached task within yet another Task instance, and we’ll then use the await keyword to wait for our database loading operation to complete before proceeding with our image download — like this:

class ProfileViewController: UIViewController {
    private let userID: User.ID
    private let database: Database
    private let imageLoader: ImageLoader
    private var user: User?
    private var loadingTask: Task<Void, Never>?
    ...

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        guard loadingTask == nil else {
            return
        }

        loadingTask = Task {
            let databaseTask = Task.detached(
    priority: .userInitiated,
    operation: { [database, userID] in
        try database.loadModel(withID: userID)
    }
)

            do {
                let user = try await databaseTask.value
                let image = try await imageLoader.loadImage(from: user.imageURL)
                userDidLoad(user, image: image)
            } catch {
                handleError(error)
            }

            loadingTask = nil
        }
    }

    ...

    private func userDidLoad(_ user: User, image: UIImage) {
        // Render the user's profile
        ...
    }
}

Note how we can once again call our view controller’s methods directly within our top-level Task, since it’s now MainActor-bound, just like before. That illustrates just how smoothly we can now mix work that’s performed both on and off the main queue, without having to worry about accidentally performing UI updates on the wrong thread.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Conclusion

Swift’s new Task type enables us to encapsulate, observe, and control a unit of asynchronous work — which in turn lets us call async-marked APIs, and perform background work, even within code that’s otherwise completely synchronous. That way, we can gradually introduce async functions and the rest of Swift’s new concurrency system, even within applications that weren’t designed with those new features in mind.

I hope that you found this article interesting and useful. If you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

Since the very first version of Swift, we’ve been able to define our various types as either classes, structs, or enums. But now, with the launch of Swift 5.5 and its built-in concurrency system, a new type declaration keyword has been added to the mix — actor.

So, in this article, let’s explore the concept of actors, and what kinds of problems that we could solve by defining custom actor types within our code bases.

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Preventing data races

One of the core advantages of Swift’s new actor types is that they can help us prevent so-called “data races” — that is, memory corruption issues that can occur when two separate threads attempt to access or mutate the same data at the same time.

To illustrate, let’s take a look at the following UserStorage type, which essentially provides a way for us to pass a dictionary of User models around by reference, rather than by value:

class UserStorage {
    private var users = [User.ID: User]()

    func store(_ user: User) {
        users[user.id] = user
    }

    func user(withID id: User.ID) -> User? {
        users[id]
    }
}

By itself, there’s really nothing wrong with the above implementation. However, if we were to use that UserStorage class within a multi-threaded environment, then we could quickly run into various kinds of data races, since our implementation currently performs its internal mutations on whatever thread or DispatchQueue that it was called on.

In other words, our UserStorage class currently isn’t thread-safe.

One way to address that would be to manually dispatch all of our reads and writes on a specific DispatchQueue, which would ensure that those operations always happen in serial order, regardless of which thread or queue that our UserStorage methods will be used on:

class UserStorage {
    private var users = [User.ID: User]()
    private let queue = DispatchQueue(label: "UserStorage.sync")

    func store(_ user: User) {
        queue.sync {
            self.users[user.id] = user
        }
    }

    func user(withID id: User.ID) -> User? {
        queue.sync {
            self.users[id]
        }
    }
}

The above implementation works, and now successfully protects our code against data races, but it does have a quite significant flaw. Since we’re using the sync API to dispatch our dictionary access code, our two methods will cause the current execution to be blocked until those dispatch calls have finished.

That can become problematic if we end up performing a lot of concurrent reads and writes, since each caller would be completely blocked until that particular UserStorage call has finished, which could result in poor performance and excessive memory usage. This type of problem is often referred to as “data contention”.

One way to fix that problem would be to instead make our two UserStorage methods fully asynchronous, which involves using the async dispatch method (rather than sync), and in the case of retrieving a user, we’d also have to use something like a closure to notify the caller when its requested model was loaded:

class UserStorage {
    private var users = [User.ID: User]()
    private let queue = DispatchQueue(label: "UserStorage.sync")

    func store(_ user: User) {
        queue.async {
            self.users[user.id] = user
        }
    }

    func loadUser(withID id: User.ID,
                  handler: @escaping (User?) -> Void) {
        queue.async {
    handler(self.users[id])
}
    }
}

Again, the above certainly works, and has been one of the preferred ways to implement thread-safe data access code prior to Swift 5.5. However, while closures are a fantastic tool, having to wrap all of our User handling code within a closure could definitely make that code more complex — especially since we had to make our loadUser method’s closure argument escaping.

A case for an actor

This is exactly the type of situation in which Swift’s new actor types can be incredibly useful. Actors work much like classes (that is, they are passed by reference), with two key exceptions:

• An actor automatically serializes all access to its properties and methods, which ensures that only one caller can directly interact with the actor at any given time. That in turn gives us complete protection against data races, since all mutations will be performed serially, one after the other.
• Actors don’t support subclassing since, well, they’re not actually classes.

So, practically, all that we have to do to convert our UserStorage class into an actor is to go back to its original implementation, and simply replace its use of the class keyword with the new actor keyword — like this:

actor UserStorage {
    private var users = [User.ID: User]()

    func store(_ user: User) {
        users[user.id] = user
    }

    func user(withID id: User.ID) -> User? {
        users[id]
    }
}

With just that tiny change in place, our UserStorage type is now completely thread-safe, without requiring us to implement any kind of custom dispatching logic. That’s because actors force other code to call their methods using the await keyword, which lets the actor’s serialization mechanism suspend such a call in case the actor is currently busy processing another request.

For example, here we’re using our new UserStorage actor as a caching mechanism within a UserLoader — which requires us to use await when both loading and storing User values:

class UserLoader {
    private let storage: UserStorage
    private let urlSession: URLSession
    private let decoder = JSONDecoder()

    init(storage: UserStorage, urlSession: URLSession = .shared) {
        self.storage = storage
        self.urlSession = urlSession
    }

    func loadUser(withID id: User.ID) async throws -> User {
        if let storedUser = await storage.user(withID: id) {
            return storedUser
        }

        let url = URL.forLoadingUser(withID: id)
        let (data, _) = try await urlSession.data(from: url)
        let user = try decoder.decode(User.self, from: data)

        await storage.store(user)

        return user
    }
}

Note how, apart from the fact that we have to use await when interacting with them, actors can be used just like any other Swift type. They can be passed as arguments, stored using properties, and can also conform to protocols.

Race conditions are still possible

However, while our user loading and storage code is now guaranteed to be free from low-level data races, that doesn’t mean that it’s necessarily free from race conditions. While data races are essentially memory corruption issues, race conditions are logical issues that occur when multiple operations end up happening in an unpredictable order.

In fact, if we end up using our new UserLoader to load the same user within multiple places at the same time, we’ll very likely run into a race condition, since several, duplicate network calls will end up being performed. That’s because our storedUser value will only exist once that user has been completely loaded.

Initially, we might think that solving that issue would be as simple as making our UserLoader an actor as well:

actor UserLoader {
    ...
}

But it turns out that doing so isn’t quite enough in this case, since our problem isn’t related to how our data is mutated, but rather in which order that our underlying operations are performed.

Because even though each actor does indeed serialize all calls to it, when an await occurs within an actor, that execution is still suspended just like any other — meaning that the actor will be unblocked and ready to accept new requests from other code. While that’s, in general, a great thing — as it lets us write nonblocking code that’s efficiently executed — in this particular case, that behavior will make our UserLoader keep performing duplicate network calls, just like when it was implemented as a class.

To fix that, we’re going to have to keep track of when the actor is currently performing a given network call. That can be done by encapsulating that code within asynchronous Task instances, which we can then store references to within a dictionary — like this:

actor UserLoader {
    private let storage: UserStorage
    private let urlSession: URLSession
    private let decoder = JSONDecoder()
    private var activeTasks = [User.ID: Task<User, Error>]()

    ...

    func loadUser(withID id: User.ID) async throws -> User {
        if let existingTask = activeTasks[id] {
    return try await existingTask.value
}

        let task = Task<User, Error> {
            if let storedUser = await storage.user(withID: id) {
                activeTasks[id] = nil
                return storedUser
            }
        
            let url = URL.forLoadingUser(withID: id)
            let (data, _) = try await urlSession.data(from: url)
            let user = try decoder.decode(User.self, from: data)

            await storage.store(user)
            activeTasks[id] = nil
            
            return user
        }

        activeTasks[id] = task

return try await task.value
    }
}

What’s interesting is that the above solution is, conceptually, almost identical to how we solved a similar race condition using Combine in “Using Combine’s share operator to avoid duplicate work”. It’s one of those domains where even though the APIs we call might vary, the techniques and underlying principles are still more or less universal.

With the above changes in place, our UserLoader is now completely thread-safe, and can be called as many times as we’d like from as many threads or queues as we’d like. Our activeTasks logic will ensure that tasks will be properly reused when possible, and our UserLoader actor’s serialization mechanism will dispatch all mutations to that dictionary in a predictable, serial order.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Conclusion

So, in general, actors are a fantastic tool when we want to implement a type that supports concurrent access to its underlying state in a very safe way. However, it’s also important to remember that turning a type into an actor will require us to interact with it in an asynchronous manner, which usually does make such calls somewhat more complex (and slower) to perform — even with tools like async/await at our disposal.

While there’s certainly more to explore when it comes to Swift’s implementation of the actor pattern (it’s definitely a topic that we’ll revisit in the future), as well as other ways to make Swift code thread-safe, I hope that this article has given you a few ideas on how you could make use of actors within the code bases that you work on.

For more on Swift’s new concurrency system, check out this page, and if you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

Writing robust and predictable unit tests for asynchronous code has always been particularly challenging, given that each test method is executed completely serially, line by line (at least when using XCTest). So when using patterns like completion handlers, delegates, or even Combine, we’d always have to find our way back to our synchronous testing context after performing a given asynchronous operation.

With the introduction of async/await, though, writing asynchronous tests is starting to become much simpler in many different kinds of situations. Let’s take a look at why that is, and how async/await can also be a great testing tool even when verifying asynchronous code that hasn’t yet been migrated to Swift’s new concurrency system.

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Asynchronous test methods

Let’s say that we’re working on an app that includes the following ImageTransformer, which has an asynchronous method that lets us resize an image to a new size:

struct ImageTransformer {
    ...

    func resize(_ image: UIImage, to newSize: CGSize) async -> UIImage {
        ...
    }
}

Since the above method is marked as async, we’ll need to use await when calling it, which in turn means that those calls need to happen within a context that supports concurrency. Normally, creating such a concurrent context involves wrapping our async code within a Task, but the good news is that Apple’s built-in unit testing framework — XCTest — has been upgraded to automatically do that wrapping work for us.

So, in order to call the above ImageTransformer method within one of our tests, all that we have to do is to make that test method async, and we’ll then be able to directly use await within it:

class ImageTransformerTests: XCTestCase {
    func testResizedImageHasCorrectSize() async {
        let transformer = ImageTransformer()
        let originalImage = UIImage()
        let targetSize = CGSize(width: 100, height: 100)

        let resizedImage = await transformer.resize(
            originalImage,
            to: targetSize
        )

        XCTAssertEqual(resizedImage.size, targetSize)
    }
    
    ...
}

This is definitely one of the areas in which async/await really shines, as it lets us write asynchronous tests in a way that’s almost identical to how we’d test our synchronous code. No more expectations, partial results, or managing timeouts — really neat!

Testing throwing APIs

Since test methods can also be marked as throws, we can even use the above setup when testing asynchronous APIs that can throw errors as well. For example, here’s what our ImageTransformer test could look like if we made our resize method capable of throwing errors:

struct ImageTransformer {
    ...

    func resize(_ image: UIImage,
                to newSize: CGSize) async throws -> UIImage {
        ...
    }
}

class ImageTransformerTests: XCTestCase {
    func testResizedImageHasCorrectSize() async throws {
        let transformer = ImageTransformer()
        let originalImage = UIImage()
        let targetSize = CGSize(width: 100, height: 100)

        let resizedImage = try await transformer.resize(
            originalImage,
            to: targetSize
        )

        XCTAssertEqual(resizedImage.size, targetSize)
    }
    
    ...
}

Just like how XCTest helps us manage our non-throwing async calls, the system will handle any errors that will be generated by the above code, and will automatically turn any such errors into proper test failures.

An alternative to expectations

Swift’s new concurrency system also includes a set of continuation APIs that enable us to make other kinds of asynchronous code compatible with async/await, and while those APIs are primarily aimed at bridging the gap between our existing code and the new concurrency system, they can also be used as an alternative to XCTest’s expectations system.

For example, let’s now imagine that our ImageTransformer hasn’t yet been migrated to using async/await, and that it’s instead currently using a completion handler-based API that looks like this:

struct ImageTransformer {
    ...

    func resize(
        _ image: UIImage,
        to newSize: CGSize,
        then onComplete: @escaping (Result<UIImage, Error>) -> Void
    ) {
        ...
    }
}

Using Swift’s withCheckedThrowingContinuation function, we can actually still test the above method using async/await, without requiring us to make any modifications to ImageTransformer itself. All that we have to do is to use that continuation function to wrap our call to resize, and to then pass our completion handler’s result to the continuation object that we’re given access to:

class ImageTransformerTests: XCTestCase {
    func testResizedImageHasCorrectSize() async throws {
        let transformer = ImageTransformer()
        let originalImage = UIImage()
        let targetSize = CGSize(width: 100, height: 100)

        let resizedImage = try await withCheckedThrowingContinuation { continuation in
            transformer.resize(originalImage, to: targetSize) { result in
                continuation.resume(with: result)
            }
        }

        XCTAssertEqual(resizedImage.size, targetSize)
    }
    
    ...
}

I’ll leave it up to you to decide whether the above is better, worse, or just different compared to creating, awaiting, and then fulfilling an expectation. But regardless, it’s certainly a great tool to have in our toolbox, and even if we’re not yet ready to fully adopt Swift’s new concurrency system within our production code, perhaps using the above technique when writing tests can be a great introduction to concepts like async/await.

Linux compatibility

Although all of the tools and techniques that’s been covered in this article are fully backward compatible (starting in Xcode 13.2), at the time of writing, we’re not yet able to use async-marked test methods outside of Apple’s platforms (like on Linux) when using the Swift Package Manager’s automatic test discovery feature.

Thankfully, that’s something that we can work around using the aforementioned expectation system — for example by extending XCTestCase with a utility method that’ll let us wrap our asynchronous testing code within an async-marked closure:

extension XCTestCase {
    func runAsyncTest(
        named testName: String = #function,
        in file: StaticString = #file,
        at line: UInt = #line,
        withTimeout timeout: TimeInterval = 10,
        test: @escaping () async throws -> Void
    ) {
        var thrownError: Error?
        let errorHandler = { thrownError = $0 }
        let expectation = expectation(description: testName)

        Task {
            do {
                try await test()
            } catch {
                errorHandler(error)
            }

            expectation.fulfill()
        }

        waitForExpectations(timeout: timeout)

        if let error = thrownError {
            XCTFail(
                "Async error thrown: \(error)",
                file: file,
                line: line
            )
        }
    }
}

We could’ve also opted to mark the above runAsyncTest method as throws, and to then directly throw any error that was encountered. However, that’d either require us to always use try when calling the above method (even when testing code that can’t actually throw), or to introduce two separate overloads of it (one throwing, one non-throwing). So, in this case, we’re instead passing any thrown error to XCTFail to cause a test failure when an error was encountered.

With the above in place, we can now simply wrap any async/await-based code that we’re looking to test within a call to our new runAsyncTest method — and we’ll be able to directly use both try and await within the passed closure, just like when running our tests on Apple’s platforms:

class ImageTransformerTests: XCTestCase {
    func testResizedImageHasCorrectSize() {
        runAsyncTest {
            let transformer = ImageTransformer()
            let originalImage = Image()
            let targetSize = Size(width: 100, height: 100)

            let resizedImage = try await transformer.resize(
                originalImage,
                to: targetSize
            )

            XCTAssertEqual(resizedImage.size, targetSize)
        }
    }
    
    ...
}

Note that we’ve also made a few other tweaks to the above code in order to make it Linux-compatible, such as using a custom Image type, rather than using UIImage.

Thankfully, the above workaround shouldn’t be required for long, since I fully expect that the open source version of XCTest (that’s used on non-Apple platforms) will eventually be updated with the same async/await support that Xcode’s version has.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Conclusion

Personally, I think that async/await is quite a game-changer when it comes to writing tests that are covering asynchronous code. In fact, all the way back in 2018, I wrote an article on how to build a custom version of that pattern for use in unit tests, so I’m very delighted to now have those capabilities built into the language itself.

I hope that this article has given you a few ideas on how you could start deploying async/await within your asynchronous unit tests, and if you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

In Swift, there are essentially two main ways to check whether a given collection is empty. We can either check if the collection’s count is equal to 0, or we can use the dedicated isEmpty property.

At first, it might seem like those two ways are completely identical in terms of how they behave. In fact, it would be completely reasonable to imagine isEmpty as being implemented using a count-check — like this:

extension Collection {
    var isEmpty: Bool { count == 0 }
}

In reality, though, it turns out that the standard library’s default implementation of isEmpty looks like this:

extension Collection {
    var isEmpty: Bool { startIndex == endIndex }
}

However, certain concrete collection types then provide a custom implementation of isEmpty that’s more tailored to how that specific collection works — and here’s where things get interesting, because if we take a look at how Set implements that property, then we’ll find that it does actually use the exact same count-check that we were imagining above:

extension Set {
    var isEmpty: Bool { count == 0 }
}

What’s going on here? To answer that question, let’s take a look at the count property’s official documentation, which includes the following sentence:

Complexity: O(1) if the collection conforms to RandomAccessCollection; otherwise, O(n), where n is the length of the collection.

So it turns out that simply accessing the count property on certain collections results in an operation that’s O(n) in terms of time complexity. In other words, a complete iteration through all of the collection’s elements is performed.

An example of such a collection is one that almost every single Swift program uses — String. That’s because, in Swift, a string’s count refers to the number of human-readable characters that the string contains, but those characters are actually stored as UTF-8 code points. So, since those two formats don’t necessarily have the same length, determining a string’s exact character count does, in fact, require it to loop through all of its UTF-8 contents (which is an O(n) operation) in order to calculate the exact distance between its startIndex and endIndex:

extension String {
    var count: Int {
        distance(from: startIndex, to: endIndex)
    }
}

That’s why the Collection protocol’s default implementation of isEmpty checks whether the startIndex and endIndex properties are equal, rather than using count, since accessing those two index properties doesn’t require any actual computation to be performed.

So, to sum up — is using isEmpty and count == 0 equivalent? Sometimes, yes (for example when working with a Set), but sometimes (like in the case of String), using count to determine whether a collection is empty is incredibly wasteful — given that the entire collection will be looped through, just so that we can then check if that count is equal to 0.

My recommendation: Always use isEmpty when you want to check whether a collection is or isn’t empty. It reads better, is more self-explanatory, and is always super fast. Only use count when you’re interested in the actual number of elements in the collection.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

If we think about it, so much of the code that we write on a daily basis essentially consists of a series of data transformations. We take data in one shape or form — whether that’s actual model data, network responses, or things like user input or other events — we then run our logic on it, and ultimately end up with some form of output data that we then save, send, or display to the user.

In this article, let’s take a look at how we can utilize Swift’s built-in concurrency system when performing such data transformations using functions like forEach and map.

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Synchronous transformations

Let’s start by taking a look at an example, in which we’ve built a MovieListViewController that enables the user to mark certain movies as favorites. When that happens, our view controller uses the standard library’s forEach API to iterate over the user-selected index paths, and then calls a FavoritesManager in order to mark the movies corresponding to those index paths as favorites:

class MovieListViewController: UIViewController {
    private var movies: [Movie]
    private let favoritesManager: FavoritesManager
    private lazy var tableView = UITableView()
    ...

    func markSelectedMoviesAsFavorites() {
        tableView.indexPathsForSelectedRows?.forEach { indexPath in
            let movie = movies[indexPath.row]
            favoritesManager.markMovieAsFavorite(movie)
        }
    }
}

Besides enabling movies to be marked as favorites, our FavoritesManager also has a method that lets us load all of the Movie models that the user has previously added to their favorites — which uses the built-in map method to transform a Set of movie IDs into actual models by retrieving them from a Database:

class FavoritesManager {
    private let database: Database
    private var favoriteIDs = Set<Movie.ID>()
    ...
    
    func loadFavorites() throws -> [Movie] {
        try favoriteIDs.map { id in
            try database.loadMovie(withID: id)
        }
    }

    func markMovieAsFavorite(_ movie: Movie) {
        ...
    }
}

So far so good. But now let’s take a look at what would happen if we wanted to start using Swift’s new concurrency system to perform the above operations in an asynchronous, non-blocking manner.

Going asynchronous

To get started, let’s say that we wanted to make our FavoritesManager and Database types perform their work asynchronously, for example like this:

class FavoritesManager {
    ...
    
    func markMovieAsFavorite(_ movie: Movie) async {
        ...
    }

    func loadFavorites() async throws -> [Movie] {
        try await favoriteIDs.map { id in
            try await database.loadMovie(withID: id)
        }
    }
}

However, it turns out that the above implementation doesn’t actually compile, since the standard library’s version of map doesn’t (yet) support async closures. Thankfully, that’s something that we can add support for ourselves, thanks to the power of Swift’s extensions.

In Swift, most of the operations that we commonly perform on various collections (including APIs like forEach, map, flatMap, and so on) are implemented using Sequence protocol extensions — which in turn is a protocol that all built-in collections (like Array, Set, and Dictionary) conform to. It’s also the protocol that’s used to drive Swift’s for loops.

So, to build an async version of map, all that we’d have to do is to extend the Sequence protocol ourselves in order to add that new method:

extension Sequence {
    func asyncMap<T>(
        _ transform: (Element) async throws -> T
    ) async rethrows -> [T] {
        var values = [T]()

        for element in self {
            try await values.append(transform(element))
        }

        return values
    }
}

Note how the above method is marked with the rethrows keyword. That tells the Swift compiler to only treat our new method as throwing if the closure passed into it also throws, which gives us the flexibility to throw errors when needed, without requiring us to always call our new method with try, even when its closure doesn’t throw.

With the above in place, we can now go back and replace our loadFavorites method’s use of map with asyncMap, and our new, asynchronous FavoritesManager implementation now successfully compiles and is ready to be used:

class FavoritesManager {
    ...

    func loadFavorites() async throws -> [Movie] {
        try await favoriteIDs.asyncMap { id in
            try await database.loadMovie(withID: id)
        }
    }
}

Next, let’s say that we also wanted to turn the forEach iteration within MovieListViewController asynchronous as well, since that would let our UI remain completely responsive while our FavoritesManager is busy marking the user’s selected movies as favorites.

To do that, we’re also going to need an async version of forEach, which can be implemented in a very similar way to how we built asyncMap:

extension Sequence {
    func asyncForEach(
        _ operation: (Element) async throws -> Void
    ) async rethrows {
        for element in self {
            try await operation(element)
        }
    }
}

Before we start using our new asyncForEach method within our view controller, however, there’s one thing that we’ll need to consider — since our call to mark the user’s selected movies as favorites will now be performed asynchronously, that means that our array of movies could possibly be mutated while our iteration is being performed.

So, to prevent bugs or crashes from happening in that kind of situation, let’s capture our movies array by value when we call asyncForEach, so that we’ll keep operating on the same array throughout our entire iteration:

class MovieListViewController: UIViewController {
    ...

    func markSelectedMoviesAsFavorites() {
        Task {
            await tableView.indexPathsForSelectedRows?.asyncForEach { 
                [movies] indexPath in

                let movie = movies[indexPath.row]
                await favoritesManager.markMovieAsFavorite(movie)
            }
        }
    }
}

To learn more about closure capturing in Swift, check out “Swift’s closure capturing mechanics”.

With those changes in place, we’ve now successfully turned two potentially heavy data transformation operations into asynchronous, non-blocking calls — which in turn will make our UI remain responsive regardless of how long those calls take to complete.

Concurrency

There’s one more thing that we could do to potentially speed up the above operations, though, and that’s to make them execute in parallel, rather than in sequence. Because even though our operations are now asynchronous in relation to other code, they’re actually still completely sequential in terms of how they’re executed — given that both asyncForEach and asyncMap always await the result of one operation before continuing with the next.

So, to enable us to perform a given forEach call in a way that executes all of its operations in parallel, let’s write a new, concurrent version of it that utilizes the built-in TaskGroup API:

extension Sequence {
    func concurrentForEach(
        _ operation: @escaping (Element) async -> Void
    ) async {
        // A task group automatically waits for all of its
        // sub-tasks to complete, while also performing those
        // tasks in parallel:
        await withTaskGroup(of: Void.self) { group in
            for element in self {
                group.addTask {
    await operation(element)
}
            }
        }
    }
}

To learn more about TaskGroup, check out “Using Swift’s concurrency system to run multiple tasks in parallel”.

Now, we’re definitely not going to want to perform all of our forEach calls concurrently (because we have to remember that spreading things out over multiple concurrent tasks and threads also comes with its own overhead and delays). However, in the case of marking movies as favorites within our MovieListViewController, we might be able to achieve a speed gain if the user ends up selecting a large number of movies, which we would now be able to iterate over concurrently.

So let’s replace our previous use of asyncForEach with a call to our new concurrentForEach method — like this:

class MovieListViewController: UIViewController {
    ...

    func markSelectedMoviesAsFavorites() {
        Task {
            await tableView.indexPathsForSelectedRows?.concurrentForEach {
                [movies, favoritesManager] indexPath in

                let movie = movies[indexPath.row]
                await favoritesManager.markMovieAsFavorite(movie)
            }
        }
    }
}

Note how we’re now also capturing a reference to our FavoritesManager within our closure. That’s because we’re now dealing with an escaping closure, which requires us to make all self-related captures explicit. So, rather than capturing self, we instead only capture the actual object that we need to perform our operation.

With the above change in place, our favorite marking logic will now operate on multiple movies in parallel when needed, which could potentially give us a significant speed boost. Of course (like with most things related to performance), whether we want to use asyncForEach or concurrentForEach is something that we’ll have to decide based on real-life performance metrics within each specific situation, as there’s no universal rule as to whether something could benefit from being executed concurrently.

Another thing that’s important to consider before making a given set of operations execute concurrently is whether our underlying data supports concurrent access. We’ll take a much closer look at that topic — including how we can use Swift’s actor types to enforce serial access to mutable state — in upcoming articles.

Moving on to the mapping operation within our FavoritesManager, let’s now take a look at how we could also enable that iteration to be performed concurrently as well. That’ll require a new, concurrent version of map, which we’ll call concurrentMap.

However, unlike concurrentForEach, this new method won’t use a TaskGroup, since that API doesn’t give us any guarantees in terms of completion order, meaning that we’d potentially end up with an output array that has a different order than our input. So, instead, we’ll start by creating an async Task for each element, and we’ll then use our previous asyncMap method to await the results of each of those tasks in-order:

extension Sequence {
    func concurrentMap<T>(
        _ transform: @escaping (Element) async throws -> T
    ) async throws -> [T] {
        let tasks = map { element in
            Task {
    try await transform(element)
}
        }

        return try await tasks.asyncMap { task in
            try await task.value
        }
    }
}

An alternative approach to the above would be to use a TaskGroup in combination with a dictionary that’d keep track of our output order. However, not only would that code be more complicated, it also wouldn’t give us any significant performance gains over our current implementation.

Using our new concurrentMap method, we’re now able to have our FavoritesManager load all favorites in a completely concurrent manner — which will make that operation scale really nicely as the user adds more and more movies to their list of favorites:

class FavoritesManager {
    ...

    func loadFavorites() async throws -> [Movie] {
        try await favoriteIDs.concurrentMap { [database] id in
            try await database.loadMovie(withID: id)
        }
    }
}

With that last piece in place, we’ve now not only given our code an async makeover, but we’ve also made it execute concurrently as well — and in the process we’ve built four completely reusable Sequence APIs — asyncForEach, concurrentForEach, asyncMap, and concurrentMap.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Conclusion

I hope that this article has given you a few new insights into how certain Swift iterations can be turned into async or concurrent operations using Swift’s new concurrency system. Again, it’s always important to consider when (and when not) to deploy concurrency, and to try to base those decisions on real-life performance metrics. After all, completely synchronous code will likely always remain the simplest to implement, debug, and maintain.

If you’re interested in using the new forEach and map variants introduced in this article, as well as similar versions of compactMap and flatMap — then check out CollectionConcurrencyKit, a new open source Swift package that adds those APIs to all Swift collections. And if you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

One of the benefits of Swift’s built-in concurrency system is that it makes it much easier to perform multiple, asynchronous tasks in parallel, which in turn can enable us to significantly speed up operations that can be broken down into separate parts.

In this article, let’s take a look at a few different ways to do that, and when each of those techniques can be especially useful.

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

From asynchronous to concurrent

To get started, let’s say that we’re working on some form of shopping app that displays various products, and that we’ve implemented a ProductLoader that lets us load different product collections using a series of asynchronous APIs that look like this:

class ProductLoader {
    ...

    func loadFeatured() async throws -> [Product] {
        ...
    }
    
    func loadFavorites() async throws -> [Product] {
        ...
    }
    
    func loadLatest() async throws -> [Product] {
        ...
    }
}

Although each of the above methods will likely be called separately most of the time, let’s say that within certain parts of our app, we’d also like to form a combined Recommendations model that contains all of the results from those three ProductLoader methods:

extension Product {
    struct Recommendations {
        var featured: [Product]
        var favorites: [Product]
        var latest: [Product]
    }
}

One way to do that would be to call each loading method using the await keyword, and to then use the results of those calls to create an instance of our Recommendations model — like this:

extension ProductLoader {
    func loadRecommendations() async throws -> Product.Recommendations {
        let featured = try await loadFeatured()
let favorites = try await loadFavorites()
let latest = try await loadLatest()
        
        return Product.Recommendations(
            featured: featured,
            favorites: favorites,
            latest: latest
        )
    }
}

The above implementation certainly works — however, even though our three loading operations are all completely asynchronous, they’re currently being performed in sequence, one after the other. So, although our top-level loadRecommendations method is being performed concurrently in relation to our app’s other code, it’s actually not utilizing concurrency to perform its internal set of operations just yet.

Since our product loading methods don’t depend on each other in any way, there’s really no reason to perform them in sequence, so let’s take a look at how we could make them execute completely concurrently instead.

An initial idea on how to do that might be to reduce the above code into a single expression, which would enable us to use a single await keyword to wait for each of our operations to finish:

extension ProductLoader {
    func loadRecommendations() async throws -> Product.Recommendations {
        try await Product.Recommendations(
            featured: loadFeatured(),
            favorites: loadFavorites(),
            latest: loadLatest()
        )
    }
}

However, even though our code might now look concurrent, it’ll actually still executed completely sequentially, just like before.

Instead, we’ll need to utilize Swift’s async let bindings in order to tell the concurrency system to perform each of our loading operations in parallel. Using that syntax enables us to start an asynchronous operation in the background, without requiring us to immediately wait for it to complete.

If we then combine that with a single await keyword at the point where we’ll actually use our loaded data (that is, when forming our Recommendations model), then we’ll get all of the benefits of executing our loading operations in parallel without having to worry about things like state management or data races:

extension ProductLoader {
    func loadRecommendations() async throws -> Product.Recommendations {
        async let featured = loadFeatured()
async let favorites = loadFavorites()
async let latest = loadLatest()
        
        return try await Product.Recommendations(
            featured: featured,
            favorites: favorites,
            latest: latest
        )
    }
}

Very neat! So async let provides a built-in way to run multiple operations concurrently when we have a known, finite set of tasks to perform. But what if that’s not the case?

Task groups

Now let’s say that we’re working on an ImageLoader that lets us load images over the network. To load a single image from a given URL, we might use a method that looks like this:

class ImageLoader {
    ...

    func loadImage(from url: URL) async throws -> UIImage {
        ...
    }
}

To also make it simple to load a series of images all at once, we’ve also created a convenience API that takes an array of URLs and asynchronously returns a dictionary of images keyed by the URLs that they were downloaded from:

extension ImageLoader {
    func loadImages(from urls: [URL]) async throws -> [URL: UIImage] {
        var images = [URL: UIImage]()
        
        for url in urls {
            images[url] = try await loadImage(from: url)
        }
        
        return images
    }
}

Now let’s say that, just like when working on our ProductLoader before, we’d like to make the above loadImages method execute concurrently, rather than downloading each image in sequence (which is currently the case, given that we’re directly using await when calling loadImage within our for loop).

However, this time we won’t be able to use async let, given that the number of tasks that we need to perform isn’t known at compile time. Thankfully, there’s also tool within the Swift concurrency toolbox that lets us execute a dynamic number of tasks in parallel — task groups.

To form a task group, we either call withTaskGroup or withThrowingTaskGroup, depending on whether we’d like to have the option to throw errors within our tasks. In this case, we’ll pick the latter, since our underlying loadImage method is marked with the throws keyword.

We’ll then iterate over each of our URLs, just like before, only this time we’ll add each image loading task to our group, rather than directly waiting for it to complete. Instead, we’ll await our group results separately, after adding each of our tasks, which will allow our image loading operations to execute completely concurrently:

extension ImageLoader {
    func loadImages(from urls: [URL]) async throws -> [URL: UIImage] {
        try await withThrowingTaskGroup(of: (URL, UIImage).self) { group in
            for url in urls {
                group.addTask{
    let image = try await self.loadImage(from: url)
    return (url, image)
} 
            }
            
            var images = [URL: UIImage]()
            
            for try await (url, image) in group {
    images[url] = image
}
            
            return images
        }
    }
}

To learn more about the above for try await syntax, and async sequences in general, check out “Async sequences, streams, and Combine”.

Just like when using async let, a huge benefit of writing our concurrent code in a way where our operations don’t directly mutate any kind of state is that doing so lets us completely avoid any kind of data race issues, while also not requiring us to introduce any locking or serialization code into the mix.

So, when possible, it’s most often a good approach to let each of our concurrent operations return a completely separate result, and to then await those results sequentially in order to form our final data set.

We’ll take a much closer look at other ways to avoid data races (for example by using Swift’s new actor types) in future articles.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.

Conclusion

It’s important to remember that just because a given function is marked as async doesn’t necessarily mean that it performs its work concurrently. Instead, we have to deliberately make our tasks run in parallel if that’s what we want to do, which really only makes sense when performing a set of operations that can be run independently.

I hope that this article has given you a few ideas on how to do just that, and feel free to reach out via email if you have any questions, comments, or feedback.

Also, if you found this article useful, then I’d be really grateful if you could either check out the above sponsor, or share this article with a friend, as doing so really helps support my work.

Thanks for reading!

Although Swift 5.5’s new concurrency system is becoming backward compatible in Xcode 13.2, some of the built-in system APIs that make use of these new concurrency features are still only available on iOS 15, macOS Monterey, and the rest of Apple’s 2021 operating systems.

For example, if we try to use the new async/await-favored version of the URLSession data task API within an app that’s also available on earlier operating system versions, then we’ll get a compiler error:

struct ModelLoader<Model: Decodable> {
    var session = URLSession.shared
    var decoder = JSONDecoder()

    func loadModel(from url: URL) async throws -> Model {
        // Error: 'data(from:delegate:)' is only available in iOS 15.0 or newer
        let (data, _) = try await session.data(from: url)
        let model = try decoder.decode(Model.self, from: data)
        return model
    }
}

Thankfully, the above problem is something that we can fix ourselves, since Swift’s new concurrency system ships with a continuation mechanism that lets us retrofit existing code with async/await support.

Here’s how we could use that mechanism to replicate the above async/await-powered URLSession API in order to make it available all the way back to iOS 13:

@available(iOS, deprecated: 15.0, message: "Use the built-in API instead")
extension URLSession {
    func data(from url: URL) async throws -> (Data, URLResponse) {
        try await withCheckedThrowingContinuation { continuation in
            let task = self.dataTask(with: url) { data, response, error in
                guard let data = data, let response = response else {
                    let error = error ?? URLError(.badServerResponse)
                    return continuation.resume(throwing: error)
                }

                continuation.resume(returning: (data, response))
            }

            task.resume()
        }
    }
}

Note how we add a custom deprecation annotation to the above extension, so that we’ll get a compiler warning whenever we’ll increase our app’s deployment target to iOS 15 or above.

With the above in place, the compiler error within our ModelLoader is now gone, as we’re now able to easily perform URLSession-based network calls using async/await, even within a backward-compatible code base.

It’s also important to point out that the above kind of work is not required for all async-marked system APIs. In fact, those that were automatically translated from completion handler-based Objective-C APIs are automatically made backward compatible — just like the concurrency features themselves, as well as standard library types like Task and AsyncStream.

To learn more about the above continuation system, and other techniques like it, check out “Connecting async/await to other Swift code”.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for developers who want to become complete senior iOS developers. This virtual event includes lectures, mentoring sessions, and step-by-step instructions. Click to learn more.