Swift 5.5 introduces a new concept called “effectful read-only properties”, which essentially means that computed properties can now utilize control flow mechanisms like errors and async operations when computing their values.

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

Throwing properties

Let’s start by taking a look at how computed properties can now throw errors using Swift’s standard error handling mechanism. As an example, let’s say that we’re currently using the built-in Result type’s get method to either extract a result’s wrapped value, or throw any error that it contains:

func handleLoginResult(_ result: Result<User, Error>) throws {
    let user = try result.get()
    ...
}

Since that get method doesn’t actually perform any kind of work, but rather just lets us unpack a Result value using the try keyword, it could now just as well be declared as a property — for example like this:

extension Result {
    var value: Success {
        get throws { try get() }
    }
}

With the above in place, we can now retrieve the underlying value from any Result instance simply by accessing our new value property, as long as we prefix those expressions with try and handle any errors that might be thrown — just like when using the get method directly:

func handleLoginResult(_ result: Result<User, Error>) throws {
    let user = try result.value
    ...
}

While the fact that computed properties can now throw errors could become really useful in certain situations, it’s important to still keep the semantic differences between properties and functions in mind. So while the above value property might make complete sense as a property (as it just retrieves an underlying value), many throwing operations would arguably still be better implemented as functions. To learn more about my thoughts on that topic, check out “Computed properties in Swift”.

Asynchronous properties

Along with its new concurrency system, Swift 5.5 also enables computed properties to be completely asynchronous. Similar to how properties can now use the throws keyword, any property annotated with async can now freely call other asynchronous APIs, and the code that accesses such a property will be suspended by the system until all of those underlying asynchronous operations have been completed.

For example, here a DatabaseEntity asynchronously checks with its parent Database if it has been synced whenever its isSynced property is accessed:

class DatabaseEntity {
    var isSynced: Bool {
        get async {
    await database?.isEntitySynced(self) ?? false
}
    }

    private weak var database: Database?
    ...
}

When it comes to asynchronous code, we arguably have to be even more careful as to what sort of operations that we implement behind a property-based API. For example, we probably don’t want to perform tasks like network calls or other relatively long-running operations as part of computing a property, but for things that require jumping to a separate dispatch queue, or tasks that involve some form of file I/O, async-marked properties could prove to be quite useful.

Protocol requirements

Finally, let’s also take a quick look at what these new “effectful properties” look like when declared as part of a protocol. Just like how a protocol can define standard properties as part of its list of requirements, a protocol can now also require those properties to be async, and can optionally enable them to throw.

For example, here’s what our above isSynced property might look like if we were to define it as part of a protocol:

protocol Syncable {
    var isSynced: Bool { get async }
}

If we then also wanted to enable types conforming to Syncable to throw errors as part of their isSynced implementation, then we could simply add the throws keyword to the above declaration — like this:

protocol Syncable {
    var isSynced: Bool { get async throws }
}

Just like other throwing protocol requirements, implementations of a throws-marked computed property doesn’t actually have to throw, they just have the option to do so.

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 this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

Conclusion

So that’s a quick look at how computed properties can now be marked with either the throws or async keyword, starting in Swift 5.5. I hope you enjoyed this article, and feel free to let me know if you have any questions, comments, or feedback — either via Twitter or email.

Thanks for reading!

One really powerful aspect of SwiftUI’s overall API is that it enables us to draw things like shapes, gradients, and colors the same way that we render views and UI controls. For example, if we wanted to render a button shaped as a rounded rectangle, then we could do so by assigning a RoundedRectangle shape as our view’s background — like this:

struct CreateAccountButton: View {
    var action: () -> Void

    var body: some View {
        Button("Create account", action: action)
            .padding()
            .background(RoundedRectangle(cornerRadius: 20))
    }
}

By default, the above background shape will be drawn using the current foregroundColor, but if we instead wanted to fill it with a specific color, then we could do so using the fill modifier:

struct CreateAccountButton: View {
    var action: () -> Void

    var body: some View {
        Button("Create account", action: action)
            .padding()
            .foregroundColor(.white)
            .background(RoundedRectangle(cornerRadius: 20).fill(Color.blue))
    }
}

