async let vs Task group

Vitaly BatrakovVitaly Batrakov
13 min read

Hey iOS folks!

In Swift, Structured Concurrency tasks are represented by async let and task groups. While both serve the same purpose, their lifecycles work slightly differently. Today, we'll explore these differences with examples.

⚠️ : I assume you are familiar with the basic concepts of Swift Concurrency. If not, you can start here.

async let

With async let, you can start multiple tasks that run concurrently.

func fetchData() async {
    async let first = fetchPart1()
    async let second = fetchPart2()
    async let third = fetchPart3()

    let result = await (first, second, third)

    print(result)
}

Although it is not explicitly stated in code, three new child tasks were created here, one for each async let.

async let can work with both sync and async functions:

func fetchPart1() -> Int { ... }
func fetchPart2() async -> Int { ... }

Moreover, it actually works with any expression:

async let number = 123
async let str = "Hello World!"

⁉️ : How it works? Under the hood, it wraps the initializer expression in a separate, concurrently executing child task. The child task starts running as soon as the async let is encountered, using the default concurrent executor.

async let first = fetchPart1()
async let second = fetchPart2()
async let number = 123
async let str = "Hello World!"

// is converted into something like this:

let first = ChildTask {
    fetchPart1()
}
let second = ChildTask {
    await fetchPart2()
}
let number = ChildTask {
    123
}
let str = ChildTask {
    "Hello World!"
}

The lifecycle of async let is bound to the local scope where it is created, such as a function, closure, or do/catch block. When execution exits this scope — either normally or due to an error — all tasks created with async let will be implicitly cancelled and awaited.

⚠️ : Even if you don’t explicitly await an async let, it will be awaited at the end of the local scope. This means an async let group always runs as long as its longest-running child task.

⚠️ : Keep in mind that cancelling the task does not stop the task, it only marks that results are not gonna be needed. Swift concurrency uses a cooperative cancellation model. Each task checks whether it has been canceled at the appropriate points in its execution (with Task.isCancelled or Task.checkCancellation()), and responds to cancellation appropriately. Depending on what work the task is doing, responding to cancellation usually means one of the following:

  • Throwing an error like CancellationError

  • Returning nil or an empty collection

  • Returning the partially completed work

Another important point to highlight can be observed here:

async let result1 = task1()
async let result2 = task2()

let results = await (result1, result2)

Pay close attention - it may not be immediately obvious, but while child tasks created with async let run concurrently, awaiting them in a tuple is sequential. Swift evaluates tuple elements from left to right, following its expression evaluation rules.

To clarify, all the expressions below are equivalent in terms of the order of sequential awaiting each result:

await (result1, result2)
// or
(await result1, await result2)
// or
await result1
await result2
// awaiting order will be the same

This can lead to a tricky behavior when child tasks throw errors, but we will discuss that later in the error propagation edge cases section.

💡: I would like to encourage you to read async let proposal for more insights, such as why async var is not allowed or why passing an async let to an escaping closure is prohibited.

TaskGroup

If you need to create a dynamic number of concurrent tasks, a task group is the better choice:


func fetchData(count: Int) async {
    var results = [String]()

    await withTaskGroup(of: String.self) { group in
        for index in 0..<count {
            group.addTask {
                await self.fetchPart(index)
            }
        }
        for await result in group {
            results.append(result)
        }
    }

    print(results)
}

Keep in mind that group: TaskGroup param inside task group closure is actually AsyncSequence. So instead of for await we can use another iterator approach with .next() method that produces the same result:

while let result = await group.next() {
    results.append(result)
}

Lifecycle of task group is bound to the closure inside withTaskGroup function. But logic is a bit more complex than with async let:

  • If execution leaves the closure normally without awaiting child tasks, they will be implicitly awaited (but not cancelled).

  • If execution leaves the closure due to an error, child tasks will be both implicitly cancelled and awaited.

For example, if we remove the for await part from the task group code above, it won’t just go to printing the results (which would be empty, obviously). Instead, it will await all child tasks first until the each of them is fully completed.

💡 : An important difference from async let is the order in which results are awaited. Unlike async let, where the order is code-driven, a task group follows a "first finished → first handled" approach, based on how an AsyncSequence works.

Lifecycle edge cases

We briefly covered the lifecycle logic for implicit cancellation and awaiting of structured tasks.

The lifecycle of async let is bound to the local scope where it is created, such as a function, closure, or do/catch block. When execution exits this scope — either normally or due to an error — all tasks created with async let will be implicitly cancelled and awaited.

Lifecycle of task group is bound to the closure inside withTaskGroup function. But logic is a bit more complex than with async let:

  • If execution leaves the closure normally without awaiting child tasks, they will be implicitly awaited (but not cancelled).

  • If execution leaves the closure due to an error, child tasks will be both implicitly cancelled and awaited.

It may seem a bit complicated already, so let’s try to clarify that with examples.

