SwiftUI offers several different ways for us to create stacks of overlapping views that can be arranged along the Z axis, which in turn enables us to define various kinds of overlays and backgrounds for the views that we build. Let’s explore some of those built-in stacking methods and what sort of UIs that they enable us to create.

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

ZStacks

Like its name implies, SwiftUI’s ZStack type is the Z-axis equivalent of the horizontally-oriented HStack and the vertical VStack. When placing multiple views within a ZStack, they’re (by default) rendered back-to-front, with the first view being placed at the back. For example, here we’re creating a full-screen ContentView, which renders a gradient with a text stacked on top:

Preview

struct ContentView: View {
    var body: some View {
        ZStack {
            LinearGradient(
                colors: [.orange, .red],
                startPoint: .topLeading,
                endPoint: .bottomTrailing
            )
            .ignoresSafeArea()

            Text("Swift by Sundell")
                .foregroundColor(.white)
                .font(.title)
        }
    }
}

Tip: You can use the above code sample’s PREVIEW button to see what it’ll look like when rendered.

The reason that the above ContentView is rendered across all of the available screen space is because a LinearGradient will always occupy as much space as possible by default, and since a any stack’s size defaults to the total size of its children, that leads to our ZStack being resized to occupy that same full-screen space.

The background modifier

However, sometimes we might not want a given background to stretch out to fill all available space, and while we could address that by applying various sizing modifiers to our background view, SwiftUI ships with a built-in tool that automatically resizes a given view’s background to perfectly fit its parent — the background modifier.

Here’s how we could use that modifier to instead apply our LinearGradient background directly to our Text-based view, which makes that background take on the exact same size as our text itself (including its padding):

Preview

struct ContentView: View {
    var body: some View {
        Text("Swift by Sundell")
            .foregroundColor(.white)
            .font(.title)
            .padding(35)
            .background(
    LinearGradient(
        colors: [.orange, .red],
        startPoint: .topLeading,
        endPoint: .bottomTrailing
    )
)
    }
}

The reason that the padding is included when calculating our background’s size in the above example is because we’re applying the padding modifier before adding our background. To learn more about that, check out “When does the order of SwiftUI modifiers matter, and why?”.

One thing that’s important to point out, though, is that even though a view’s background does indeed get resized according to the parent view itself, there’s no form of clipping applied by default. So if we were to give our LinearGradient an explicit size that’s larger than its parent, then it’ll actually be rendered out of bounds (which we can clearly demonstrate by adding a border to our main Text-based view):

Preview

struct ContentView: View {
    var body: some View {
        Text("Swift by Sundell")
            .foregroundColor(.white)
            .font(.title)
            .padding(35)
            .background(
                LinearGradient(
                    colors: [.orange, .red],
                    startPoint: .topLeading,
                    endPoint: .bottomTrailing
                )
                .frame(width: 300, height: 300)
            )
            .border(Color.blue)
    }
}

There are multiple ways to apply clipping to a view, though, which would remove the above sort of out-of-bounds rendering. For example, we could use either the clipped or clipShape modifier to tell the view to apply a clipping mask to its bounds, or we could give our view rounded corners (which also introduces clipping) — like this:

Preview

struct ContentView: View {
    var body: some View {
        Text("Swift by Sundell")
            .foregroundColor(.white)
            .font(.title)
            .padding(35)
            .background(
                LinearGradient(
                    colors: [.orange, .red],
                    startPoint: .topLeading,
                    endPoint: .bottomTrailing
                )
                .frame(width: 300, height: 300)
            )
            .cornerRadius(20)
    }
}

Of course, the simplest way to avoid drawing a background outside of the bounds of its parent view is to simply let the SwiftUI layout system automatically determine the size of each background. That way, the size of a given background will always perfectly match the size of its parent view.

Assigning overlays

SwiftUI also supports adding overlays to views as well, which essentially act as the inverse of backgrounds — in that they’re rendered on top of their parent views (with the same sizing behaviors as we explored above).

Both overlays and backgrounds also support alignment customization, which lets us decide how such a view should be placed within its parent’s coordinate system. For views that are fully resizable (like our above LinearGradient), the alignment doesn’t matter (since those views will be resized to fit their parent view anyway), but for smaller views, specifying an alignment lets us move a view to any of its parent’s corners.

For example, here’s how we could add a star image overlay to the top-trailing corner of our ContentView:

Preview

struct ContentView: View {
    var body: some View {
        Text("Swift by Sundell")
            .foregroundColor(.white)
            .font(.title)
            .padding(35)
            .background(
                LinearGradient(
                    colors: [.orange, .red],
                    startPoint: .topLeading,
                    endPoint: .bottomTrailing
                )
            )
            .overlay(starOverlay, alignment: .topTrailing)
            .cornerRadius(20)
    }

    private var starOverlay: some View {
        Image(systemName: "star")
    .foregroundColor(.white)
    .padding([.top, .trailing], 5)
    }
}

Specifying an alignment for a background is done the exact same way, by passing an alignment argument when using the background modifier.

An overlay or background also inherits all of its parent’s environment values. In the case of our ContentView example, that means that we don’t actually have to apply the same foregroundColor modifier twice, like we’re doing above (since foreground colors automatically become part of the SwiftUI environment). So if we instead apply that modifier after we’ve added our overlay, then that same color will be applied to both our text and our star icon:

struct ContentView: View {
    var body: some View {
        Text("Swift by Sundell")
            .font(.title)
            .padding(35)
            .background(
                LinearGradient(
                    colors: [.orange, .red],
                    startPoint: .topLeading,
                    endPoint: .bottomTrailing
                )
            )
            .overlay(starOverlay, alignment: .topTrailing)
            .foregroundColor(.white)
            .cornerRadius(20)
    }