Note how we’re now also applying a white foreground color to our button. That’s because button labels are blue by default, so if we left it like that, it’d now become invisible.

So far, we could’ve actually achieved the exact same result by using the cornerRadius modifier to apply rounded corners directly to our view, rather than using a shape. However, using a shape might give us a few advantages, depending on what kind of styling that we’re going for. For example, let’s say that we also wanted to add a border to our button, and that we’d like that border to follow our button’s rounded corners. An initial idea on how to do that might be to also apply the stroke modifier to our RoundedRectangle — like this:

struct CreateAccountButton: View {
    var action: () -> Void

    var body: some View {
        Button("Create account", action: action)
            .padding()
            .foregroundColor(.white)
            .background(RoundedRectangle(cornerRadius: 20)
                .fill(Color.blue)
                .stroke(Color.primary, lineWidth: 2)
            )
    }
}

Unfortunately, the above code doesn’t compile, since both fill and stroke are only available on the Shape protocol, and both of those modifiers use the standard some View return type. Thankfully, there’s another way, and that’s to actually make our filled rectangle the background of another, stroked rectangle, which we then use as our button’s background:

struct CreateAccountButton: View {
    var action: () -> Void

    var body: some View {
        Button("Create account", action: action)
            .padding()
            .foregroundColor(.white)
            .background(
    RoundedRectangle(cornerRadius: 20)
        .stroke(Color.primary, lineWidth: 2)
        .background(
            RoundedRectangle(cornerRadius: 20)
                .fill(Color.blue)
        )
)
    }
}

Initially, the above solution might seem a bit strange, but we have to remember that — in the world of SwiftUI — views are just descriptions of what we want to render, and any view can be used as a background for any other view. So, using two separate rectangles for stroking and filling is sort of the SwiftUI version of performing two rendering commands.

That being said, stacking multiple shapes like we did above can often result in code that’s a bit hard to read. One way to fix that would be to move our background declaration to its own, dedicated property — like this:

struct CreateAccountButton: View {
    var action: () -> Void

    var body: some View {
        Button("Create account", action: action)
            .padding()
            .foregroundColor(.white)
            .background(background)
    }

    private var background: some View {
        let rectangle = RoundedRectangle(cornerRadius: 20)

        return rectangle
            .stroke(Color.primary, lineWidth: 2)
            .background(rectangle.fill(Color.blue))
    }
}

If we instead wanted to create a more reusable solution, then another option would be to create a custom modifier that lets us style any Shape by both stroking and filling it:

extension Shape {
    func style<S: ShapeStyle, F: ShapeStyle>(
        withStroke strokeContent: S,
        lineWidth: CGFloat = 1,
        fill fillContent: F
    ) -> some View {
        self.stroke(strokeContent, lineWidth: lineWidth)
    .background(fill(fillContent))
    }
}

struct CreateAccountButton: View {
    var action: () -> Void

    var body: some View {
        Button("Create account", action: action)
            .padding()
            .foregroundColor(.white)
            .background(RoundedRectangle(cornerRadius: 20).style(
    withStroke: Color.primary,
    lineWidth: 2,
    fill: Color.blue
))
    }
}

A big benefit of mimicking SwiftUI’s built-in shape styling APIs — by using generic types constrained to the ShapeStyle protocol for our fill and stroke content — is that doing so lets us use more than just colors to style our shapes. For example, if we instead wanted to fill our button using a gradient, then we could now easily do so like this:

struct CreateAccountButton: View {
    var action: () -> Void

    var body: some View {
        Button("Create account", action: action)
            .padding()
            .foregroundColor(.white)
            .background(RoundedRectangle(cornerRadius: 20).style(
                withStroke: Color.primary,
                lineWidth: 2,
                fill: LinearGradient(
    gradient: Gradient(colors: [.blue, .black]),
    startPoint: .top,
    endPoint: .bottom
)
            ))
    }
}

While it could definitely be argued that SwiftUI’s Shape API should enable us to both stroke and fill a given shape without requiring any custom code, the fact that we can compose multiple shapes to build that sort of functionality on our own is definitely a really powerful thing.

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 this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

