Swift’s type inference capabilities have been a very core part of the language since the very beginning, and heavily reduces the need for us to manually specify types when declaring variables and properties that have default values. For example, the expression var number = 7 doesn’t need to include any type annotations, since the compiler is able to infer that the value 7 is an Int and that our number variable should be typed accordingly.

Swift 5.6, which was released as part of Xcode 13.3, continues to expand these type inference capabilities by introducing the concept of “type placeholders”, which can come very much in handy when working with collections and other generic types.

For example, let’s say that we wanted to create an instance of Combine’s CurrentValueSubject with a default integer value. An initial idea on how to do just that might be to simply pass our default value to that subject’s initializer, and then store the result in a local let (just like when creating a plain Int value). However, doing so gives us the following compiler error:

// Error: "Generic parameter 'Failure' could not be inferred"
let counterSubject = CurrentValueSubject(0)

That’s because CurrentValueSubject is a generic type that needs to be specialized with not just an Output type, but also with a Failure type — which is the type of error that the subject is capable of throwing.

Since we don’t want our subject to throw any errors in this case, we’ll give it the failure type Never (which is a common convention when using both Combine and Swift concurrency). But in order to do that, prior to Swift 5.6, we would need to explicitly specify our Int output type as well — like this:

let counterSubject = CurrentValueSubject<Int, Never>(0)

Starting in Swift 5.6, though, that’s no longer the case — as we can now use a type placeholder for our subject’s output type, which lets us once again leverage the compiler to automatically infer that type for us, just like when declaring a plain Int value:

let counterSubject = CurrentValueSubject<_, Never>(0)

That’s nice, but it’s arguably not the biggest improvement in the world. After all, we’re only saving two characters by replacing Int with _, and it’s not like manually specifying a simple type like Int was something problematic to begin with.

But let’s now take a look at how this feature scales to more complex types, which is where it really starts to shine. For example, let’s say that our project contains the following function that lets us load a user-annotated PDF file:

func loadAnnotatedPDF(named: String) -> Resource<PDF<UserAnnotations>> {
    ...
}

The above function uses a quite complex generic as its return type, which might be because we’re reusing our Resource type across multiple domains, and because we’ve opted to use phantom types to specify what kind of PDF that we’re currently dealing with.

Now let’s take a look at what our CurrentValueSubject-based code from before would look like if we were to call the above function when creating our subject, rather than just using a simple integer:

// Before Swift 5.6:
let pdfSubject = CurrentValueSubject<Resource<PDF<UserAnnotations>>, Never>(
    loadAnnotatedPDF(named: name)
)

// Swift 5.6:
let pdfSubject = CurrentValueSubject<_, Never>(
    loadAnnotatedPDF(named: name)
)

That’s quite a huge improvement! Not only does the Swift 5.6-based version save us some typing, but since the type of pdfSubject is now derived completely from the loadAnnotatedPDF function, that’ll likely make iterating on that function (and its related code) much easier — since there will be fewer manual type annotations that will need to be updated if we ever change that function’s return type.

It’s worth pointing out, though, that there’s another way to leverage Swift’s type inference capabilities in situations like the one above — and that’s to use a type alias, rather than a type placeholder. For example, here’s how we could define an UnfailingValueSubject type alias, which we’ll be able to use to easily create subjects that aren’t capable of throwing any errors:

typealias UnfailingValueSubject<T> = CurrentValueSubject<T, Never>

With the above in place, we’ll now be able to create our pdfSubject without any kind of generic type annotations at all — since the compiler is able to infer what type that T refers to, and since the failure type Never has been hard-coded into our new type alias:

let pdfSubject = UnfailingValueSubject(loadAnnotatedPDF(named: name))

That doesn’t mean that type aliases are universally better than type placeholders, though, since if we were to define new type aliases for each particular situation, then that could also make our code base much more complicated. Sometimes, specifying everything inline (like when using a type placeholder) is definitely the way to go, as that lets us define expressions that are completely self-contained.

Before we wrap things up, let’s also take a look at how type placeholders can be used with collection literals — for example when creating a dictionary. Here, we’ve opted to manually specify our dictionary’s Key type (in order to be able to use dot-syntax to refer to an enum’s various cases), while using a type placeholder for that dictionary’s values:

enum UserRole {
    case local
    case remote
}

let latestMessages: [UserRole: _] = [
    .local: "",
    .remote: ""
]

So that’s type placeholders — a new feature introduced in Swift 5.6, which will likely be really useful when dealing with slightly more complex generic types. It’s worth pointing out, though, that these placeholders can only be used at call sites, not when specifying the return types of either functions or computed properties.

I hope you found this article useful, and feel free to let me know if you have any questions, comments, or feedback — either via Twitter or email.

Thanks for reading!

In object-oriented programming, an abstract type provides a base implementation that other types can inherit from in order to gain access to some kind of shared, common functionality. What separates abstract types from regular ones is that they’re never meant to be used as-is (in fact, some programming languages even prevent abstract types from being instantiated directly), since their sole purpose is to act as a common parent for a group of related types.