    private var starOverlay: some View {
        Image(systemName: "star")
            .padding([.top, .trailing], 5)
    }
}

Conditional overlays and backgrounds

Sometimes, though, we might only want to apply a given overlay (or background) under certain conditions. For example, let’s say that we wanted to add a second overlay that displays a progress view while our ContentView is in some form of loading state.

Since we don’t want to introduce any if/else control flow to our ContentView itself (since that’ll essentially make SwiftUI treat those two code paths as two separate views), we could create such a conditional overlay by defining a new @ViewBuilder-marked computed property — like this:

Preview

struct ContentView: View {
    @State private var isLoading = true

    var body: some View {
        Text("Swift by Sundell")
            .font(.title)
            .padding(35)
            .background(
                LinearGradient(
                    colors: [.orange, .red],
                    startPoint: .topLeading,
                    endPoint: .bottomTrailing
                )
            )
            .overlay(starOverlay, alignment: .topTrailing)
            .overlay(loadingOverlay)
            .foregroundColor(.white)
            .cornerRadius(20)
    }
    
    ...

    @ViewBuilder private var loadingOverlay: some View {
        if isLoading {
    ProgressView()
}
    }
}

Note that it’s perfectly fine to apply multiple overlays or backgrounds to a single view. They’ll simply be stacked on top of each other, just like when using a ZStack.

However, our ProgressView isn’t currently very easy to see, and could definitely use a background of its own. In this case, we do actually want that background to occupy the same space as our ContentView itself, which can be done using the ZStack-based technique that we initially explored in this article:

Preview

struct ContentView: View {
    ...

    @ViewBuilder private var loadingOverlay: some View {
        if isLoading {
            ZStack {
    Color(white: 0, opacity: 0.75)
    ProgressView().tint(.white)
}
        }
    }
}

Note that if our app supported iOS 14 or earlier, then we’d have to apply CircularProgressViewStyle(tint: .white) to our progress view (using the progressViewStyle modifier), rather than using tint, since that modifier was introduced in iOS 15.

iOS 15 also introduced new APIs for defining backgrounds and overlays using @ViewBuilder-marked closures. The benefit of those new APIs is that they let us use control flow (like if statements) inline within those modifier calls, which in our case would enable us to easily define both of our two overlays right within our view’s body:

struct ContentView: View {
    @State private var isLoading = true

    var body: some View {
        Text("Swift by Sundell")
            .font(.title)
            .padding(35)
            .background(
                LinearGradient(
                    colors: [.orange, .red],
                    startPoint: .topLeading,
                    endPoint: .bottomTrailing
                )
            )
            .overlay(alignment: .topTrailing) {
    Image(systemName: "star")
        .padding([.top, .trailing], 5)
}
.overlay {
    if isLoading {
        ZStack {
            Color(white: 0, opacity: 0.75)
            ProgressView().tint(.white)
        }
    }
}
            .foregroundColor(.white)
            .cornerRadius(20)
    }
}

That’s not to say that delegating certain accessory view definitions to separate properties isn’t a good idea — in fact, that’s an excellent pattern that can help us break certain massive body properties up into more manageable pieces (without having to define a ton of new view types). But sometimes, defining everything inline might be the way to go, especially for simpler overlays, and the new closure-based background and overlay modifiers certainly make doing so much easier.

Closure-based backward compatibility

It is a bit of a shame that those new closure-based APIs are iOS 15-only, though, so let’s wrap up this article by fixing that. It’s important to remember just how composable SwiftUI was designed to be, and that most of the convenience APIs that have been introduced recently are merely composing some of SwiftUI’s older building blocks — which is something that we can do ourselves as well.

So here’s how we could use the same technique as we previously used to make certain async/await-based system APIs backward compatible — that is, by defining an extension that overrides the system-provided APIs with our own, iOS 13-compatible versions:

@available(iOS, deprecated: 15.0, message: "Use the built-in APIs instead")
extension View {
    func background<T: View>(
        alignment: Alignment = .center,
        @ViewBuilder content: () -> T
    ) -> some View {
        background(Group(content: content), alignment: alignment)
    }

    func overlay<T: View>(
        alignment: Alignment = .center,
        @ViewBuilder content: () -> T
    ) -> some View {
        overlay(Group(content: content), alignment: alignment)
    }
}

With that simple extension in place, we can now use the closure-based variants of both background and overlay even within projects that need to support earlier operating system versions.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

Conclusion

Backgrounds and overlays are two incredibly useful layout tools when working with SwiftUI, and along with ZStack, make it possible to define all sorts of depth-stacked view hierarchies. To learn more about SwiftUI’s layout system, make sure to check out my three-part guide right here, and head over to the SwiftUI Discover page if you’d like to continue exploring many other aspects of the framework.

Of course, you’re always welcome to contact me via either Twitter or email if you have any questions, comments, or feedback.

Thanks for reading!

A challenge that many developers face as they maintain various code bases over time is how to neatly connect different frameworks and APIs in a way that properly adheres to the conventions of each technology involved.

For example, as teams around the world are starting to adopt Swift 5.5’s async/await-powered concurrency system, we’ll likely find ourselves in situations where we need to create versions of our async-marked APIs that are compatible with other asynchronous programming techniques — such as Combine.

While we’ve already taken a look at how Combine relates to concurrency APIs like async sequences and streams, and how we can make it possible to call async-marked functions within a Combine pipeline — in this article, let’s explore how we could make it easy to create Combine-based variants of any async API, regardless of whether it was defined by us, by Apple, or as part of a third-party dependency.

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

Async futures

Let’s say that an app that we’re working on contains the following ModelLoader, which can be used to load any Decodable model over the network. It performs its work through an async function that looks like this:

class ModelLoader<Model: Decodable> {
    ...