One of the ways in which Swift helps us write more robust code is through its concept of value types, which limit the way that state can be shared across API boundaries. That’s because, when using value types, all mutations are (by default) only performed to local copies of the values that we’re working with, and APIs that actually perform mutations have to be clearly marked as mutating.

In this article, let’s explore that keyword, as well as its nonmutating counterpart, and the sort of capabilities that those language features provide.

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

What can a mutating function do?

Essentially, a function that’s been marked as mutating can change any property within its enclosing value. The word “value” is really key here, since Swift’s concept of structured mutations only applies to value types, not to reference types like classes and actors.

For example, the following Meeting type’s cancel method is mutating, since it modifies its enclosing type’s state and reminderDate properties:

struct Meeting {
    var name: String
    var state: MeetingState
    var reminderDate: Date?
    ...

    mutating func cancel(withMessage message: String) {
        state = .cancelled(message: message)
        reminderDate = nil
    }
}

Besides modifying properties, mutating contexts can also assign a brand new value to self, which can be really useful when adding a mutating method to an enum (which can’t contain any stored instance properties). For example, here we’re creating an API for making it easy to appending one Operation to another:

enum Operation {
    case add(Item)
    case remove(Item)
    case update(Item)
    case group([Operation])
}

extension Operation {
    mutating func append(_ operation: Operation) {
        self = .group([self, operation])
    }
}

The above technique also works for other value types, such as structs, which can be really useful if we ever want to reset a value back to its default set of properties, or if we want to mutate a more complex value as a whole — for example like this:

struct Canvas {
    var backgroundColor: Color?
    var foregroundColor: Color?
    var shapes = [Shape]()
    var images = [Image]()

    mutating func reset() {
        self = Canvas()
    }
}

The fact that we can assign a brand new value to self within a mutating function might initially seem a bit strange, but we have to remember that Swift structs are really just values — so just like how we can replace an Int value by assigning a new number to it, we can do the same thing with any other struct (or enum) as well.

Mutating protocol requirements

Although the concept of separating mutating and non-mutating APIs is something that’s unique to value types, we can still make a mutating function a part of a protocol as well — even if that protocol might end up being adopted by a reference type, such as a class. Classes can simply omit the mutating keyword when conforming to such a protocol, since they are inherently mutable.

What’s very interesting, though, is that if we extend a protocol with a default implementation of a mutating function, then we could implement things like the above reset API without actually knowing what type of value that we’re resetting — like this:

protocol Resettable {
    init()
    mutating func reset()
}

extension Resettable {
    mutating func reset() {
        self = Self()
    }
}

struct Canvas: Resettable {
    var backgroundColor: Color?
    var foregroundColor: Color?
    var shapes = [Shape]()
    var images = [Image]()
}

Performing mutations within initializers

While functions always need to be explicitly marked as mutating whenever we want to modify a value type’s internal state (whether that’s a property, or the entire value itself), initializers are always mutating by default. That means that, besides assigning initial values to a type’s properties, an initializer can also call mutating methods to perform its work (as long as self has been fully initialized beforehand).

For example, the following ProductGroup calls its own add method in order to add all of the products that were passed into its initializer — which makes it possible for us to use a single code path for that logic, regardless of whether it’s being run as part of the initialization process or not:

struct ProductGroup {
    var name: String
    private(set) var products = [Product]()
    private(set) var totalPrice = 0
    
    init(name: String, products: [Product]) {
        self.name = name
        products.forEach { add($0) }
    }

    mutating func add(_ product: Product) {
        products.append(product)
        totalPrice += product.price
    }
}

Just like mutating functions, initializers can also assign a value directly to self. Check out this quick tip for an example of that.

Non-mutating properties

So far, all of the examples that we’ve been taking a look at have been about mutable contexts, but Swift also offers a way to mark certain contexts as explicitly non-mutating as well. While the use cases for doing so are certainly more limited compared to opting into mutations, it can still be a useful tool in certain kinds of situations.

As an example, let’s take a look at this simple SwiftUI view, which increments an @State-marked value property every time that a button was tapped:

struct Counter: View {
    @State private var value = 0

    var body: some View {
        VStack {
            Text(String(value)).font(.largeTitle)
            Button("Increment") {
                value += 1
            }
        }
    }
}