For example, let’s say that we wanted to unify the way we load certain types of models over the network, by providing a shared API that we’ll be able to use to separate concerns, to facilitate dependency injection and mocking, and to keep method names consistent throughout our project.

One abstract type-based way to do that would be to use a base class that’ll act as that shared, unified interface for all of our model-loading types. Since we don’t want that class to ever be used directly, we’ll make it trigger a fatalError if its base implementation is ever called by mistake:

class Loadable<Model> {
    func load(from url: URL) async throws -> Model {
        fatalError("load(from:) has not been implemented")
    }
}

Then, each Loadable subclass will override the above load method in order to provide its loading functionality — like this:

class UserLoader: Loadable<User> {
    override func load(from url: URL) async throws -> User {
        ...
    }
}

If the above sort of pattern looks familiar, it’s probably because it’s essentially the exact same sort of polymorphism that we typically use protocols for in Swift. That is, when we want to define an interface, a contract, that multiple types can conform to through distinct implementations.

Protocols do have a significant advantage over abstract classes, though, in that the compiler will enforce that all of their requirements are properly implemented — meaning we no longer have to rely on runtime errors (such as fatalError) to guard against improper use, since there’s no way to instantiate a protocol by itself.

So here’s what our Loadable and UserLoader types from before could look like if we were to go the protocol-oriented route, rather than using an abstract base class:

protocol Loadable {
    associatedtype Model
    func load(from url: URL) async throws -> Model
}

class UserLoader: Loadable {
    func load(from url: URL) async throws -> User {
        ...
    }
}

Note how we’re now using an associated type to enable each Loadable implementation to decide what exact Model that it wants to load — which gives us a nice mix between full type safety and great flexibility.

So, in general, protocols are definitely the preferred way to declare abstract types in Swift, but that doesn’t mean that they’re perfect. In fact, our protocol-based Loadable implementation currently has two main drawbacks:

• First, since we had to add an associated type to our protocol in order to keep our setup generic and type-safe, that means that Loadable can no longer be referenced directly.
• And second, since protocols can’t contain any form of storage, if we wanted to add any stored properties that all Loadable implementations could make use of, we’d have to re-declare those properties within every single one of those concrete implementations.

That property storage aspect is really a huge advantage of our previous, abstract class-based setup. So if we were to revert Loadable back to a class, then we’d be able to store all objects that our subclasses would need right within our base class itself — removing the need to duplicate those properties across multiple types:

class Loadable<Model> {
    let networking: Networking
let cache: Cache<URL, Model>

    init(networking: Networking, cache: Cache<URL, Model>) {
        self.networking = networking
        self.cache = cache
    }

    func load(from url: URL) async throws -> Model {
        fatalError("load(from:) has not been implemented")
    }
}

class UserLoader: Loadable<User> {
    override func load(from url: URL) async throws -> User {
        if let cachedUser = cache.value(forKey: url) {
            return cachedUser
        }

        let data = try await networking.data(from: url)
        ...
    }
}

So, what we’re dealing with here is essentially a classic trade-off scenario, where both approaches (abstract classes vs protocols) give us a different set of pros and cons. But what if we could combine the two to sort of get the best of both worlds?

If we think about it, the only real issue with the abstract class-based approach is that fatalError that we had to add within the method that each subclass is required to implement, so what if we were to use a protocol just for that specific method? Then we could still keep our networking and cache properties within our base class — like this:

protocol LoadableProtocol {
    associatedtype Model
    func load(from url: URL) async throws -> Model
}

class LoadableBase<Model> {
    let networking: Networking
let cache: Cache<URL, Model>

    init(networking: Networking, cache: Cache<URL, Model>) {
        self.networking = networking
        self.cache = cache
    }
}

The main disadvantage of that approach, though, is that all concrete implementations will now have to both subclass LoadableBase and declare that they conform to our new LoadableProtocol:

class UserLoader: LoadableBase<User>, LoadableProtocol {
    ...
}

That might not be a huge issue, but it does arguably make our code a bit less elegant. The good news, though, is that we can actually solve that issue by using a generic type alias. Since Swift’s composition operator, &, supports combining a class with a protocol, we can re-introduce our Loadable type as a combination between LoadableBase and LoadableProtocol:

typealias Loadable<Model> = LoadableBase<Model> & LoadableProtocol

That way, concrete types (such as UserLoader) can simply declare that they’re Loadable-based, and the compiler will ensure that all such types implement our protocol’s load method — while still enabling those types to use the properties declared within our base class as well:

class UserLoader: Loadable<User> {
    func load(from url: URL) async throws -> User {
        if let cachedUser = cache.value(forKey: url) {
            return cachedUser
        }

        let data = try await networking.data(from: url)
        ...
    }
}

Neat! The only real disadvantage of the above approach is that Loadable still can’t be referenced directly, since it’s still partially a generic protocol under the hood. That might not actually be an issue, though — and if that ever becomes the case, then we could always use techniques such as type erasure to get around such problems.