    func loadModel(from url: URL) async throws -> Model {
        ...
    }
}

Now let’s say that we’d also like to create a Combine-based version of the above loadModel API, for example in order to be able to call it within specific parts of our code base that might’ve been written in a more reactive style using the Combine framework.

We could of course choose to write that sort of compatibility code specifically for our ModelLoader type, but since this is a general problem that we’re likely to encounter multiple times when working with Combine-based code, let’s instead create a more generic solution that we’ll be able to easily reuse across our code base.

Since we’re dealing with async functions that either return a single value, or throw an error, let’s use Combine’s Future publisher to wrap those calls. That publisher type was specifically built for these kinds of use cases, since it gives us a closure that can be used to report a single Result back to the framework.

So let’s go ahead and extend the Future type with a convenience initializer that makes it possible to initialize an instance with an async closure:

extension Future where Failure == Error {
    convenience init(operation: @escaping () async throws -> Output) {
        self.init { promise in
            Task {
                do {
                    let output = try await operation()
                    promise(.success(output))
                } catch {
                    promise(.failure(error))
                }
            }
        }
    }
}

For more information on how Combine’s Future type works, check out “Using Combine’s futures and subjects”.

The power of creating an abstraction like that, which isn’t tied to any specific use case, is that we’ll now be able to apply it to any async API that we want to make Combine-compatible. All it takes is a few lines of code that calls the API that we’re looking to bridge within a closure that’s passed to our new Future initializer — like this:

extension ModelLoader {
    func modelPublisher(for url: URL) -> Future<Model, Error> {
        Future {
            try await self.loadModel(from: url)
        }
    }
}

Neat! Note how we could’ve chosen to give that Combine-based version the same loadModel name that our async-powered one has (since Swift supports method overloading). However, in this case, it might be a good idea to clearly separate the two, which is why the above new API has a name that explicitly includes the word “Publisher”.

Reactive async sequences

Async sequences and streams are perhaps the closest that the Swift standard library has ever come to adopting reactive programming, which in turn makes those APIs behave very similarly to Combine — in that they enable us to emit values over time.

In fact, in the article “Async sequences, streams, and Combine”, we took a look at how Combine publishers can even be directly converted into async sequences using their values property — but what if we wanted to go the other way, and convert an async sequence (or stream) into a publisher?

Continuing with the ModelLoader example from before, let’s say that our loader class also offers the following API, which lets us create an AsyncThrowingStream that emits a series of models loaded from an array of URLs:

class ModelLoader<Model: Decodable> {
    ...

    func loadModels(from urls: [URL]) -> AsyncThrowingStream<Model, Error> {
        ...
    }
}

For an example of a concrete implementation of an API just like the one above, check out the aforementioned article “Async sequences, streams, and Combine”.

Just like before, rather than rushing into writing code that specifically converts the above loadModels API into a Combine publisher, let’s instead try to come up with a generic abstraction that we’ll be able to reuse whenever we want to write similar bridging code elsewhere within our project.

This time, we’ll extend Combine’s PassthroughSubject type, which gives us complete control over when its values are emitted, as well as when and how it should terminate. However, we’re not going to model this API as a convenience initializer, since we want to make it clear that calling this API will, in fact, make the created subject start emitting values right away. So let’s make it a static factory method instead — like this:

extension PassthroughSubject where Failure == Error {
    static func emittingValues<T: AsyncSequence>(
        from sequence: T
    ) -> Self where T.Element == Output {
        let subject = Self()

        Task {
            do {
                for try await value in sequence {
                    subject.send(value)
                }

                subject.send(completion: .finished)
            } catch {
                subject.send(completion: .failure(error))
            }
        }

        return subject
    }
}

For more on how static factory methods might differ from initializers in terms of API design, check out “Initializers in Swift”

With the above in place, we can now wrap our async stream-based loadModels API almost as easily as our previous async-marked one — the only extra step that’s required in this case is to type-erase our PassthroughSubject instance into an AnyPublisher, to prevent any other code from being able to send new values to our subject:

extension ModelLoader {
    func modelPublisher(for urls: [URL]) -> AnyPublisher<Model, Error> {
        let subject = PassthroughSubject.emittingValues(
            from: loadModels(from: urls)
        )
        
        return subject.eraseToAnyPublisher()
    }
}

Just like that, we’ve now created two convenience APIs that make it very straightforward for us to make code using Swift’s concurrency system backward compatible with Combine — which should prove to be incredibly convenient when working with a code base that uses Combine to some extent.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

Conclusion

Even though Swift does now have a built-in concurrency system that covers much of the same ground as Combine does, I think both of those two technologies will continue to be incredibly useful for years to come — so the more we can create smooth bridges between them, the better.

While some developers will likely opt to completely rewrite their Combine-based code using Swift concurrency, the good news is that we don’t have to do that. With just a few convenience APIs in place, we can make it trivial to pass data and events between those two technologies, which in turn will let us keep using our Combine-based code, even as we start adopting async/await and the rest of Swift’s concurrency system.

I hope that you found this article useful. If you did, or if you have any feedback, questions, or comments, then please let me know — either on Twitter or via email.

Thanks for reading!

In Swift, there are two ways to capture self as a strong reference within an escaping closure. The first is to explicitly use the self keyword whenever we’re calling a method or accessing a property on the current object within such a closure.

For example, the following VideoViewController performs such a strong capture in order to be able to call two of its own methods whenever it finished preparing its Video model:

class VideoViewController: UIViewController {
    private var video: Video
    ...
    
    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        prepareVideo {
            self.movePlayhead(to: self.video.lastPlayheadPosition)
self.startPlaybackIfNeeded()
        }
    }
}