Now, if we look at the above not just as a SwiftUI view, but rather as a standard Swift struct (which it is), it’s actually quite strange that our code compiles. How come we can mutate our value property like that, within a closure, that’s not being called within a synchronous, mutable context?

The mystery continues to thicken if we then take a look at the declaration of the State property wrapper, which is also a struct, just like our view:

@frozen @propertyWrapper public struct State<Value>: DynamicProperty {
    ...
}

So how come a struct-based property wrapper, that’s used within a struct-based view, can actually be mutated within a non-mutating context? The answer lies within the declaration of the State wrapper’s wrappedValue, which has been marked with the nonmutating keyword:

public var wrappedValue: Value { get nonmutating set }

Although this is as far as we’re able to investigate without access to SwiftUI’s source code, State very likely uses some form of reference-based storage under the hood, which in turn makes it possible for it to opt out of Swift’s standard value mutation semantics (using the nonmutating keyword) — since the State wrapper itself is not actually being mutated when we assign a new property value.

If we wanted to, this is a capability that we could add to some of our own types as well. To demonstrate, the following PersistedFlag wrapper stores its underlying Bool value using UserDefaults, meaning that when we assign a new value to it (through its wrappedValue property), we’re not actually performing any value-based mutations here either. So that property can be marked as nonmutating, which gives PersistedFlag the same mutation capabilities as State:

@propertyWrapper struct PersistedFlag {
    var wrappedValue: Bool {
        get {
            defaults.bool(forKey: key)
        }
        nonmutating set {
            defaults.setValue(newValue, forKey: key)
        }
    }

    var key: String
    private let defaults = UserDefaults.standard
}

So just like @State-marked properties, any property that we mark with @PersistedFlag can now be written to even within non-mutating contexts, such as within escaping closures. What’s very important to note, though, is that the nonmutating keyword sort of lets us circumvent key aspects of Swift’s value semantics, so it’s definitely something that should only be used within very specific situations.

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 this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

Conclusion

I hope that this article has given you a few insights into what separates a mutating context from a non-mutating one, what sort of capabilities that a mutating context actually has, and what Swift’s relatively new nonmutating keyword does.

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

Thanks for reading!

When building iOS and Mac apps, it’s very common to want to present certain views either modally, or by pushing them onto the current navigation stack. For example, here we’re presenting a MessageDetailView as a modal, using SwiftUI’s built-in sheet modifier in combination with a local @State property that keeps track of whether the detail view is currently being presented:

struct MessageView: View {
    var message: Message
    @State private var isShowingDetails = false

    var body: some View {
        ScrollView {
            Text(message.body)
            ...
        }
        .navigationTitle(message.subject)
        .navigationBarItems(trailing: Button("Details") {
            isShowingDetails = true
        })
        .sheet(isPresented: $isShowingDetails) {
    MessageDetailsView(message: message)
}
    }
}

To learn more about @State and the rest of SwiftUI’s state management system, check out this guide.

But now the question is — how do we dismiss that MessageDetailsView once it’s been presented? One way to do that would be to inject our above isShowingDetails property into our MessageDetailsView as a binding, which the detail view could then set to false to dismiss itself:

struct MessageDetailsView: View {
    var message: Message
    @Binding var isPresented: Bool

    var body: some View {
        VStack {
            ...
            Button("Dismiss") {
                isPresented = false
            }
        }
    }
}

struct MessageView: View {
    var message: Message
    @State private var isShowingDetails = false

    var body: some View {
        ...
        .sheet(isPresented: $isShowingDetails) {
            MessageDetailsView(
                message: message,
                isPresented: $isShowingDetails
            )
        }
    }
}

While the above pattern certainly works, it requires us to manually implement that binding connection every time that we want to enable our users to dismiss a modal. So, there has to be a more convenient way, right?

The good news is that there is, and that’s to use the presentationMode environment value, which gives us access to an object that can be used to dismiss any view, regardless of how it’s being presented:

struct MessageDetailsView: View {
    var message: Message
    @Environment(\.presentationMode) var presentationMode

    var body: some View {
        VStack {
            ...
            Button("Dismiss") {
                presentationMode.wrappedValue.dismiss()
            }
        }
    }
}