Another slight caveat with our new type alias-based Loadable setup is that such combined type aliases cannot be extended, which could become an issue if we wanted to provide a few convenience APIs that we don’t want to (or can’t) implement directly within our LoadableBase class.

One way to address that issue, though, would be to declare everything that’s needed to implement those convenience APIs within our protocol, which would then enable us to extend that protocol by itself:

protocol LoadableProtocol {
    associatedtype Model

    var networking: Networking { get }
var cache: Cache<URL, Model> { get }

    func load(from url: URL) async throws -> Model
}

extension LoadableProtocol {
    func loadWithCaching(from url: URL) async throws -> Model {
        if let cachedModel = cache.value(forKey: url) {
            return cachedModel
        }

        let model = try await load(from: url)
        cache.insert(model, forKey: url)
        return model
    }
}

So that’s a few different ways to use abstract types and methods in Swift. Subclassing might not currently be as popular as it once was (and remains to be within other programming languages), but I still think these sorts of techniques are great to have within our overall Swift development toolbox.

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

Thanks for reading!

A major part of the challenge of architecting UI-focused code bases tends to come down to deciding where to draw the line between the code that needs to interact with the platform’s various UI frameworks, versus code that’s completely within our own app’s domain of logic.

That task might become especially tricky when working with SwiftUI, as so much of our UI-centric logic tends to wind up within our various View declarations, which in turn often makes such code really difficult to verify using unit tests.

So, in this article, let’s take a look at how we could deal with that problem, and explore how to make UI-related logic fully testable — even when that logic is primarily used within SwiftUI-based views.

Logic intertwined with views

“You shouldn’t put business logic within your views”, is a piece of advice that’s often mentioned when discussing unit testing within the context of UI-based projects, such as iOS and Mac apps. However, in practice, that advice can sometimes be tricky to follow, as the most natural or intuitive place to put view-related logic is often within the views themselves.

As an example, let’s say that we’re working on an app that contains the following SendMessageView. Although the actual message sending logic (and its associated networking) has already been abstracted using a MessageSender protocol, all of the UI-specific logic related to sending messages is currently embedded right within our view:

struct SendMessageView: View {
    var sender: MessageSender

    @State private var message = ""
@State private var isSending = false
@State private var sendingError: Error?

    var body: some View {
        VStack {
            Text("Your message:")

            TextEditor(text: $message)

            Button(isSending ? "Sending..." : "Send") {
                isSending = true
                sendingError = nil
            
                Task {
                    do {
    try await sender.sendMessage(message)
    message = ""
} catch {
    sendingError = error
}

                    isSending = false
                }
            }
            .disabled(isSending || message.isEmpty)

            if let error = sendingError {
                Text(error.localizedDescription)
                    .foregroundColor(.red)
            }
        }
    }
}

At first glance, the above might not look so bad. Our view isn’t massive by any stretch of the imagination, and the code is quite well-organized. However, unit testing that view’s logic would currently be incredibly difficult — as we’d have to find some way to spin up our view within our tests, then find its various UI controls (such as its “Send” button), and then figure out a way to trigger and observe those views ourselves.

Because we have to remember that SwiftUI views aren’t actual, concrete representations of the UI that we’re drawing on-screen, which can then be controlled and inspected as we wish. Instead, they’re ephemeral descriptions of what we want our various views to look like, which the system then renders and manages on our behalf.

So, although we could most likely find a way to unit test our SwiftUI views directly — ideally, we’ll probably want to verify our logic in a much more controlled, isolated environment.

One way to create such an isolated environment would be to extract all of the logic that we’re looking to test out from our views, and into objects and functions that are under our complete control — for example by using a view model. Here’s what such a view model could end up looking like if we were to move all of our message sending UI logic out from our SendMessageView:

@MainActor class SendMessageViewModel: ObservableObject {
    @Published var message = ""
@Published private(set) var errorText: String?

var buttonTitle: String { isSending ? "Sending..." : "Send" }
var isSendingDisabled: Bool { isSending || message.isEmpty }

    private let sender: MessageSender
    private var isSending = false

    init(sender: MessageSender) {
        self.sender = sender
    }

    func send() {
        guard !message.isEmpty else { return }
        guard !isSending else { return }

        isSending = true
        errorText = nil

        Task {
            do {
                try await sender.sendMessage(message)
                message = ""
            } catch {
                errorText = error.localizedDescription
            }

            isSending = false
        }
    }
}

To learn more about constructing and using observable objects, check out this guide to SwiftUI’s state management system.

Our logic remains almost identical, but the above refactor does give us two quite significant benefits. First, we’ll now be able to unit test our code without having to worry about SwiftUI at all. And second, we’ll even be able to improve our SwiftUI view itself, as our view model now contains all of the logic that our view needs to decide how it should be rendered — making that UI code much simpler in the process:

struct SendMessageView: View {
    @ObservedObject var viewModel: SendMessageViewModel