The reason that it’s safe to capture self strongly within the above example is because the closure that we pass to prepareVideo isn’t stored in a way that would potentially cause a retain cycle. For more on that topic, check out “Is using [weak self] always required when working with closures?”.

The above is certainly the most well-known way to access properties and methods on self within an escaping closure. But there’s also another, lesser-known technique that lets us reference self just once — and that’s to use a capture list to set up our reference. While capture lists are most commonly used when we want to create a weak or unowned reference to self, or when we want to capture a specific set of properties, they can also be used in situations like the above in order to avoid having to retype that same self prefix multiple times — like this:

class VideoViewController: UIViewController {
    private var video: Video
    ...

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

        prepareVideo { [self] in
            movePlayhead(to: video.lastPlayheadPosition)
            startPlaybackIfNeeded()
        }
    }
}

Note how we can now call methods and access properties on self just like if we were writing our code in a context other than an escaping closure, which is quite neat!

Of course, we also always have the option to move the logic that we want to perform to a dedicated method instead, which we could then simply call from within our closure:

class VideoViewController: UIViewController {
    private var video: Video
    ...

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

        prepareVideo {
            self.videoWasPrepared()
        }
    }
    
    private func videoWasPrepared() {
        movePlayhead(to: video.lastPlayheadPosition)
        startPlaybackIfNeeded()
    }
}

It’s important to re-iterate that the above techniques are specifically for creating strong references to objects. When we don’t want to retain the current object, we’d be much better off using either a weak or unowned self capture, or to avoid capturing self entirely. For more on that topic, check out “Swift’s closure capturing mechanics”. Also, when working with value types, the compiler will implicitly capture self for us, which you can read more about here.

Thanks for reading, and Happy New Year! 🎉

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

When building modern applications, it’s incredibly common to want to trigger some form of asynchronous action in response to a UI event. For example, within the following SwiftUI-based PhotoView, we’re using a Task to trigger an asynchronous onLike action whenever the user tapped that view’s button:

struct PhotoView: View {
    var photo: Photo
    var onLike: () async -> Void

    var body: some View {
        VStack {
            Image(uiImage: photo.image)
            Text(photo.description)
            
            Button(action: {
                Task {
    await onLike()
}
            }, label: {
                Image(systemName: "hand.thumbsup.fill")
            })
            .disabled(photo.isLiked)
        }
    }
}

The above implementation is definitely a good starting point. However, if our Photo model’s isLiked property isn’t updated until after our asynchronous call has completed, then we might end up with duplicate onLike calls if the user taps the button multiple times in quick succession — since we’re currently only disabling our button once that property has been set to true.

Now, we could choose to fix that issue by performing a local model update right before we call onLike. However, doing so would introduce multiple sources of truth for our data model, which is something that’s typically good to avoid. So, ideally, we’d like to keep having our PhotoView simply render the Photo model that it gets from its parent view, without having to make any local copies or modifications.

So, instead, let’s explore how we could make our button disable itself while its action is being performed. Since that’ll involve introducing additional state that’s only really relevant to our button itself — let’s encapsulate all of that code within a new AsyncButton view that’ll also display a loading spinner while waiting for its async action to complete:

struct AsyncButton<Label: View>: View {
    var action: () async -> Void
    @ViewBuilder var label: () -> Label

    @State private var isPerformingTask = false

    var body: some View {
        Button(
            action: {
                isPerformingTask = true
            
                Task {
                    await action()
                    isPerformingTask = false
                }
            },
            label: {
                ZStack {
                    // We hide the label by setting its opacity
                    // to zero, since we don't want the button's
                    // size to change while its task is performed:
                    label().opacity(isPerformingTask ? 0 : 1)

                    if isPerformingTask {
                        ProgressView()
                    }
                }
            }
        )
        .disabled(isPerformingTask)
    }
}

If you’re curious about the @ViewBuilder attribute that the above button’s label closure is annotated with, then check out “Annotating properties with result builder attributes”.

Since our new AsyncButton has an API that perfectly matches SwiftUI’s built-in Button type, we’ll be able to update our PhotoView by simply changing the type of button that it creates, and by removing the Task within its action closure (since we can now use await directly within that closure, as it’s marked with the async keyword):

struct PhotoView: View {
    var photo: Photo
    var onLike: () async -> Void

    var body: some View {
        VStack {
            Image(uiImage: photo.image)
            Text(photo.description)
            
            AsyncButton(action: {
    await onLike()
}, label: {
    Image(systemName: "hand.thumbsup.fill")
})
            .disabled(photo.isLiked)
        }
    }
}

Very nice! Now, if that was the only place within our app in which we needed to perform the above kind of asynchronous action, then we could wrap things up here. But let’s say that our code base also contains many other, similar async-function-calling buttons, and that we’d like to reuse our new AsyncButton within those places as well.

To make things even more interesting, let’s also say that within some parts of our code base, we don’t want to show a loading spinner while our async action is being performed, and that we’d also like to have the option to perform multiple actions at the same time.

To support those kinds of options, let’s introduce an ActionOption enum, which will enable each part of our code base to tweak how it wants our AsyncButton to behave when performing its action:

extension AsyncButton {
    enum ActionOption: CaseIterable {
        case disableButton
        case showProgressView
    }
}

The reason that we’re making that new enum conform to CaseIterable is because doing so lets us easily default to enabling all options (and thus making this a backward compatible change) using that protocol’s automatically generated allCases property. We’ll then check whether the specified options contain either disableButton or showProgressView before activating those behaviors — like this:

struct AsyncButton<Label: View>: View {
    var action: () async -> Void
    var actionOptions = Set(ActionOption.allCases)
    @ViewBuilder var label: () -> Label

    @State private var isDisabled = false
@State private var showProgressView = false