With the above in place, we no longer have to manually inject our isShowingDetails property as a binding — SwiftUI will automatically set that property to false whenever our sheet gets dismissed. As an added bonus, the above pattern even works if we were to present our MessageDetailsView by pushing it onto the navigation stack, rather than displaying it as a sheet. In that situation, our view would get “popped” from the navigation stack when the presentation mode’s dismiss method is called. Neat!

However, there’s one thing that’s somewhat awkward about the above implementation, and that’s that we have to access our environment value’s wrappedValue in order to be able to call its dismiss method (because it’s actually a Binding, not just a raw value). So, to address that, Apple is introducing a new version of the above API in iOS 15 (and the rest of their 2021 operating systems) which is simply called dismiss. That new API gives us an action that can be invoked directly — like this:

struct MessageDetailsView: View {
    var message: Message
    @Environment(\.dismiss) private var dismiss

    var body: some View {
        VStack {
            ...
            Button("Dismiss") {
                dismiss()
            }
        }
    }
}

Please note that iOS 15 is, at the time of writing, currently in beta.

Now, if you’ve been reading Swift by Sundell for a while, then you might think that the next thing that I will point out is that the above dismiss closure can be directly passed to our Button as its action, but that’s actually not the case. It turns out that dismiss is not a closure, but rather a struct that uses Swift’s relatively new call as function feature.

So, if we wanted to inject the dismiss action directly into our button, then we’d have to pass a reference to its callAsFunction method — like this:

struct MessageDetailsView: View {
    var message: Message
    @Environment(\.dismiss) private var dismiss

    var body: some View {
        VStack {
            ...
            Button("Dismiss", action: dismiss.callAsFunction)
        }
    }
}

Of course, there’s nothing wrong with wrapping our call to dismiss within a closure (in fact, I prefer doing that in this kind of situation), but I just thought I’d point it out, since it’s interesting to see SwiftUI adopt call as function for the above API and others like it.

So that’s three different ways to dismiss a SwiftUI modal or detail view — two of which that are backward compatible with iOS 14 and earlier, and a modern version that should ideally be used within apps that are targeting iOS 15 (or its sibling operating systems).

I hope that you found this article useful, and if you have any questions, comments, or feedback, then feel free to reach out via either Twitter or 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 this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

When starting to adopt Swift’s new async/await feature, we’re likely going to have to find ways to connect and bridge that pattern to any existing asynchronous code that we’ve already written within a given project.

Earlier this week, we took a look at how that can be done when it comes to completion handler-based APIs, and how single-output Combine publishers can be made async/await-compatible. In this article, let’s continue that journey by exploring how we can make it possible to call async-marked functions within a Combine pipeline.

Please note that, at the time of writing, Swift 5.5 is currently in beta as part of Xcode 13.

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

Future-proofing

Let’s start by extending Combine’s Publisher protocol with a custom operator called asyncMap. Internally, we’ll then perform a flatMap using Combine’s built-in Future type, and we’ll then use an async block to trigger our asynchronous transform — like this:

extension Publisher {
    func asyncMap<T>(
        _ transform: @escaping (Output) async -> T
    ) -> Publishers.FlatMap<Future<T, Never>, Self> {
        flatMap { value in
            Future { promise in
                async {
                    let output = await transform(value)
                    promise(.success(output))
                }
            }
        }
    }
}

It could be argued that the above operator should instead be an overload of the standard flatMap operator (since that’s the type operation that we’re actually performing under the hood). Naming is hard, but in this case, I think using a new name makes things more clear (given that we’re not actually returning a new publisher within our transformation closure), and also mimics the design of other map variants, such as tryMap.

With the above in place, we’ll now be able to freely call any non-throwing async function within a Combine pipeline. For example, here we’re mixing a Combine-powered call to a ColorProfile API with a series of async function calls:

struct PhotoRenderer {
    var colorProfile: ColorProfile
    var effect: PhotoEffect

    func render(_ photo: Photo) -> AnyPublisher<UIImage, Never> {
        colorProfile
            .apply(to: photo)
            .asyncMap { photo in
                let photo = await effect.apply(to: photo)
return await uiImage(from: photo)
            }
            .eraseToAnyPublisher()
    }