    var body: some View {
        VStack(alignment: .leading) {
            Text("Your message:")

            TextEditor(text: $viewModel.message)

            Button(viewModel.buttonTitle) {
                viewModel.send()
            }
            .disabled(viewModel.isSendingDisabled)

            if let errorText = viewModel.errorText {
                Text(errorText).foregroundColor(.red)
            }
        }
    }
}

Fantastic! To now shift our focus to unit testing our code, we’re going to need two pieces of infrastructure before we can actually start writing our test cases. While those two pieces are not strictly required, they’re going to help us make our testing code so much simpler and easier to read.

Investing in utilities

First, let’s create a mocked implementation of our MessageSender protocol, which will enable us to gain complete control over how messages are sent, as well as how errors are thrown during that process:

class MessageSenderMock: MessageSender {
    @Published private(set) var pendingMessageCount = 0
    private var pendingMessageContinuations = [CheckedContinuation<Void, Error>]()

    func sendMessage(_ message: String) async throws {
        return try await withCheckedThrowingContinuation { continuation in
            pendingMessageContinuations.append(continuation)
            pendingMessageCount += 1
        }
    }

    func sendPendingMessages() {
        let continuations = pendingMessageContinuations
        pendingMessageContinuations = []
        pendingMessageCount = 0
        continuations.forEach { $0.resume() }
    }

    func triggerError(_ error: Error) {
        let continuations = pendingMessageContinuations
        pendingMessageContinuations = []
        pendingMessageCount = 0
        continuations.forEach { $0.resume(throwing: error) }
    }
}

To learn more about Swift’s continuation system, check out “Connecting async/await to other Swift code”.

Next, since the code that we’re looking to verify is asynchronous, we’re going to need a way to wait for a given state to be entered before proceeding with our verifications. Since we don’t want to put any observation logic within our tests themselves, let’s extend XCTestCase with a method that’ll let us wait until a given @Published-marked property has been assigned a specific value:

extension XCTestCase {
    func waitUntil<T: Equatable>(
        _ propertyPublisher: Published<T>.Publisher,
        equals expectedValue: T,
        timeout: TimeInterval = 10,
        file: StaticString = #file,
        line: UInt = #line
    ) {
        let expectation = expectation(
            description: "Awaiting value \(expectedValue)"
        )
        
        var cancellable: AnyCancellable?

        cancellable = propertyPublisher
            .dropFirst()
            .first(where: { $0 == expectedValue })
            .sink { value in
                XCTAssertEqual(value, expectedValue, file: file, line: line)
                cancellable?.cancel()
                expectation.fulfill()
            }

        waitForExpectations(timeout: timeout, handler: nil)
    }
}

Above we’re using Apple’s Combine framework to observe the injected Published property’s publisher (wow, that’s quite a tongue twister, isn’t it?). To learn more about Combine, and published properties in particular, check out this Discover page.

With those two pieces in place, we can now finally start writing the unit tests for our UI-related message sending logic! It might, at first, seem rather unnecessary to create all of that infrastructure just to be able to verify some simple pieces of logic — but the utilities that we’ve now created will really make our testing code much easier (and more enjoyable) to write.

It’s testing time!

Let’s start by verifying that our “Send” button will be correctly enabled and disabled based on whether the user has entered a message. To do that, we’ll start by setting up an XCTestCase subclass for our tests, and we’ll then be able to easily simulate a message being entered simply by assigning a string to our view model’s message property:

@MainActor class SendMessageViewModelTests: XCTestCase {
    private var sender: MessageSenderMock!
    private var viewModel: SendMessageViewModel!

    @MainActor override func setUp() {
        super.setUp()
        sender = MessageSenderMock()
        viewModel = SendMessageViewModel(sender: sender)
    }

    func testSendingDisabledWhileMessageIsEmpty() {
        XCTAssertTrue(viewModel.isSendingDisabled)
        viewModel.message = "Message"
        XCTAssertFalse(viewModel.isSendingDisabled)
        viewModel.message = ""
        XCTAssertTrue(viewModel.isSendingDisabled)
    }
}

Note that we need to add the MainActor attribute to both our test case itself, as well as to the setUp method that we’re overriding from the XCTestCase base class. Otherwise we wouldn’t be able to easily interact with our view model’s APIs, since those are also bound to the main actor. To learn more, check out this article.

Alright, our first test is done, but we’re just getting started. Next, let’s verify that the correct states are entered while sending a message — and this is where the two utilities that we built earlier (our MessageSenderMock class and our waitUntil method) will come very much in handy:

@MainActor class SendMessageViewModelTests: XCTestCase {
    ...

    func testSuccessfullySendingMessage() {
        // First, start sending a message, and verify the current state:
        viewModel.message = "Message"
        viewModel.send()
        waitUntil(sender.$pendingMessageCount, equals: 1)

        XCTAssertEqual(viewModel.buttonTitle, "Sending...")
        XCTAssertTrue(viewModel.isSendingDisabled)

        // Then, finish sending the message, and verify the end state:
        sender.sendPendingMessages()
        waitUntil(viewModel.$message, equals: "")

        XCTAssertEqual(viewModel.buttonTitle, "Send")
    }
}