    var body: some View {
        Button(
            action: {
                if actionOptions.contains(.disableButton) {
                    isDisabled = true
                }

                if actionOptions.contains(.showProgressView) {
                    showProgressView = true
                }
            
                Task {
                    await action()
                    isDisabled = false
                    showProgressView = false
                }
            },
            label: {
                ZStack {
                    label().opacity(showProgressView ? 0 : 1)

                    if showProgressView {
                        ProgressView()
                    }
                }
            }
        )
        .disabled(isDisabled)
    }
}

With those changes in place, our AsyncButton is now flexible enough to accommodate many different use cases, but there’s still room for a few finishing touches to make both its API and internal behavior even nicer before calling it done.

First, let’s use a delayed task to only show our button’s ProgressView if its task ended up taking longer than 150 milliseconds to complete. That way, we’ll avoid quickly showing and hiding that loading spinner when performing fast operations, which is a very common type of glitch within asynchronous UI code:

struct AsyncButton<Label: View>: View {
    var action: () async -> Void
    var actionOptions = Set(ActionOption.allCases)
    @ViewBuilder var label: () -> Label

    @State private var isDisabled = false
    @State private var showProgressView = false

    var body: some View {
        Button(
            action: {
                if actionOptions.contains(.disableButton) {
                    isDisabled = true
                }
            
                Task {
                    var progressViewTask: Task<Void, Error>?

                    if actionOptions.contains(.showProgressView) {
                        progressViewTask = Task {
                            try await Task.sleep(nanoseconds: 150_000_000)
                            showProgressView = true
                        }
                    }

                    await action()
                    progressViewTask?.cancel()

                    isDisabled = false
                    showProgressView = false
                }
            },
            label: {
                ZStack {
                    label().opacity(showProgressView ? 0 : 1)

                    if showProgressView {
                        ProgressView()
                    }
                }
            }
        )
        .disabled(isDisabled)
    }
}

Note that, depending on the app and the type of operations that we’re looking to have our AsyncButton perform, we might want to tweak that 150 millisecond value either upwards or downwards. We might also want to introduce logic to always show the loading spinner for a given duration, to give the user proper feedback that an action was indeed performed.

Finally, let’s also introduce two convenience APIs — one for when we want to render an AsyncButton that shows a Text as its label, and one for when we want to use a system icon displayed using an Image. That can be done by extending our button type using generic type constraints — like this:

extension AsyncButton where Label == Text {
    init(_ label: String,
         actionOptions: Set<ActionOption> = Set(ActionOption.allCases),
         action: @escaping () async -> Void) {
        self.init(action: action) {
            Text(label)
        }
    }
}

extension AsyncButton where Label == Image {
    init(systemImageName: String,
         actionOptions: Set<ActionOption> = Set(ActionOption.allCases),
         action: @escaping () async -> Void) {
        self.init(action: action) {
            Image(systemName: systemImageName)
        }
    }
}

With the above in place, we can now use our new Image-based initializer to construct the AsyncButton within our PhotoView in a very lightweight way:

struct PhotoView: View {
    var photo: Photo
    var onLike: () async -> Void

    var body: some View {
        VStack {
            Image(uiImage: photo.image)
            Text(photo.description)
            
            AsyncButton(
    systemImageName: "hand.thumbsup.fill",
    action: onLike
)
            .disabled(photo.isLiked)
        }
    }
}

Very nice! Of course, there are multiple ways that we could continue iterating on our AsyncButton type to make it even more flexible, or to adopt a different type of design (for example by show its loading spinner next to its label instead), but I hope that this article has given you some inspiration as to how async actions can be integrated into SwiftUI views, and how such views can be generalized to become much more versatile and reusable.

If you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

Most often, we want our various asynchronous tasks to start as soon as possible after they’ve been created, but sometimes we might want to add a slight delay to their execution — perhaps in order to give another task time to complete first, or to add some form of “debouncing” behavior.

Although there’s no direct, built-in way to run a Swift Task with a certain amount of delay, we can achieve that behavior by telling the task to sleep for a given number of nanoseconds before we actually start performing its operation:

Task {
    // Delay the task by 1 second:
    try await Task.sleep(nanoseconds: 1_000_000_000)
    
    // Perform our operation
    ...
}

Calling Task.sleep is very different from using things like the sleep system function, as the Task version is completely non-blocking in relation to other code.

The reason that the above call to Task.sleep is marked with the try keyword is because that call will throw an error in case the task was cancelled during its sleeping time. So, for example, if we wanted to make a view controller only show a loading spinner if an async operation took more than 150 milliseconds to complete, then we could implement something like this:

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

        let loadingSpinnerTask = Task {
            try await Task.sleep(nanoseconds: 150_000_000)
            showLoadingSpinner()
        }

        Task {
            await prepareVideo()
            loadingSpinnerTask.cancel()
            hideLoadingSpinner()
        }
    }
    
    ...
}

Please note that the above is not meant to be a complete example on how to use a Task to load a view controller’s content. For example, we probably want to check whether an existing loading task is already in progress before starting a new one. To learn more, check out “What role do Tasks play within Swift’s concurrency system?”.

Now, if we’re going to use a lot of delayed tasks within a given code base, then it might be worth defining a simple abstraction that would let us create such delayed tasks more easily — for example by enabling us to use a more standard TimeInterval value to define second-based delays, rather than having to use nanoseconds:

extension Task where Failure == Error {
    static func delayed(
        byTimeInterval delayInterval: TimeInterval,
        priority: TaskPriority? = nil,
        operation: @escaping @Sendable () async throws -> Success
    ) -> Task {
        Task(priority: priority) {
            let delay = UInt64(delayInterval * 1_000_000_000)
            try await Task<Never, Never>.sleep(nanoseconds: delay)
            return try await operation()
        }
    }
}