⚠️ Disclaimer: Not awaiting structured tasks may not be a good idea in some cases. Even if you want to create parallel "fire and forget" operations without caring about the results, structured tasks might not work as you expected. Remember that both async let and task groups have implicit awaiting, meaning you'll always wait for the longest child task to complete before proceeding. This makes true "fire and forget" behavior impossible unless you wrap the tasks in an unstructured root task or simply use an unstructured tasks instead.

What if we don’t await child tasks and leave the local scope normally?

async let

When we we leave local scope normally without awaiting child tasks, async let’s child tasks will be implicitly cancelled and implicitly awaited:

func fast() async {
    print("fast started")
    do {
        /// If current task is canceled before the time ends,
        /// Task.sleep function throws `CancellationError`.
        try await Task.sleep(nanoseconds: 5_000_000_000)
    } catch {
        print("fast cancelled", error)
    }
    print("fast ended")
}

func slow() async {
    print("slow started")
    do {
        try await Task.sleep(nanoseconds: 10_000_000_000)
    } catch {
        print("slow cancelled", error)
    }
    print("slow ended")
}

func go() async {
    async let f = fast()
    async let s = slow()

    print("leaving local scope")
}

//    Prints:
//    leaving local scope
//    fast started
//    slow started
//    slow cancelled CancellationError()
//    slow ended
//    fast cancelled CancellationError()
//    fast ended

Keep in mind that it will implicitly cancel and await tasks in reverse order, starting from the last defined async let child task. In this example, it implicitly cancels and awaits the slow task first, and then the fast task will also be implicitly cancelled and awaited.

If your last defined async let task will take long time to finish and will not handle cancellation properly, previous ones will not be cancelled until first one is completed, which will affect total group completion time. For example, if we make slow one “more slower” and ignore cancellation for it:

func slow() async {
    print("slow started")
    do {
        try await Task.sleep(nanoseconds: 10_000_000_000)
    } catch {
        print("slow cancelled", error)
    }
    sleep(10) // this sleep will ignore cancellation
    print("slow ended")
}

// fast and go funcs are the same

//    Prints:
//    leaving local scope
//    fast started
//    slow started
//    slow cancelled CancellationError()
//    fast ended // after 5 secs
//    slow ended // after 10 sec

As you can see, this time fast wasn’t even cancelled this time, because it managed to complete before slow is completed (slow was implicitly cancelled and implicitly awaited).

Task group

When we leave Task group closure normally without awaiting child tasks, task group’s child tasks will be implicitly awaited but not cancelled:

await withTaskGroup(of: Void.self) { group in
    group.addTask {
        await fast()
    }
    group.addTask {
        await slow()
    }

    print("leaving task group closure")
}

// fast and slow funcs are the same

//    Prints:
//    leaving task group closure
//    fast started
//    slow started
//    fast ended // after 5 sec
//    slow ended // after 20 sec

What if we do not await and leave the local scope due to error?

💡: Remember, that if child task is not awaited explicitly, throwing an error inside child task will not be propagated and caught outside (Rule: not awaited explicitly → not propagated). Task group will only implicitly await it’s child tasks in this case (no implicit cancellation) as it did in previous case without error.

If we don’t await child tasks but error is somehow thrown inside async let’s local scope or Task group’s closure and it leaves the scope/closure uncaught, child tasks will be implicitly cancelled and implicitly awaited, and after that error will be propagated outside:

try await withThrowingTaskGroup(of: Void.self) { group in
    group.addTask {
        try await fast()
    }
    group.addTask {
        try await slow()
    }

    print("leaving task group closure")
    throw TestError()
}

//    Prints:
//    leaving task group closure
//    fast started
//    fast cancelled CancellationError()
//    fast ended
//    slow started
//    slow cancelled CancellationError()
//    slow ended
//    external catch TestError() // error caught outside task group closure

Opposite to async let where the implicit cancellation + awaiting happens in order opposite to async let’s declaration, for task group:

  • there is not defined order for cancellation and awaiting (random order)

  • it implicitly cancels all child tasks first, then implicitly awaits all of them.

We can check that in this example:

func fast() async throws {
    print("fast started")
    do {
        try await Task.sleep(nanoseconds: 5_000_000_000)
    } catch {
        print("fast cancelled", error)
    }
    sleep(5) // this sleep will ignore cancellation
    print("fast ended")
}

func slow() async throws {
    print("slow started")
    do {
        try await Task.sleep(nanoseconds: 10_000_000_000)
    } catch {
        print("slow cancelled", error)
    }
    sleep(10) // this sleep will ignore cancellation
    print("slow ended")
}

// code of withThrowingTaskGroup is the same as previous

//    Prints:
//    leaving task group closure
//    slow started
//    fast started
//    fast cancelled CancellationError()
//    slow cancelled CancellationError()
//    fast ended // after 5 seconds
//    slow ended // after 10 seconds
//    external catch TestError() // error caught outside task group closure

As you can see, it implicitly cancels both fast and slow first, then awaits fast and slow after that.

What if we await child tasks and error is handled locally?