That’s really the power of investing in testing infrastructure like mocks and various utility functions — they let our testing methods remain completely linear, and free from cancellables, expectations, and other sources of complexity.

Let’s write one more test. This time, we’ll verify that our code behaves correctly when an error was encountered:

@MainActor class SendMessageViewModelTests: XCTestCase {
    ...

    func testHandlingMessageSendingError() {
        // First, start sending a message:
        viewModel.message = "Message"
        viewModel.send()
        waitUntil(sender.$pendingMessageCount, equals: 1)

        // Then, make the sender throw an error and verify it:
        let error = URLError(.badServerResponse)
        sender.triggerError(error)
        waitUntil(viewModel.$errorText, equals: error.localizedDescription)

        XCTAssertEqual(viewModel.message, "Message")
        XCTAssertEqual(viewModel.buttonTitle, "Send")
        XCTAssertFalse(viewModel.isSendingDisabled)
    }
}

Just like that, we’ve now fully covered our UI-related message sending logic with unit tests — without having to actually attempt to unit test our SwiftUI view itself. As an added bonus, we also made our view code simpler in the process, and it should now be much easier to iterate on our view’s logic and styling completely separately.

Combine the above approach with a few UI tests, as well as manual testing, and we should be able to release new versions of our app with confidence.

Is MVVM required for testability?

Now, is the point of the above series of examples that all SwiftUI-based apps should completely adopt the MVVM (Model-View-ViewModel) architecture? No, absolutely not. Instead, the point is that the easiest way to unit test any kind of UI-related code (regardless of what UI framework that the code was originally written against) is most often to move that code out from whatever view that it’s being consumed in. That way, our logic is no longer tied to any specific UI framework, and we’re free to test and manage it however we’d like.

To further prove that this article isn’t about advocating for “MVVM all the things!”, let’s take a look at another example, in which using a view model would probably be quite unnecessary.

Here we’ve written an EventSelectionView, which also has a significant piece of logic embedded within it — this time for deciding whether a given Event should be auto-selected when the user taps a button:

struct EventSelectionView: View {
    var events: [Event]
    @Binding var selection: Event?

    var body: some View {
        List(events) { event in
            ...
        }
        .toolbar {
            Button("Select next available") {
                selection = events.first(where: { event in
                    guard event.isBookable else {
                        return false
                    }

                    guard event.participants.count < event.capacity else {
                        return false
                    }

                    return event.startDate > .now
                })
            }
        }
    }
}

Just like when we refactored our SendMessageView earlier, one way to make the above logic testable would be to create another view model, and move our logic there. But, let’s take a different (more lightweight) approach this time, and instead move that logic into our Event type itself:

extension Event {
    var isSelectable: Bool {
        guard isBookable else {
            return false
        }

        guard participants.count < capacity else {
            return false
        }

        return startDate > .now
    }
}

After all, the above logic isn’t very UI-related at all (it doesn’t mutate any form of view state, and it just inspects properties that are owned by Event itself), so it doesn’t really warrant the creation of a dedicated view model.

And, even without a view model, we can still fully test the above code, simply by creating and mutating an Event value:

class EventTests: XCTestCase {
    private var event: Event!

    override func setUp() {
        super.setUp()

        event = Event(
            id: UUID(),
            capacity: 1,
            isBookable: true,
            startDate: .distantFuture
        )
    }

    func testEventIsSelectableByDefault() {
        XCTAssertTrue(event.isSelectable)
    }

    func testUnBookableEventIsNotSelectable() {
        event.isBookable = false
        XCTAssertFalse(event.isSelectable)
    }

    func testFullyBookedEventIsNotSelectable() {
        event.participants = [.stub()]
        XCTAssertFalse(event.isSelectable)
    }

    func testPastEventIsNotSelectable() {
        event.startDate = .distantPast
        XCTAssertFalse(event.isSelectable)
    }
}

Just like before, a big benefit of performing the above kind of logic extraction is that doing so also tends to make our SwiftUI-based code much simpler. Thanks to our new Event extension, EventSelectionView can now simply use Swift’s key path syntax to pick the first selectable event — like this:

struct EventSelectionView: View {
    var events: [Event]
    @Binding var selection: Event?

    var body: some View {
        List(events) { event in
            ...
        }
        .toolbar {
            Button("Select next available") {
                selection = events.first(where: \.isSelectable)
            }
        }
    }
}

So, regardless of whether we choose to go for a view model, a simple model extension, or another kind of metaphor — if we can move the UI logic that we’re looking to test out from our views themselves, then those tests tend to be much easier to write and maintain.

Conclusion

So, how do I unit test my SwiftUI views? The answer is quite simply: I don’t. I also almost never test my UIView implementations either. Instead, I focus on extracting all of the logic that I wish to test out from my views and into objects that are under my complete control. That way, I can spend less time fighting with Apple’s UI frameworks in order to make them unit testing-friendly, and more time writing solid, reliable tests.

I hope that this article has given you a few ideas on how you could make your SwiftUI-based code easier to test as well. If you have any questions, comments, or feedback, then feel free to reach out via either Twitter or email.