The reason we have to explicitly mark our sleep task as Task<Never, Never> is because that method is only available on that exact Task specialization, and within the scope of our extension, the symbol Task refers to the current specialization that our extension is being used with.

With the above extension in place, we can now simply call Task.delayed whenever we want to create a delayed task. The only downside of that approach is that we now have to manually capture self within those task closures:

class VideoViewController: UIViewController {
    ...

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

        let loadingSpinnerTask = Task.delayed(byTimeInterval: 0.15) {
    self.showLoadingSpinner()
}

        Task {
            await prepareVideo()
            loadingSpinnerTask.cancel()
            hideLoadingSpinner()
        }
    }
    
    ...
}

There is one way around that minor problem, though — and that’s to use the “semi-public” _implicitSelfCapture attribute — which is what the Swift standard library uses to make all built-in Task closures automatically capture self references:

extension Task where Failure == Error {
    static func delayed(
        byTimeInterval delayInterval: TimeInterval,
        priority: TaskPriority? = nil,
        @_implicitSelfCapture operation: @escaping @Sendable () async throws -> Success
    ) -> Task {
        ...
    }
}

However, since the above attribute is not yet an official part of Swift’s public API (given that its name is prefixed with an underscore), I wouldn’t really recommend using it in production code — unless you’re willing to accept the risk that any code using it might break at any point.

I hope you enjoyed this quick look at a few different ways to model delayed operations using Swift’s new built-in Task API. Of course, we also have the option to use older tools to implement such delays — like Grand Central Dispatch, timers, or even the Objective-C runtime (at least in some cases). But, when writing async code using Swift’s new concurrency system, being able to directly use the Task type to achieve that kind of delaying behavior could be really convenient.

Like always, feel free to send me an email if you have any questions, comments, or feedback.

Thanks for reading!

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

Very often, making code easy to unit test tends to go hand-in-hand with improving that code’s separation of concerns, its state management, and its overall architecture. In general, the more well-abstracted and organized our code is, the easier it tends to be to test it in an automated fashion.

However, in an effort to make code more testable, we can very often find ourselves introducing a ton of new protocols and other kinds of abstractions, and end up making our code significantly more complicated in the process — especially when testing asynchronous code that relies on some form of networking.

But does it really have to be that way? What if we could actually make our code fully testable in a way that doesn’t require us to introduce any new protocols, mocking types, or complicated abstractions? Let’s explore how we could make use of Swift’s new async/await capabilities to make that happen.

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

Injected networking

Let’s say that we’re working on an app that includes the following ProductViewModel, which uses the very common pattern of getting its URLSession (that it’ll use to perform network calls) injected through its initializer:

class ProductViewModel {
    var title: String { product.name }
    var detailText: String { product.description }
    var price: Price { product.price(in: localUser.currency) }
    ...

    private var product: Product
    private let localUser: User
    private let urlSession: URLSession

    init(product: Product, localUser: User, urlSession: URLSession = .shared) {
        self.product = product
        self.localUser = localUser
        self.urlSession = urlSession
    }

    func reload() async throws {
        let url = URL.forLoadingProduct(withID: product.id)
        let (data, _) = try await urlSession.data(from: url)
        let decoder = JSONDecoder()
        product = try decoder.decode(Product.self, from: data)
    }
}

Now, there’s really nothing wrong with the above code. It works, and it uses dependency injection to avoid accessing URLSession.shared directly as a singleton (which already has huge benefits in terms of testing and overall architecture), even though it does use that shared instance by default, for convenience.

However, it could definitely be argued that inlining raw network calls within types like view models and view controllers is something that ideally should be avoided — as that’d create a better separation of concerns within our project, and would let us reuse that network code whenever we need to perform a similar request elsewhere.

So, to continue iterating on the above example, let’s extract our view model’s product loading code into a dedicated ProductLoader type instead:

class ProductLoader {
    private let urlSession: URLSession

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

    func loadProduct(withID id: Product.ID) async throws -> Product {
        let url = URL.forLoadingProduct(withID: id)
        let (data, _) = try await urlSession.data(from: url)
        let decoder = JSONDecoder()
        return try decoder.decode(Product.self, from: data)
    }
}

If we then make our view model use that new ProductLoader, rather than interacting with URLSession directly, then we can simplify its implementation quite significantly — as it can now simply call loadProduct whenever it’s asked to reload its underlying data model:

class ProductViewModel {
    ...
    private var product: Product
    private let localUser: User
    private let loader: ProductLoader

    init(product: Product, localUser: User, loader: ProductLoader) {
        self.product = product
        self.localUser = localUser
        self.loader = loader
    }

    func reload() async throws {
        product = try await loader.loadProduct(withID: product.id)
    }
}

So that’s already quite an improvement. But what if we now wanted to implement a few unit tests to ensure that our view model behaves as we’d expect? To do that, we’re going to need to mock our app’s networking one way or another, as we definitely don’t want to perform any real network calls within our unit tests (as that could add delays, flakiness, and require us to always be online while working on our code base).

Protocol-based mocking

One way to setup that kind of mocking would be to create a protocol-based Networking abstraction, which essentially just requires us to duplicate the signature of the URLSession.data method within that protocol, and to then make URLSession conform to our new protocol through an extension — like this:

protocol Networking {
    func data(
    from url: URL,
    delegate: URLSessionTaskDelegate?
) async throws -> (Data, URLResponse)
}

extension Networking {
    // If we want to avoid having to always pass 'delegate: nil'
    // at call sites where we're not interested in using a delegate,
    // we also have to add the following convenience API (which
    // URLSession itself provides when using it directly):
    func data(from url: URL) async throws -> (Data, URLResponse) {
        try await data(from: url, delegate: nil)
    }
}

extension URLSession: Networking {}