    private func uiImage(from photo: Photo) async -> UIImage {
        ...
    }
}

What’s really nice about the above new capability is that it enables us to more seamlessly migrate parts of a code base to async/await, while still keeping all of our existing Combine-based APIs completely intact.

Throwing asynchronous functions

Next, let’s also enable throwing async functions to be called within our Combine pipelines. That requires a second asyncMap overload that accepts a closure that throws, and that automatically forwards any error that was thrown to our wrapping Future:

extension Publisher {
    func asyncMap<T>(
        _ transform: @escaping (Output) async throws -> T
    ) -> Publishers.FlatMap<Future<T, Error>, Self> {
        flatMap { value in
            Future { promise in
                async {
                    do {
    let output = try await transform(value)
    promise(.success(output))
} catch {
    promise(.failure(error))
}
                }
            }
        }
    }
}

Using the above new overload, we’ll now be able to easily insert any throwing async function calls into our Combine pipelines as well. For example, the following LoginStateController uses a Combine-powered Keychain API, which is then connected to an async/await-powered UserLoader to produce our final pipeline:

class LoginStateController {
    private let keychain: Keychain
    private let userLoader: UserLoader
    ...

    func loadLoggedInUser() -> AnyPublisher<User, Error> {
        keychain
            .loadLoggedInUserID()
            .asyncMap { [userLoader] userID in
                try await userLoader.loadUser(withID: userID)
            }
            .eraseToAnyPublisher()
    }
}

Note how we’re explicitly capturing our userLoader within the above asyncMap closure, to avoid having to capture a self reference. To learn more about that technique, check out “Swift’s closure capturing mechanics”.

Although we’ve now covered the vast majority of use cases when it comes to Combine and async/await interoperability, there’s one more type of situation that might be good to handle — and that’s to enable a throwing async function to be called within a non-throwing Combine pipeline.

Thankfully, this is something that the built-in flatMap operator is already handling (through a dedicated overload), so all that we have to do is to create a third overload of asyncMap that has an output type that matches that specific version of flatMap:

extension Publisher {
    func asyncMap<T>(
        _ transform: @escaping (Output) async throws -> T
    ) -> Publishers.FlatMap<Future<T, Error>,
                            Publishers.SetFailureType<Self, Error>> {
        flatMap { value in
            Future { promise in
                async {
                    do {
                        let output = try await transform(value)
                        promise(.success(output))
                    } catch {
                        promise(.failure(error))
                    }
                }
            }
        }
    }
}

With the above in place, we’ll now be able to extend any non-throwing Combine pipeline with a throwing asyncMap call. For example, here we’re connecting the non-throwing PhotoRenderer API that we took a look at earlier to a throwing call to one of the new, async/await-powered URLSession APIs for performing uploads:

struct PhotoUploader {
    var renderer: PhotoRenderer
    var urlSession = URLSession.shared

    func upload(_ photo: Photo,
                to url: URL) -> AnyPublisher<URLResponse, Error> {
        renderer
            .render(photo)
            .asyncMap { image in
                guard let data = image.pngData() else {
                    throw PhotoUploadingError.invalidImage(image)
                }

                var request = URLRequest(url: url)
                request.httpMethod = "POST"

                let (_, response) = try await urlSession.upload(
    for: request,
    from: data
)

                return response
            }
            .eraseToAnyPublisher()
    }
}

With those three asyncMap overloads in place, we’ll now be able to insert any kind of async-marked call into any Combine pipeline. Pretty great!

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 this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

Conclusion

Although I still think that Combine will remain an incredibly useful tool when it comes to reactive programming, many asynchronous APIs will likely move to async/await over time. Thankfully, that doesn’t mean that we have to rewrite any existing Combine-based code that our projects already use, since it’s definitely possible to bridge the gap between those two worlds.

I’ll continue exploring how async/await, actors, and the rest of Swift’s new concurrency system can be integrated with Combine in various ways, and will keep sharing my findings with you. I hope you enjoyed this article, and if you have any questions, comments or feedback, then feel free to reach out via either Twitter or email.

Thanks for reading!

At WWDC21, Apple introduced a new SwiftUI API that enables us to attach refresh actions to any view, which in turn now gives us native support for the very popular pull-to-refresh mechanism. Let’s take a look at how this new API works, and how it also enables us to build completely custom refreshing logic as well.