async let

async let’s child tasks will be implicitly cancelled and implicitly awaited.

Let’s say we throw an error in fast and slow now:

func fast() async throws {
    print("fast started")
    do {
        try await Task.sleep(nanoseconds: 5_000_000_000)
    } catch {
        print("fast cancelled", error)
    }
    print("fast ended")
    throw TestError1() // <- HERE
}
func slow() async throws {
    print("slow started")
    do {
        try await Task.sleep(nanoseconds: 10_000_000_000)
    } catch {
        print("slow cancelled", error)
    }
    print("slow ended")
    throw TestError2() // <- HERE
}

async let f = fast()
async let s = slow()
do {
    try await (f, s)
} catch {
    print("caught error locally", error)
}
print("leaving local scope")

//    Prints:
//    fast started
//    slow started
//    fast ended // after 5 seconds
//    caught error locally TestError1()
//    leaving local scope
//    slow cancelled CancellationError()
//    slow ended

See how TestError2 from slow wasn’t even caught because of await order for async let’s (we await fast first and slow second). We caught TestError1 and left do block, leaving slow unawaited, so it was implicitly cancelled and awaited after we left the local scope.

Order of implicit cancellation + awaiting is the same as before for async let - reversed to async let declaration order.

Keep in mind that the order of awaiting can directly affect the order of error propagation. If we await the slow task first, TestError2 will be propagated, even though the fast task ended first and threw an error first — it was never caught because fast was never awaited on practice:

try await (s, f) // changed the order of awaits

//    Prints:
//    fast started
//    slow started
//    fast ended // after 5 seconds
//    slow ended // after 10 seconds
//    caught error locally TestError2()
//    leaving local scope

Task group

Task group’s child tasks will be implicitly awaited but not cancelled.

Let’s say again that we throw an error in fast and slow :

try await withThrowingTaskGroup(of: Void.self) { group in
    group.addTask {
        try await fast()
    }
    group.addTask {
        try await slow()
    }
    do {
        for try await result in group {
            print("Received: \(result)")
        }
    } catch {
        print("caught error locally", error)
    }
    print("leaving task group closure")
}

// fast and slow are the same as in previous example

//    Prints:
//    fast started
//    slow started
//    fast ended // after 5 secs
//    caught error locally TestError1()
//    leaving task group closure
//    slow ended // after 10 secs

When fast throws TestError1, we catch it locally and after we leave the task group closure, slow is implicitly awaited. Even though slow throws TestError2 error eventually, we didn’t catch it (because it is not awaited anymore → not propagated).

What if we await child tasks and error is propagated outside local scope?

async let

async let’s child tasks are implicitly cancelled and implicitly awaited.

Let’s remove local do/catch block to test that case:

async let f = fast()
async let s = slow()
try await (f, s)
print("leaving local scope")

// fast and slow are the same as in previous example

//    Prints:
//    slow started
//    fast started
//    fast ended // after 5 secs
//    slow cancelled CancellationError()
//    slow ended
//    extenral catch TestError1()

After fast throws TestError1 , execution jumps to external catch block and leaves slow unawaited. slow is implicitly cancelled and implicitly awaited. TestError1 is propagated and caught outside of the local scope.

Task group

task group’s child tasks are implicitly cancelled and implicitly awaited.

Let’s remove local do/catch block to test that case as well:

try await withThrowingTaskGroup(of: Void.self) { group in
    group.addTask {
        try await fast()
    }
    group.addTask {
        try await slow()
    }
    for try await result in group { // Removed do/catch here
        print("Received: \\(result)")
    }
    print("leaving task group closure")
}

// fast and slow are the same as in previous example

//    Prints:
//    slow started
//    fast started
//    fast ended // after 5 secs
//    slow cancelled CancellationError()
//    slow ended
//    external catch TestError1()

After fast throws TestError1 , execution jumps to external catch block and leaves slow unawaited. slow is implicitly cancelled and awaited. TestError1 is propagated and caught outside of task group closure.

Conclusion

⚠️ : If you have error propagation logic, a task group may be a better choice than async let. The task group’s "first thrown, first caught" logic is more predictable and won’t be affected by the order of awaiting, unlike async let, where error propagation can be influenced by the awaiting order. Task groups are more suitable for cases where you want to "fail fast" compared to async let.

As you could notice, there were quite a few cases to consider. Hopefully, your brain isn’t boiling just yet. Luckily, the logic behind these cases is simpler than it may seem. To make it more visual and easier to understand, we can build a diagram:

If you spot any inaccuracies or misleading points in this post, please share them in the comments - your feedback helps everyone!

Good luck on your Swift Concurrency journey! See you in the next articles!

1
Subscribe to my newsletter

Read articles from Vitaly Batrakov directly inside your inbox. Subscribe to the newsletter, and don't miss out.

iOSSwiftconcurrencySwift Concurrencyasync letTask Group

Written by

Vitaly Batrakov
Vitaly Batrakov

Senior iOS Engineer at Skip