With the above in place, we can now make our ProductLoader accept any object that conforms to our new Networking protocol, rather than always using a concrete URLSession instance (we’ll still default to URLSession.shared for convenience):

class ProductLoader {
    private let networking: Networking

    init(networking: Networking = URLSession.shared) {
        self.networking = networking
    }

    func loadProduct(withID id: Product.ID) async throws -> Product {
        let url = URL.forLoadingProduct(withID: id)
        let (data, _) = try await networking.data(from: url)
        let decoder = JSONDecoder()
        return try decoder.decode(Product.self, from: data)
    }
}

With all of that preparation work done, we can now finally start writing our tests. To do that, we’ll start by creating a mocked implementation of our Networking protocol, and we’ll then set up a ProductLoader and ProductViewModel that uses that mocked implementation when performing all network calls — which in turn enables us to write our tests like this:

class NetworkingMock: Networking {
    var result = Result<Data, Error>.success(Data())

    func data(
        from url: URL,
        delegate: URLSessionTaskDelegate?
    ) async throws -> (Data, URLResponse) {
        try (result.get(), URLResponse())
    }
}

class ProductViewModelTests: XCTestCase {
    private var product: Product!
    private var networking: NetworkingMock!
    private var viewModel: ProductViewModel!

    override func setUp() {
        super.setUp()

        product = .stub()
        networking = NetworkingMock()
        viewModel = ProductViewModel(
            product: product,
            localUser: .stub(),
            loader: ProductLoader(networking: networking)
        )
    }

    func testReloadingProductUpdatesTitle() async throws {
        product.name = "Reloaded product"
        networking.result = try .success(JSONEncoder().encode(product))
        XCTAssertNotEqual(viewModel.title, product.name)

        try await viewModel.reload()
        XCTAssertEqual(viewModel.title, product.name)
    }
    
    ...
}

To learn more about the .stub() method that’s called above in order to generate stubbed versions of our data models, check out “Defining testing data in Swift”.

Alright! We have now successfully refactored all of our ProductViewModel-related code to become fully testable, and we’ve started covering it with unit tests. Very nice.

But, if we take a closer look at the above test case, we can see that our ProductLoader isn’t really participating much in our testing code at all. That’s because we’re really only interested in mocking our actual networking code in this case, since that’s the part of our code that would be problematic to run in a testing context.

Now, it could definitely be argued that we also should’ve added an additional protocol and mocking layer for ProductLoader as well — which would let us mock it directly, rather than using its real, actual implementation with a mocked networking instance. You could even argue that the above unit test isn’t actually a unit test at all — that it instead is an integration test, as it integrates multiple units (our view model, product loader, and networking) when performing verifications.

However, if we were to take that unit-testing-by-the-book route and introduce yet another protocol and mocking type, then we could quickly end up going down a slippery slope where every single object in our code base also has an associated protocol and mocking type, which would lead to a ton of code duplication and added complexity (even when using code generation tools to automatically generate those types).

But perhaps there’s a way that we could have our cake and eat it too? Let’s see if we could actually make our above test case just verify our ProductViewModel as a single unit, while also getting rid of those mocks and test-specific protocols in the process.

Adding a bit of functional programming

If we stop thinking about our product loading code in terms of object-oriented constructs like classes and protocols, and instead look at it from a more functional perspective, then we could actually model our view model’s loading code using the following function signature:

typealias Loading<T> = () async throws -> T

That is, a function that loads some form of value in an asynchronous manner, and either returns that value, or throws an error.

Next, let’s change our ProductViewModel once more, to now accept some function that matches the above signature (specialized using our Product model), rather than accepting a ProductLoader instance directly:

class ProductViewModel {
    ...

    private var product: Product
    private let localUser: User
    private let reloading: Loading<Product>

    init(product: Product,
         localUser: User,
         reloading: @escaping Loading<Product>) {
        self.product = product
        self.localUser = localUser
        self.reloading = reloading
    }

    func reload() async throws {
        product = try await reloading()
    }
}

One thing that’s very neat about the above pattern is that it still lets us keep using our existing Networking and ProductLoader code just like before — all that we have to do is to call that code within the reloading function/closure that we pass into our ProductViewModel when creating it:

func makeProductViewModel(
    for product: Product,
    localUser: User,
    networking: Networking
) -> ProductViewModel {
    let loader = ProductLoader(networking: networking)

    return ProductViewModel(
        product: product,
        localUser: localUser,
        reloading: {
    try await loader.loadProduct(withID: product.id)
}
    )
}

If you’ve been reading Swift by Sundell for a while, then you might recognize the above pattern from 2019’s “Functional networking in Swift” article, which used Futures and Promises to achieve a similar result.

But here’s where things get really interesting. Now, when unit testing our ProductViewModel, we no longer have to worry about mocking our networking, or even create a ProductLoader instance — all that we have to do is to inject an inline closure that returns a specific Product value, which we can then mutate whenever we want to change our reloading response in any way:

class ProductViewModelTests: XCTestCase {
    private var product: Product!
    private var viewModel: ProductViewModel!

    override func setUp() {
        super.setUp()

        product = .stub()
        viewModel = ProductViewModel(
            product: product,
            localUser: .stub(),
            reloading: { [unowned self] in self.product }
        )
    }

    func testReloadingProductUpdatesTitle() async throws {
        product.name = "Reloaded product"
        XCTAssertNotEqual(viewModel.title, product.name)

        try await viewModel.reload()
        XCTAssertEqual(viewModel.title, product.name)
    }
    
    ...
}

Note how there’s no longer any protocols or mocking types involved in our entire test case! Since we’ve now completely separated our ProductViewModel from our networking code, we can unit test that class in complete isolation — since, as far as it’s concerned, it just gets access to a closure that loads a Product value from somewhere.