Thanks for reading!

One of the core strengths of Swift’s protocols is that they enable us to define shared interfaces that multiple types can conform to, which in turn lets us interact with those types in a very uniform way, without necessarily knowing what underlying type that we’re currently dealing with.

For example, to clearly define an API that enables us to persist a given instance onto disk, we might choose to use a protocol that looks something like this:

protocol DiskWritable {
    func writeToDisk(at url: URL) throws
}

One advantage of defining commonly used APIs that way is that it helps us keep our code consistent, as we can now make any type that should be disk-writable conform to the above protocol, which then requires us to implement the exact same method for all such types.

Another big advantage of Swift protocols is that they’re extendable, which makes it possible for us to define all sorts of convenience APIs for both our own protocols, as well as those that are defined externally — for example within the standard library, or within any framework that we’ve imported.

When writing those kinds of convenience APIs, we might also want to mix the protocol that we’re currently extending with some functionality provided by another protocol. For example, let’s say that we wanted to provide a default implementation of our DiskWritable protocol’s writeToDisk method for types that also conform to the Encodable protocol — since a type that’s encodable can be transformed into Data, which we could then automatically write to disk.

One way to make that happen would be to make our DiskWritable protocol inherit from Encodable, which in turn will require all conforming types to implement both of those two protocols’ requirements. We could then simply extend DiskWritable in order to add that default implementation of writeToDisk that we were looking to provide:

protocol DiskWritable: Encodable {
    func writeToDisk(at url: URL) throws
}

extension DiskWritable {
    func writeToDisk(at url: URL) throws {
        let encoder = JSONEncoder()
        let data = try encoder.encode(self)
        try data.write(to: url)
    }
}

While powerful, the above approach does have a quite significant downside, in that we’ve now completely coupled our DiskWritable protocol with Encodable — meaning that we can no longer use that protocol by itself, without also requiring any conforming type to also fully implement Encodable, which might become problematic.

Another, much more flexible approach would be to let DiskWritable remain a completely stand-alone protocol, and instead write a type-constrained extension that only adds our default writeToDisk implementation to types that also conform to Encodable separately — like this:

extension DiskWritable where Self: Encodable {
    func writeToDisk(at url: URL) throws {
        let encoder = JSONEncoder()
        let data = try encoder.encode(self)
        try data.write(to: url)
    }
}

The tradeoff here is that the above approach does require each type that wants to leverage our default writeToDisk implementation to explicitly conform to both DiskWritable and Encodable, which might not be a big deal, but it could make it a bit harder to discover that default implementation — since it’s no longer automatically available on all DiskWritable-conforming types.

One way to address that discoverability issue, though, could be to create a convenience type alias (using Swift’s protocol composition operator, &) that gives us an indication that DiskWritable and Encodable can be combined to unlock new functionality:

typealias DiskWritableByEncoding = DiskWritable & Encodable

When a type conforms to those two protocols (either using the above type alias, or completely separately), it’ll now get access to our default writeToDisk implementation (while still having the option to provide its own, custom implementation as well):

struct TodoList: DiskWritableByEncoding {
    var name: String
    var items: [Item]
    ...
}

let list = TodoList(...)
try list.writeToDisk(at: fileURL)

Combining protocols like that can be a really powerful technique, as we’re not just limited to adding default implementations of protocol requirements — we can also add brand new APIs to any protocol combination, simply by adding new methods or computed properties within one of our extensions.

For example, here we’ve added a second overload of our writeToDisk method, which makes it possible to pass a custom JSONEncoder that’ll be used when serializing the current instance:

extension DiskWritable where Self: Encodable {
    func writeToDisk(at url: URL, encoder: JSONEncoder) throws {
        let data = try encoder.encode(self)
        try data.write(to: url)
    }

    func writeToDisk(at url: URL) throws {
        try writeToDisk(at: url, encoder: JSONEncoder())
    }
}

We do have to be bit careful not to over-use the above pattern, though, since doing so could introduce conflicts if a given type ends up getting access to multiple default implementations of the same method.

To illustrate, let’s say that our code base also contains a DataConvertible protocol, which we’d like to extend with a similar, default implementation of writeToDisk — like this:

protocol DataConvertible {
    func convertToData() throws -> Data
}

extension DiskWritable where Self: DataConvertible {
    func writeToDisk(at url: URL) throws {
        let data = try convertToData()
        try data.write(to: url)
    }
}

While both of the two DiskWritable extensions that we’ve now created make perfect sense in isolation, we’ll now end up with a conflict if a given DiskWritable-conforming type also wants to conform to both Encodable and DataConvertible at the same time (which is highly likely, since both of those protocols are about transforming an instance into Data).

Since the compiler won’t be able to pick which default implementation to use in cases like that, we’d have to manually implement our writeToDisk method specifically for each of those conflicting types. Not a big problem, perhaps, but it could lead us to a situation where it’s hard to tell which method implementation that will be used for which type, which in turn could make our code feel quite unpredictable and harder to debug and maintain.