Please note that this article will cover APIs that are being introduced as part of iOS 15, and the rest of Apple’s 2021 operating systems, which are all currently in beta.

Essential Developer: If you’re a mid/senior iOS developer who’s looking to improve both your skills and your salary level, then join this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

Powered by async/await

To be able to tell when a refresh operation was completed, SwiftUI uses the async/await pattern, which is being introduced in Swift 5.5 (and is expected to be released alongside Apple’s new operating systems later this year). So before we can start adopting the new refreshing API, we’ll need an async-marked function that we can call whenever our view’s refresh action will be triggered.

As an example, let’s say that we’re working on an app that includes some form of bookmarking feature, and that we’ve built a BookmarkListViewModel that’s responsible for providing our bookmark list UI with its data. To then enable that data to be refreshed, we’ve added an asynchronous reload method, which in turn calls a DatabaseController in order to fetch an array of Bookmark models:

class BookmarkListViewModel: ObservableObject {
    @Published private(set) var bookmarks: [Bookmark]
    private let databaseController: DatabaseController
    ...

    func reload() async {
        bookmarks = await databaseController.loadAllModels(
            ofType: Bookmark.self
        )
    }
}

Now that we have an async function that can be called to refresh our view’s data, let’s apply the new refreshable modifier within our BookmarkList view — like this:

struct BookmarkList: View {
    @ObservedObject var viewModel: BookmarkListViewModel

    var body: some View {
        List(viewModel.bookmarks) { bookmark in
            ...
        }
        .refreshable {
    await viewModel.reload()
}
    }
}

Just by doing that, our List-powered UI will now support pull-to-refresh. SwiftUI will automatically hide and show a loading spinner as our refresh action is being performed, and will even ensure that no duplicate refresh actions are being performed at the same time. Really cool!

As an added bonus — given that Swift supports first class functions — we can even pass our view model’s reload method directly to the refreshable modifier, which gives us a slightly more compact implementation:

struct BookmarkList: View {
    @ObservedObject var viewModel: BookmarkListViewModel

    var body: some View {
        List(viewModel.bookmarks) { bookmark in
            ...
        }
        .refreshable(action: viewModel.reload)
    }
}

That’s really all there is to it when it comes to basic pull-to-refresh support. But that’s just the beginning — let’s keep exploring!

Error handling

When it comes to loading actions, it’s very common that those can end up throwing an error, which we’ll need to handle one way or another. For example, if the underlying loadAllModels API that our view model calls was a throwing function, then we’d have to call it using the try keyword in order to handle any error that could be thrown. One way to do that would be to simply propagate any such errors to our view, by making our top-level reload method capable of throwing as well:

class BookmarkListViewModel: ObservableObject {
    ...

    func reload() async throws {
        bookmarks = try await databaseController.loadAllModels(
            ofType: Bookmark.self
        )
    }
}

However, with the above change in place, our previous BookmarkList view code no longer compiles, since the refreshable modifier only accepts non-throwing async closures. To fix that we could, for example, wrap the call to our view model’s reload method in a do/catch statement — which would let us catch any thrown errors in order to display them using something like an ErrorView overlay:

struct BookmarkList: View {
    @ObservedObject var viewModel: BookmarkListViewModel
    @State private var error: Error?

    var body: some View {
        List(viewModel.bookmarks) { bookmark in
            ...
        }
        .overlay(alignment: .top) {
            if error != nil {
    ErrorView(error: $error)
}
        }
        .refreshable {
            do {
    try await viewModel.reload()
    error = nil
} catch {
    self.error = error
}
        }
    }
}

The reason that our ErrorView accepts a binding to an error, rather than just a plain Error value, is because we want that view to be able to dismiss itself by setting our error property to nil. To learn more, check out my guide to SwiftUI’s state management system.

While the above implementation does work, it would arguably be better to encapsulate all of our view state (including any thrown errors) within our view model, which would allow our view to focus on just rendering the data that our view model gives it. To make that happen, let’s start by moving the above do/catch statement into our view model instead — like this:

class BookmarkListViewModel: ObservableObject {
    @Published private(set) var bookmarks: [Bookmark]
    @Published var error: Error?
    ...

    func reload() async {
        do {
            bookmarks = try await databaseController.loadAllModels(
                ofType: Bookmark.self
            )
            error = nil
        } catch {
            self.error = error
        }
    }
}

With the above change in place, we can now make our view much simpler, since the fact that our reload method can throw errors now sort of becomes an implementation detail of our view model. All that our view now needs to know is that there’s an error property that it can use to display any error that was encountered (for any reason):

struct BookmarkList: View {
    @ObservedObject var viewModel: BookmarkListViewModel

    var body: some View {
        List(viewModel.bookmarks) { bookmark in
            ...
        }
        .overlay(alignment: .top) {
            if viewModel.error != nil {
                ErrorView(error: $viewModel.error)
            }
        }
        .refreshable {
            await viewModel.reload()
        }
    }
}

Very nice. But perhaps the most interesting aspect of this new refreshable modifier is that it’s not just limited to the built-in pull-to-refresh functionality that SwiftUI ships with. In fact, we can use it to power our very own, completely custom refreshing logic as well.

Custom refreshing logic

To be able to more easily build custom refreshing features, let’s start by creating a dedicated class that’ll perform our refresh actions. When passed a system-provided RefreshAction value, it’ll set an isPerforming property to true while the action is being performed, which in turn will enable us to observe that piece of state within any custom refreshing UIs that we’re looking to build:

class RefreshActionPerformer: ObservableObject {
    @Published private(set) var isPerforming = false

    func perform(_ action: RefreshAction) async {
        guard !isPerforming else { return }
        isPerforming = true
        await action()
        isPerforming = false
    }
}

Next, let’s build a RetryButton that will enable our users to retry a given refresh action if it ended up failing. To do that, we’ll use the new refresh environment value, which gives us access to any RefreshAction that was injected into our view hierarchy using the refreshable modifier. We’ll then pass any such action to an instance of our newly created RefreshActionPerformer — like this:

struct RetryButton: View {
    var title: LocalizedStringKey = "Retry"
    
    @Environment(\.refresh) private var action
    @StateObject private var actionPerformer = RefreshActionPerformer()

    var body: some View {
        if let action = action {
            Button(
                role: nil,
                action: {
                    await actionPerformer.perform(action)
                },
                label: {
                    ZStack {
                        if actionPerformer.isPerforming {
                            Text(title).hidden()
                            ProgressView()
                        } else {
                            Text(title)
                        }
                    }
                }
            )
            .disabled(actionPerformer.isPerforming)
        }
    }
}

Note how we’re rendering a hidden version of our label while our loading spinner is being displayed. That’s to prevent the button’s size from changing as it transitions between its idle and loading states.

The fact that SwiftUI inserts our refresh actions into the environment is incredibly powerful, as that lets us define a single action that can then be picked up and used by any view that’s within that particular view hierarchy. So, without making any changes to our BookmarkList view, if we now simply insert our new RetryButton into our ErrorView, then it’ll be able to perform the exact same refreshing action as our List uses — simply because that action exists within our view hierarchy’s environment:

struct ErrorView: View {
    @Binding var error: Error?

    var body: some View {
        if let error = error {
            VStack {
                Text(error.localizedDescription)
                    .bold()
                HStack {
                    Button("Dismiss") {
                        self.error = nil
                    }
                    RetryButton()
                }
            }
            .padding()
            .background(Color.red)
            .foregroundColor(.white)
            .cornerRadius(10)
        }
    }
}

How cool isn’t that? I love when Apple places data like this in the SwiftUI environment, and makes it publicly accessible, since that opens up so many powerful ways to build custom UIs and logic, like I think the above example shows.

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 this 100% free online crash course, starting on August 2nd. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions.

Conclusion

So that’s the new refreshable modifier and how it can both be used to implement system-provided UI patterns (like pull-to-refresh), and how we can also use it to build completely custom reloading logic as well.

I hope you found this article useful, and if you have any questions, comments, or feedback, then feel free to reach out via either Twitter or email. And, if you did find this article useful, then please share it with a friend (or check out the above sponsor), since that really helps support me and my work.

Thanks for reading!