Scaling things up

But now the big question becomes — how does this pattern scale if we need to perform multiple kinds of loading operations within a given type? To explore that, let’s start by introducing a second kind of async function signature, which’ll let us perform an action using a given value:

typealias AsyncAction<T> = (T) async throws -> Void

Then, let’s say that we wanted to extend our ProductViewModel with support for marking a given product as a favorite, and to also be able to add that product to a user-defined list. To make that happen, we could inject those two new pieces of functionality as separate closures — like this:

class ProductViewModel {
    ...
    private let reloading: Loading<Product>
    private let favoriteToggling: Loading<Product>
private let listAdding: AsyncAction<List.ID>

    init(product: Product,
         localUser: User,
         reloading: @escaping Loading<Product>,
         favoriteToggling: @escaping Loading<Product>,
         listAdding: @escaping AsyncAction<List.ID>) {
        self.product = product
        self.localUser = localUser
        self.reloading = reloading
        self.favoriteToggling = favoriteToggling
self.listAdding = listAdding
    }

    func reload() async throws {
        product = try await reloading()
    }

    func toggleProductFavoriteStatus() async throws {
        product = try await favoriteToggling()
    }

    func addProductToList(withID listID: List.ID) async throws {
        try await listAdding(listID)
    }
}

The above still works fine, but our implementation is arguably starting to become a bit messy, since we now have to juggle multiple closures when initializing our view model.

So let’s take some inspiration from “Extracting view controller actions in Swift”, and group the above three closures into an Actions struct, which will give us a bit of added structure (no pun intended) when both implementing and initializing our ProductViewModel:

class ProductViewModel {
    ...
    private let actions: Actions

    init(product: Product, localUser: User, actions: Actions) {
        self.product = product
        self.localUser = localUser
        self.actions = actions
    }

    func reload() async throws {
        product = try await actions.reload()
    }

    func toggleProductFavoriteStatus() async throws {
        product = try await actions.toggleFavorite()
    }

    func addProductToList(withID listID: List.ID) async throws {
        try await actions.addToList(listID)
    }
}

extension ProductViewModel {
    struct Actions {
    var reload: Loading<Product>
    var toggleFavorite: Loading<Product>
    var addToList: AsyncAction<List.ID>
}
}

func makeProductViewModel(
    for product: Product,
    localUser: User,
    networking: Networking,
    listManager: ListManager
) -> ProductViewModel {
    let loader = ProductLoader(networking: networking)

    return ProductViewModel(
        product: product,
        localUser: localUser,
        actions: ProductViewModel.Actions(
            reload: {
                try await loader.loadProduct(withID: product.id)
            },
            toggleFavorite: {
                try await loader.toggleFavoriteStatusForProduct(
                    withID: product.id
                )
            },
            addToList: { listID in
                try await listManager.addProduct(
                    withID: product.id,
                    toListWithID: listID
                )
            }
        )
    )
}

With the above change in place, we can still mock all of the above three actions using simple closures within our tests, while now also making it easy to manage those actions, especially if we keep adding new ones in the future. Of course, the above pattern probably wouldn’t scale that well to types that have 10, 15, 20 actions — but at that point, it’s probably also worth asking if perhaps that type has too many responsibilities to begin with.

However, one fair piece of criticism against the above pattern would be that it does end up pushing some of the internal implementation details of our ProductViewModel to the call sites that create instances of it. For example, our makeProductViewModel function now has to know exactly what logic that it’s supposed to place within each of our view model’s Action closures.

One way to address that problem would be to provide default implementations of those closures using the underlying objects that our production code should ideally use — which could be done using an extension that can be placed within the same file as our ProductViewModel itself:

extension ProductViewModel.Actions {
    init(productID: Product.ID,
         loader: ProductLoader,
         listManager: ListManager) {
        reload = {
            try await loader.loadProduct(withID: productID)
        }
        toggleFavorite = {
            try await loader.toggleFavoriteStatusForProduct(
                withID: productID
            )
        }
        addToList = {
            try await listManager.addProduct(
                withID: productID,
                toListWithID: $0
            )
        }
    }
}

With that final tweak in place, our makeProductViewModel can now simply inject our view model’s dependencies, more or less exactly like how things were done when using our earlier, protocol-based setup:

func makeProductViewModel(
    for product: Product,
    localUser: User,
    networking: Networking,
    listManager: ListManager
) -> ProductViewModel {
    ProductViewModel(
        product: product,
        localUser: localUser,
        actions: ProductViewModel.Actions(
    productID: product.id,
    loader: ProductLoader(networking: networking),
    listManager: listManager
)
    )
}

With that approach, we’ve arguably struck a quite nice balance between being able to unit test our view model through a very lightweight set of abstractions, while also not leaking any implementation details to whichever call site that’ll initialize that view model within our production code.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. Click to learn more.

Conclusion

While there’s probably no such thing as a perfect dependency injection setup — by experimenting with different techniques, we can often arrive at an architecture that strikes a neat balance between how our code base is organized, its testing needs, and the personal preferences of the developers working on it.

I hope you found this article interesting and useful, and although I’m not saying that anyone should replace all of their protocols with the above kind of functional setup, I think it’s an approach that’s at least worth exploring — especially now that we have the power of async/await at our disposal.

For more Swift dependency injection techniques, check out this category page, and if you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

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: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. 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.

However, note that it’s up to each individual task to implement the actual cancellation handling code required to cancel its particular operation. So, even though the system will automatically manage and propagate cancellation in terms of marking, it’s up to each task to decide how to actually handle that cancellation (for example by calling Task.checkCancellation within its closure).

Context inheritance

The 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: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join the iOS Architect Crash Course, starting on January 31st. It’s 100% free and held entirely online. 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!