So let’s also explore one final, alternative approach to the above set of problems — which would be to implement our disk-writing convenience APIs within a dedicated type, rather than using protocol extensions. For example, here’s how we could define an EncodingDiskWriter, which only requires the types that it’ll be used with to conform to Encodable, since the writer itself conforms to DiskWritable:

struct EncodingDiskWriter<Value: Encodable>: DiskWritable {
    var value: Value
    var encoder = JSONEncoder()

    func writeToDisk(at url: URL) throws {
        let data = try encoder.encode(value)
        try data.write(to: url)
    }
}

So even though the following Document type doesn’t conform to DiskWritable, we can still easily write its data to disk using our new EncodingDiskWriter:

struct Document: Identifiable, Codable {
    let id: UUID
    var name: String
    ...
}

class EditorViewController: UIViewController {
    private var document: Document
    private var fileURL: URL
    ...

    private func save() throws {
        let writer = EncodingDiskWriter(value: document)
try writer.writeToDisk(at: fileURL)
    }
}

So, although protocol extensions provide us with an incredibly powerful set of tools, it’s always important to remember that there are other alternatives that might be a better fit for what we’re trying to build.

Like with so many things in programming, there are no right or wrong answers here, but I hope that this article has shown a few different ways to combine the functionality of multiple protocols, and what sort of tradeoffs that each approach comes with. If you have any questions, comments, or feedback, then feel free to send me an email, or reach out via Twitter.

Thanks for reading!

Managing an app’s memory is something that tends to be especially tricky to do within the context of asynchronous code, as various objects and values often need to be captured and retained over time in order for our asynchronous calls to be performed and handled.

While Swift’s relatively new async/await syntax does make many kinds of asynchronous operations easier to write, it still requires us to be quite careful when it comes to managing the memory for the various tasks and objects that are involved in such asynchronous code.

Implicit captures

One interesting aspect of async/await (and the Task type that we need to use to wrap such code when calling it from a synchronous context) is how objects and values often end up being implicitly captured while our asynchronous code is being executed.

For example, let’s say that we’re working on a DocumentViewController, which downloads and displays a Document that was downloaded from a given URL. To make our download execute lazily when our view controller is about to be displayed to the user, we’re starting that operation within our view controller’s viewWillAppear method, and we’re then either rendering the downloaded document once available, or showing any error that was encountered — like this:

class DocumentViewController: UIViewController {
    private let documentURL: URL
    private let urlSession: URLSession

    ...

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

        Task {
            do {
                let (data, _) = try await urlSession.data(from: documentURL)
                let decoder = JSONDecoder()
                let document = try decoder.decode(Document.self, from: data)
                renderDocument(document)
            } catch {
                showErrorView(for: error)
            }
        }
    }

    private func renderDocument(_ document: Document) {
        ...
    }

    private func showErrorView(for error: Error) {
        ...
    }
}

Now, if we just quickly look at the above code, it might not seem like there’s any object capturing going on whatsoever. After all, asynchronous capturing has traditionally only happened within escaping closures, which in turn require us to always explicitly refer to self whenever we’re accessing a local property or method within such a closure (when self refers to a class instance, that is).

So we might expect that if we start displaying our DocumentViewController, but then navigate away from it before its download has completed, that it’ll be successfully deallocated once no external code (such as its parent UINavigationController) maintains a strong reference to it. But that’s actually not the case.

That’s because of the aforementioned implicit capturing that happens whenever we create a Task, or use await to wait for the result of an asynchronous call. Any object used within a Task will automatically be retained until that task has finished (or failed), including self whenever we’re referencing any of its members, like we’re doing above.

In many cases, this behavior might not actually be a problem, and will likely not lead to any actual memory leaks, since all captured objects will eventually be released once their capturing task has completed. However, let’s say that we’re expecting the documents downloaded by our DocumentViewController to potentially be quite large, and that we wouldn’t want multiple view controllers (and their download operations) to remain in memory if the user quickly navigates between different screens.

The classic way to address this sort of problem would be to perform a weak self capture, which is often accompanied by a guard let self expression within the capturing closure itself — in order to turn that weak reference into a strong one that can then be used within the closure’s code:

class DocumentViewController: UIViewController {
    ...

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

        Task { [weak self] in
    guard let self = self else { return }

            do {
                let (data, _) = try await self.urlSession.data(
                    from: self.documentURL
                )
                let decoder = JSONDecoder()
                let document = try decoder.decode(Document.self, from: data)
                self.renderDocument(document)
            } catch {
                self.showErrorView(for: error)
            }
        }
    }
    
    ...
}

Unfortunately, that’s not going to work in this case, as our local self reference will still be retained while our asynchronous URLSession call is suspended, and until all of our closure’s code has finished running (just like how a local variable within a function is retained until that scope has been exited).

So if we truly wanted to capture self weakly, then we’d have to consistently use that weak self reference throughout our closure. To make it somewhat simpler to use our urlSession and documentURL properties, we could capture those separately, as doing so won’t prevent our view controller itself from being deallocated:

class DocumentViewController: UIViewController {
    ...

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

        Task { [weak self, urlSession, documentURL] in
            do {
                let (data, _) = try await urlSession.data(from: documentURL)
                let decoder = JSONDecoder()
                let document = try decoder.decode(Document.self, from: data)
                self?.renderDocument(document)
            } catch {
                self?.showErrorView(for: error)
            }
        }
    }
    
    ...
}

The good news is that, with the above in place, our view controller will now be successfully deallocated if it ends up being dismissed before its download has completed.

However, that doesn’t mean that its task will automatically be cancelled. That might not be a problem in this particular case, but if our network call resulted in some kind of side-effect (like a database update), then that code would still run even after our view controller would be deallocated, which could result in bugs or unexpected behavior.

Cancelling tasks

One way to ensure that any ongoing download task will indeed be cancelled once our DocumentViewController goes out of memory would be to store a reference to that task, and to then call its cancel method when our view controller is being deallocated:

class DocumentViewController: UIViewController {
    private let documentURL: URL
    private let urlSession: URLSession
    private var loadingTask: Task<Void, Never>?
    
    ...

    deinit {
    loadingTask?.cancel()
}

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

        loadingTask = Task { [weak self, urlSession, documentURL] in
            ...
        }
    }
    
    ...
}

Now everything works as expected, and all of our view controller’s memory and asynchronous state will automatically be cleaned up once it has been dismissed — but our code has also become quite complicated in the process. Having to write all of that memory management code for every view controller that performs an asynchronous task would be quite tedious, and it could even make us question whether async/await actually gives us any real benefits over technologies like Combine, delegates, or closures.

Thankfully, there’s another way to implement the above pattern that doesn’t involve quite as much code and complexity. Since the convention is for long-running async methods to throw an error if they get cancelled (see this article about delaying asynchronous tasks for more info), we can simply cancel our loadingTask once our view controller is about to be dismissed — and that will make our task throw an error, exit, and release all of its captured objects (including self). That way, we no longer need to capture self weakly, or do any other kind of manual memory management work — giving us the following implementation:

class DocumentViewController: UIViewController {
    private let documentURL: URL
    private let urlSession: URLSession
    private var loadingTask: Task<Void, Never>?
    
    ...

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

        loadingTask = Task {
            do {
                let (data, _) = try await urlSession.data(from: documentURL)
                let decoder = JSONDecoder()
                let document = try decoder.decode(Document.self, from: data)
                renderDocument(document)
            } catch {
                showErrorView(for: error)
            }
        }
    }

    override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    loadingTask?.cancel()
}

    ...
}

Note that when our task is cancelled, our showErrorView method will now still be called (since an error will be thrown, and self remains in memory at that point). However, that extra method call should be completely negligible in terms of performance.

Long-running observations

The above set of memory management techniques should become even more important once we start using async/await to set up long-running observations of some kind of async sequence or stream. For example, here we’re making a UserListViewController observe a UserList class in order to reload its table view data once an array of User models was changed:

class UserList: ObservableObject {
    @Published private(set) var users: [User]
    ...
}

class UserListViewController: UIViewController {
    private let list: UserList
    private lazy var tableView = UITableView()
    
    ...

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

        Task {
            for await users in list.$users.values {
                updateTableView(withUsers: users)
            }
        }
    }

    private func updateTableView(withUsers users: [User]) {
        ...
    }
}

To learn more about Published properties, check out this article.

Note that the above implementation currently doesn’t include any of the task cancellation logic that we previously implemented within our DocumentViewController, which in this case will actually lead to a memory leak. The reason is that (unlike our previous Document-loading task) our UserList observation task will keep running indefinitely, as it’s iterating over a Publisher-based async sequence that can’t throw an error, or complete in any other way.

The good news is that we can easily fix the above memory leak using the exact same technique as we previously used to prevent our DocumentViewController from being retained in memory — that is, to cancel our observation task once our view controller is about to disappear:

class UserListViewController: UIViewController {
    private let list: UserList
    private lazy var tableView = UITableView()
    private var observationTask: Task<Void, Never>?

    ...

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

        observationTask = Task {
            for await users in list.$users.values {
                updateTableView(withUsers: users)
            }
        }
    }

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        observationTask?.cancel()
    }

    ...
}

Note that performing the above cancellation within deinit wouldn’t work in this case, since we’re dealing with an actual memory leak — meaning that deinit will never be called unless we break our observation task’s endless loop.

Conclusion

At first, it might seem like technologies like Task and async/await make asynchronous, memory-related issues a thing of the past, but unfortunately we still have to be careful around how objects are captured and retained when performing various kinds of async-marked calls. While actual memory leaks and retain cycles are perhaps not as easily encountered as when using things like Combine or closures, we still have to ensure that our objects and tasks are managed in a way that makes our code robust and easy to maintain.

I hope that you found this article useful. If you did, please share it! If you have any questions, comments, or feedback, then feel free to reach out via either Twitter or email.

Thanks for reading!