Introduction

The expression problem is a well-known programming challenge. Let’s explore it in Swift by trying to model an arithmetic operation like this one:

3 + 5 * (8–7) / 6

The object-oriented approach

Most people approach this by creating a base class or protocol that defines what an operation means.

protocol Operation {
    var compute: Double { get }
}

But what is an operation? Well, it can be just a number:

struct Number: Operation {
    var value: Double
    var compute: Double { value }
}

Or, following the composite pattern, it can be a combination of other Operation types:

struct Add: Operation {
    var lhs: Operation
    var rhs: Operation

    var compute: Double { lhs.compute + rhs.compute }
}

struct Subs: Operation {
    var lhs: Operation
    var rhs: Operation

    var compute: Double { lhs.compute - rhs.compute }
}

struct Mult: Operation {
    var lhs: Operation
    var rhs: Operation

    var compute: Double { lhs.compute * rhs.compute }
}

struct Div: Operation {
    var lhs: Operation
    var rhs: Operation

    var compute: Double { lhs.compute / rhs.compute }
}

As you can see, it’s a simple recursive pattern where the Number type is our base case.

Once we have all these types in place, we can build the arithmetic operation we defined at the beginning of the article:

let operation = Add(
    lhs: Number(value: 3),
    rhs: Mult(
        lhs: Number(value: 5),
        rhs: Div(
            lhs: Subs(
                lhs: Number(value: 8),
                rhs: Number(value: 7)
            ),
            rhs: Number(value: 6)
        )
    )
)

operation.compute // 3.833333333333333

This approach makes it extremely easy to add new arithmetic operations just by having a new type conform to the Operation protocol.

struct Pow: Operation {
    var base: Operation
    var exp: Int

    var compute: Double { pow(base.compute, Double(exp)) }
}

Pow(base: operation, exp: 3).compute // 56.328

But what about trying to add a new “interpretation” for that arithmetic operation? Right now, we only compute the final number after evaluating the operation, but we might want to “interpret” the operation differently. For instance, we might want to present the user with the string representation of the operation, that is, something like 3+5*(8-7)/6.

Well, that’s slightly trickier. If we had access to the Operation type, we might simply add a new asString property and have all the conformant types implement that new method. But Operation could be defined in an external library we don’t have access to. What options do we have then? Well, we have extensions…

extension Operation {
    var asString: String { fatalError() }
}

extension Number {
    var asString: String { "\(value)" }
}

extension Add {
    var asString: String { "(\(lhs.asString) + \(rhs.asString))" }
}

Add(lhs: Number(value: 5), rhs: Number(value: 3)).asString // ???

Of course, that doesn’t work and the last line ends up hitting the fatalError. Even if the asString method inside the Add type is called, the lhs and rhs variables are Operation types. As asString method is only defined in a protocol extension and not as a required method in the protocol definition, the dispatch of the asString method for lhs and rhs will be static, not dynamic. What that means is that the underlying runtime type for lhs and rhs won’t matter and Number‘s asString implementation won’t be ever called. Rather, the fatalError will.

Let’s try another solution.

The functional approach

Let’s try defining our operation as a recursive sum type:

indirect enum Operation {
    case add(lhs: Self, rhs: Self)
    case subs(lhs: Self, rhs: Self)
    case mult(lhs: Self, rhs: Self)
    case division(lhs: Self, rhs: Self)
    case number(value: Double)
}

extension Operation {
    var compute: Double {
        switch self {
        case let .add(lhs: lhs, rhs: rhs): lhs.compute + rhs.compute
        case let .subs(lhs: lhs, rhs: rhs): lhs.compute - rhs.compute
        case let .mult(lhs: lhs, rhs: rhs): lhs.compute * rhs.compute
        case let .division(lhs: lhs, rhs: rhs): lhs.compute / rhs.compute
        case let .number(value): value
        }
    }
}

let operation: Operation = .add(
    lhs: .number(value: 3),
    rhs: .mult(
        lhs: .number(value: 5),
        rhs: .division(
            lhs: .subs(
                lhs: .number(value: 8),
                rhs: .number(value: 7)
            ),
            rhs: .number(value: 6)
        )
    )
)

operation.compute // 3.833333333333333

With this approach, interpreting the Operation type as a String becomes trivial.

extension Operation {
    var asString: String {
        switch self {
        case let .add(lhs: lhs, rhs: rhs): "(\(lhs.asString) + \(rhs.asString))"
        case let .subs(lhs: lhs, rhs: rhs): "(\(lhs.asString) - \(rhs.asString))"
        case let .mult(lhs: lhs, rhs: rhs): "(\(lhs.asString) * \(rhs.asString))"
        case let .division(lhs: lhs, rhs: rhs): "(\(lhs.asString) / \(rhs.asString))"
        case let .number(value): "\(value)"
        }
    }
}

operation.asString // (3.0 + (5.0 * ((8.0 - 7.0) / 6.0)))

But… of course, the other type of extensibility won’t be that easy! Adding new arithmetic operations will be impossible if the enum is in a library we can’t control. We can’t simply add a new case!

Is there any hope for both kinds of extensibility? Well, turns out there is.

The Tagless Final approach

What would happen if our Operation was a protocol like in the first approach, but instead of conformant types per arithmetic operation, we had static functions returning Self? Something like this:

protocol Operation {
    static func add(lhs: Self, rhs: Self) -> Self
    static func subs(lhs: Self, rhs: Self) -> Self
    static func mult(lhs: Self, rhs: Self) -> Self
    static func division(lhs: Self, rhs: Self) -> Self
    static func number(value: Double) -> Self
}

Now, for each interpretation we need, we can simply have a type:

struct DoubleInterpreter {
    var compute: Double
}

extension DoubleInterpreter: Operation {
    static func add(lhs: Self, rhs: Self) -> Self {
        .init(compute: lhs.compute + rhs.compute)
    }

    static func subs(lhs: Self, rhs: Self) -> Self {
        .init(compute: lhs.compute - rhs.compute)
    }

    static func mult(lhs: Self, rhs: Self) -> Self {
        .init(compute: lhs.compute * rhs.compute)
    }

    static func division(lhs: Self, rhs: Self) -> Self {
        .init(compute: lhs.compute / rhs.compute)
    }

    static func number(value: Double) -> Self {
        .init(compute: value)
    }
}

Then, we create the value and compute it.

let doubleInterpreter: DoubleInterpreter = .add(
    lhs: .number(value: 3),
    rhs: .mult(
        lhs: .number(value: 5),
        rhs: .division(
            lhs: .subs(
                lhs: .number(value: 8),
                rhs: .number(value: 7)
            ),
            rhs: .number(value: 6)
        )
    )
)

doubleInterpreter.compute // 3.833333333333333

Now, creating a new operation is as easy as creating a new protocol that conforms to the previous Operation type:

protocol OperationWithPow: Operation {
    associatedtype Op: Operation
    static func pow(base: Op, exp: Int) -> Self
}

extension DoubleInterpreter: OperationWithPow {
    static func pow(base: Self, exp: Int) -> Self {
        .init(compute: Foundation.pow(base.compute, Double(exp)))
    }
}

DoubleInterpreter.pow(base: doubleInterpreter, exp: 3).compute // 56.328

Finally, let’s try to interpret the operation as a String value rather than a Double:

struct StringInterpreter {
    var asString: String
}

extension StringInterpreter: OperationWithPow {
    static func pow(base: Self, exp: Int) -> Self {
        .init(asString: "(\(base.asString) ^ \(exp))")
    }

    static func add(lhs: Self, rhs: Self) -> Self {
        .init(asString: "(\(lhs.asString) + \(rhs.asString))")
    }

    static func subs(lhs: Self, rhs: Self) -> Self {
        .init(asString: "(\(lhs.asString) - \(rhs.asString))")
    }

    static func mult(lhs: Self, rhs: Self) -> Self {
        .init(asString: "(\(lhs.asString) * \(rhs.asString))")
    }

    static func division(lhs: Self, rhs: Self) -> Self {
        .init(asString: "(\(lhs.asString) / \(rhs.asString))")
    }

    static func number(value: Double) -> Self {
        .init(asString: "\(value)")
    }
}

let stringInterpreter = StringInterpreter.pow(
    base: .add(
        lhs: .number(value: 3),
        rhs: .mult(
            lhs: .number(value: 5),
            rhs: .division(
                lhs: .subs(
                    lhs: .number(value: 8),
                    rhs: .number(value: 7)
                ),
                rhs: .number(value: 6)
            )
        )
    ),
    exp: 3
)

stringInterpreter.asString // ((3.0 + (5.0 * ((8.0 - 7.0) / 6.0))) ^ 3)

In case we want to reuse the same operation amongst different interpreters, we can leverage generic functions like this:

func operation<Op: OperationWithPow>() -> Op {
    .pow(
        base: .add(
            lhs: .number(value: 3),
            rhs: .mult(
                lhs: .number(value: 5),
                rhs: .division(
                    lhs: .subs(
                        lhs: .number(value: 8),
                        rhs: .number(value: 7)
                    ),
                    rhs: .number(value: 6)
                )
            )
        )
        ,
        exp: 3
    )
}

(operation() as DoubleInterpreter).compute // 56.32870370370369
(operation() as StringInterpreter).asString // ((3.0 + (5.0 * ((8.0 - 7.0) / 6.0))) ^ 3)

Conclusion

As you can see, the expression problem is a fascinating problem about extensibility and the Open-closed principle that neither the “object-oriented approach” nor the “functional approach” fully addresses.

Interestingly, a rather “not so common” way of using protocols with static functions returning Self “solves” the problem, not without introducing a slight amount of complexity in terms of generic functions for reusability.

If you want to know more, make sure to check out this great talk by Brandon Kase about this topic.

As always, the right approach depends on your actual needs for extensibility. Choosing the right balance between extensibility and complexity is hard. Choose wisely.

The Expression Problem in Swift was originally published in The Swift Cooperative on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

I remember the first time I read about Railway Oriented Programming. It was back in September 2015. We already had Swift 2.0 with its new error-handling model, allowing us to annotate any function as throws. That new way of handling errors had some issues though:

1. It was impossible to use with asynchronous functions and callbacks.
2. It was untyped. When I started learning Swift, I wanted to type everything strongly! I wanted the compiler to prevent as many errors as possible, have exhaustive error checking, etc. Years later, I realized that throwing untyped errors is usually the most ergonomic way to handle errors in most scenarios.
3. Coming from Objective-C, where exceptions had different semantics, and weren’t used for normal error control flow (but for exceptional fatal programming errors at runtime), it was hard to embrace this new way of thinking about errors. We no longer throw Exceptions, we throw Errors now. And we are talking about “normal” errors as we can read in the Swift blog.
4. The impact of marking a function as throws is not negligible and will force you to either handle it in every usage of that function or mark the calling function as throws. This means that refactoring code to start throwing errors might require quite a lot of changes across your code base. If you come from the Java world, this is similar to checked exceptions, but without the specific error type. And well, in the Java community, these kinds of exceptions are considered a bad practice.

The Result type was embraced by the community back then as the idiomatic way to solve the first two problems. It could be used in asynchronous contexts, it avoided impossible states (like having both an error and a success value) and we could decide to type the error if needed.

Even if we didn’t have the Result type yet (it wouldn’t be included in the standard library until 2019 with Swift 5.0), we could very easily build it ourselves. Enums with associated values were available in the first version of Swift, and they were the fundamental building block for a lot of the new type safety possibilities that Swift brought us:

enum Result<Value, Failure> where Failure: Error {
    case success(Value)
    case failure(Failure)
}

Throughout the article, we’ll develop a very simple example to see the pros and cons of different error mechanisms available in Swift. From the previous Result type, to the newer typed throws available in Swift 6.

Result type

Let’s imagine that we are developing a function that:

• Downloads some integer value from an API.
• Sends an email using that previous integer value.

Both steps can error of course.

enum APIError: Error {
    case unknown
}

enum EmailError: Error {
    case unknown
}

enum APIOrEmailError: Error {
    case api(APIError)
    case email(EmailError)
}

func downloadData(callback: (Result<Int, APIError>) -> Void) {
    fatalError("Implementation is not important")
}

func sendEmail(value: Int, callback: (Result<Void, EmailError>) -> Void) {
    fatalError("Implementation is not important")
}

func downloadDataAndSendEmail(callback: (Result<Void, APIOrEmailError>) -> Void) {
    downloadData { result in
        switch result {
        case .success(let value):
            sendEmail(value: value) { result in
                switch result {
                case .success:
                    callback(.success(()))
                case .failure(let error):
                    callback(.failure(.email(error)))
                }
            }

        case .failure(let error):
            callback(.failure(.api(error)))
        }
    }
}

As you can see, we have two main issues:

• Callbacks don’t compose nicely, so code gets ugly very easily, leading us to a hard-to-read-and-maintain pyramid of doom with lots of nested levels of indentation.
• We need to interpret explicitly the errors from the different layers and decide how we want to expose them upwards. In this case, we simply forwarded both the API and email errors as part of the associated values in the compound error. Take into account that any time we introduce new errors, all usages of the downloadDataAndSendEmail function will break. That’s the price to pay for the error type safety and that’s why library authors should prefer untyped errors in most cases.

But even if we remove the explicit types and simply have Error in the Result types, the implementation is still hard to read and doesn’t compose very well.

Let’s look for some alternatives.

Combine

The aforementioned Railway Oriented Programming was the solution to the first of our problems. It was a solution to compose functions that can fail in a nice way. In order to do so, we need to two pieces:

1. A type that represents an asynchronous computation that can fail.
2. A flatMap and mapError combinators to chain functions returning those types.

At that time, we didn’t have Combine yet (it would be introduced in 2019), but we could very easily create an asynchronous version of that result type like this:

struct AsyncResult<Value, Failure> where Failure: Error {
    var run: ((Result<Value, Failure>) -> Void) -> Void

    // Some combinators like flatMap, mapError, etc
}

For simplicity, let’s just use Combine for the example

func downloadData() -> AnyPublisher<Int, APIError> {
    fatalError("Implementation is not important")
}

func sendEmail(value: Int) -> AnyPublisher<Void, EmailError> {
    fatalError("Implementation is not important")
}

func downloadDataAndSendEmail() -> AnyPublisher<Void, APIOrEmailError> {
    downloadData()
        .mapError(APIOrEmailError.api)
        .flatMap { sendEmail(value: $0).mapError(APIOrEmailError.email) }
        .eraseToAnyPublisher()
}

Things look much better! Well… it depends 😅. Even if the code is succinct, there are several underlying Combine’s operators that we needed to use: mapError, flatMap. Even if that code might read well if you are used to Combine and reactive paradigms, writing that code is not straightforward.

What happens if we remove the typed errors? If both downloadData and sendEmail still return APIError and EmailError, the implementation is still quite complex:

func downloadDataAndSendEmail() -> AnyPublisher<Void, any Error> {
    downloadData()
        .mapError { $0 }
        .flatMap { sendEmail(value: $0).mapError { $0 } }
        .eraseToAnyPublisher()
}

Fortunately, if we are lucky enough to control downloadData and sendEmail functions to change their signatures to use any Error , things get much better:

func downloadDataAndSendEmail() -> AnyPublisher<Void, any Error> {
    downloadData()
        .flatMap(sendEmail)
        .eraseToAnyPublisher()
}

No need for ugly mapError functions and things compose much nicer. Just a single flatMap function.

We can even simplify things further by removing AnyPublisher and using the Publisher existential type directly.

func downloadDataAndSendEmail() -> any Publisher<Void, any Error> {
    downloadData().flatMap(sendEmail)
}

As you can see. Removing the specific error type from all the steps in the chain had huge implications for the composability and readability of the code.

Let’s compare this implementation with a final one. Arguably, the most idiomatic way of handling errors in Swift, via throwing functions.

Async throwing functions

func downloadData() async throws(APIError) -> Int {
    fatalError("Implementation is not important")
}

func sendEmail(value: Int) async throws(EmailError) {
    fatalError("Implementation is not important")
}

func downloadDataAndSendEmail() async throws(APIOrEmailError) {
    let value: Int
    do {
        value = try await downloadData()
    } catch {
        throw .api(error)
    }

    do {
        try await sendEmail(value: value)
    } catch {
        throw .email(error)
    }
}

Even if there are quite a few mappings of errors via the do/catch clauses, I read that much better than this other version:

downloadData()
    .mapError(APIOrEmailError.api)
    .flatMap { sendEmail(value: $0).mapError(APIOrEmailError.email) }
    .eraseToAnyPublisher()

But readability is quite subjective and depends a lot on people’s experience and preferences…

Let’s see what happens now if we decide to remove the typed error just from the downloadDataAndSendEmail function.

func downloadDataAndSendEmail() async throws {
    let value = try await downloadData()
    try await sendEmail(value: value)
}

You can see here the great ergonomics that Typed throws provides in Swift. Even if downloadData and sendEmail still throw typed errors, having several functions throwing different typed errors means that the enclosing function throws any Error, which is great and makes a lot of sense. No need to handle ugly error mapping!

This solves one of the main problems of checked exceptions in Java. Each time you use a function that throws a checked exception, you are forced to either change your signature to account for that new exception or just catch it and rethrow it in a way that you don’t change your function’s signature. Swift handles this scenario much better.

func sendEmail(value: Int) async throws(EmailError) {
    fatalError()
}

func downloadDataAndSendEmail() async throws {
    // It doesn't matter if sendEmail throws a typed error.
    // As `downloadDataAndSendEmail` throws any Error, this typed
    // error is automatically converted to `any Error`
    try await sendEmail(value: 3)
}

Better error semantics

Even if you might think that you won’t use typed throws in your code base much, which might be true for app development to be honest, typed throws allows Swift to have much better error semantics.

Let’s imagine we want to model a repository generic over a Model type, with an async sequence that returns those types over time. In Swift 5.10, with untyped throws, this is the best we can do.

protocol Repository<Model> {
    associatedtype Model: Equatable
    associatedtype ModelSequence: AsyncSequence where ModelSequence.Element == Model

    var modelSequence: ModelSequence { get }
}

extension Repository {
    func onModel(action: @escaping (Model) -> Void) {
        Task {
            for try await model in modelSequence {
                action(model)
            }
        }
    }
}

There’s not a big problem with that code, but there’s no way to convey that the async sequence never fails. That means that iterating over that sequence in the onModel function will always force us to use for try await, even for cases where that sequence would never fail.

And this is because of how AsyncIteratorProtocol is defined:

protocol AsyncIteratorProtocol {
    associatedtype Element

    mutating func next() async throws -> Self.Element?
}

As you can see, the next function is async throws and the only way for Swift to know that an async iterator won’t throw is to know the specific implementation of AsyncIteratorProtocol with a non-throwing next function.

In Swift 6, things get much better:

protocol Repository<Model> {
    associatedtype Model: Equatable
    associatedtype ModelSequence: AsyncSequence<Model, Never>

    var modelSequence: ModelSequence { get }
}

extension Repository {
    func onModel(action: @escaping (Model) -> Void) {
        Task {
            for await model in modelSequence {
                action(model)
            }
        }
    }
}

We can now leverage the primary associated types in AsyncSequence and use the Never type to ensure that the async sequence will never fail. That means that the onModel function can iterate over the sequence with just for await instead of for try await. And that’s because AsyncIteratorProtocol is defined as follows:

protocol AsyncIteratorProtocol<Element, Failure> {
    associatedtype Element

    mutating func next(isolation actor: isolated (any Actor)?) async throws(Self.Failure) -> Self.Element?
}

As you can see, we can use the Failure primary associated type in the function signature via throws Failure. And throws Never will be the same as not having the throws word at all.

This might seem like a negligible small thing that won’t have any impact in your code. That might be true, but Swift getting smarter about how to handle errors won’t hurt 😅.

Conclusion

In general, I think typed throws is a very welcome addition to the Swift language. It doesn’t break existence code bases and allows developers to choose the best way to model errors (either typed or untyped) while keeping great ergonomics and avoiding the problems we had in other languages like Java with checked exceptions.

Library authors would still need to be wary about using typed errors because of the evolution problems, but for other type of code, it gives us some great flexibility and would allow the compiler to force several error code paths for specific, important domain errors where we want that extra type safety.

Looking forward to Swift 6.

A Tale of Two Error Types in Swift was originally published in The Swift Cooperative on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

A year ago, I wrote a long article comparing different flavors of unidirectional architectures in Swift. Here, I will present what I consider to be the main problem of them all. Well, it’s not a problem of unidirectional architectures per se. Rather, it’s a problem of modeling the actions or events as values. I usually call it the “ping-pong problem”. And it’s all about the “jumps” we have to do between different places of the code to have a cohesive understanding of the whole flow. Let’s see a simple example first.

func handle(event: Event) {
    switch event {
    case .onAppear:
        state = .loading
        return .task {
            let numbers = try await apiClient.numbers()
            await send(.numbersDownloaded(numbers))
        }
    
    case .numbersDownloaded(let values):
        state = .loaded(values)
        return .none
    }
}

Even if that code is pretty easy to read, there’s an even simpler version of that:

func onAppear() {
    Task {
        state = .loading
        let numbers = try await apiClient.numbers()
        state = .loaded(numbers)
    }
}

It’s not only less code. It’s more cohesive and understandable code.

When modeling events as values, we lose the ability to read all the code from top to bottom as a cohesive piece of behavior. We now have to go event by event to form the whole understanding of a particular flow: some input event triggers some feedback event, which might trigger another feedback event, etc… There can be lots of different back and forths between those events, which makes it harder to understand the code.

But as always, applying any architecture to any trivial example will look like overengineering.

Imagine using something like CLEAN architecture in the previous code.

func onAppear() {
    Task {
        state = .loading
        let numbers = try await usecase.numbers()
        state = .loaded(values)
    }
}

class UseCase {
    let repository: RepositoryContract

    func numbers() async throws -> [Int] {
        repository.numbers()
    }
}

protocol RepositoryContract {
    func numbers() async throws -> [Int]
}

class Repository: RepositoryContract {
    let apiClient: APIClient

    func numbers() async throws -> [Int] {
        apiClient.numbers()
    }
}

In both cases, we’ve introduced unneeded indirection. We have to jump to lots of different places to understand the code.

Even if we need layers and abstractions to manage complexity, allow flexibility, and facilitate testing, we shouldn’t forget that we are also losing an important trait in software: “locality of behavior” (also called local reasoning). As always, everything is a trade-off.

Modeling events as values has great advantages, like having full traceability of the state changes and what events produced them. But allowing that comes with risks in readability. And remember, code should always be optimized for readability.

Let’s see now a more complex example, inspired by the Mobius Workflow from Spotify.

The ping-pong problem in practice

Taking the architecture I proposed in my previous blog post about unidirectional architectures, let’s implement a simple login screen with the following requirements:

• The user can enter their email and password to log in.
• In case of no internet, the user won’t be allowed to log in.
• The email has both a local validation first and a remote validation after that.
• The password has no validation.
• Before attempting to log in, the user will be prompted for confirmation.

We’ll have three different implementations, but first, let’s have the two common pieces: the state and the effects.

struct State: Equatable {
    var online: Bool = true
    var email: Email = .init()
    var password: String = ""
    var loggingIn: Bool = false

    var canLogin: Bool {
        online && email.valid && password.count > 8
    }

    struct Email: Equatable {
        var rawValue: String = ""
        var valid: Bool = false
        var currentValidation: Validation? = nil

        enum Validation {
            case local
            case remote
        }
    }
}

enum Effects {
    static func login() async throws -> String {
        "dummy token"
    }

    static func localEmailValidation(_ email: String) -> Bool {
        email.contains("@")
    }

    static func remoteEmailValidation(_ email: String) async -> Bool {
        return Bool.random()
    }

    static func showConfirmation(text: String, yes: () async -> Void, no: () async -> Void) async {}
    static func onlineStream() -> AsyncStream<Bool> {}
}

Case 1: Complete unidirectional architecture

class ViewReducer: Reducer {
    enum Input {
        case onAppear
        case emailInputChanged(String)
        case passwordInputChanged(String)
        case loginButtonClicked
    }

    enum Feedback {
        case internetStateChanged(online: Bool)
        case loginSuccessful(token: String)
        case loginFailed
        case emailLocalValidation(valid: Bool)
        case emailRemoteValidation(valid: Bool)
        case loginAlertConfirmation(confirm: Bool)
    }

    enum Output {
        case showErrorToast
        case loginFinished(_ token: String)
    }

    func reduce(message: Message<Input, Feedback>, into state: inout State) -> Effect<Feedback, Output> {
        switch message {
        // MARK: - Input events
        case .input(.onAppear):
            return .run { send in
                for await online in Effects.onlineStream() {
                    await send(.internetStateChanged(online: online))  
                }
            }

        case .input(.emailInputChanged(let value)):
            state.email.rawValue = value
            state.email.valid = false
            state.email.currentValidation = .local

            let email = state.email.rawValue
            return .run { send in
                let valid = Effects.localEmailValidation(email)
                await send(.emailLocalValidation(valid: valid))
            }

        case .input(.passwordInputChanged(let value)):
            state.password = value
            return .none

        case .input(.loginButtonClicked):
            guard state.canLogin else {
                fatalError("Shouldn't be here")
            }

            return .run { send in
                await Effects.showConfirmation(text: "Are you sure?") {
                    await send(.loginAlertConfirmation(confirm: true))
                } no: {
                    await send(.loginAlertConfirmation(confirm: false))
                }
            }

        // MARK: - Feedback events
        case .feedback(.emailLocalValidation(valid: let valid)):
            guard valid else {
                state.email.currentValidation = nil
                return .none
            }
            state.email.currentValidation = .remote
            let email = state.email.rawValue
            return .run { send in
                let valid = await Effects.remoteEmailValidation(email)
                await send(.emailRemoteValidation(valid: valid))
            }

        case .feedback(.emailRemoteValidation(valid: let valid)):
            state.email.valid = valid
            state.email.currentValidation = nil
            return .none

        case .feedback(.loginAlertConfirmation(true)):
            state.loggingIn = true
            return .run { send in
                do {
                    let token = try await Effects.login()
                    await send(.loginSuccessful(token: token))
                } catch {
                    await send(.loginFailed)
                }
            }

        case .feedback(.loginAlertConfirmation(false)):
            return .none

        case .feedback(.loginSuccessful(token: let token)):
            state.loggingIn = false
            return .output(.loginFinished(token))

        case .feedback(.loginFailed):
            state.loggingIn = false
            return .output(.showErrorToast)

        case .feedback(.internetStateChanged(let online)):
            state.online = online
            return .none
        }
    }
}

As you can see, to figure out all the login flow, we need to understand how all these different events are handled:

• emailInputChanged input -> emailLocalValidation feedback -> emailRemoteValidation feedback.
• loginButtonClicked input -> loginAlertConfirmation feedback -> loginSuccessful feedback.

There are quite a few events and back and forth between them to understand what happens when the user enters their email and when the login button is tapped. Even if we put together the related events in the switch statement to minimize the pain of jumping between them, it’s still very cumbersome and requires painful jumps and indirections.

The feedback events are the ones producing all this back and forth. 🤔 What would happen if we remove them? Let’s see.

Case 2: Removing feedback events

Let’s now write a view model from scratch. This time, only modeling the input and output events as values.

class ViewModel {
    enum Input {
        case onAppear
        case emailInputChanged(String)
        case passwordInputChanged(String)
        case loginButtonClicked
    }

    enum Output {
        case showErrorToast
        case loginFinished(_ token: String)
    }

    private(set) var state: State
    let stream: AsyncStream<Output>
    private let continuation: AsyncStream<Output>.Continuation

    init() {
        let (stream, continuation) = AsyncStream.makeStream(of: Output.self)
        self.stream = stream
        self.continuation = continuation
        self.state = .init()
    }

    func send(_ input: Input) {
        switch input {
        case .onAppear:
            Task {
                for await online in Effects.onlineStream() {
                    self.state.online = online
                }
            }

        case .emailInputChanged(let value):
            state.email.rawValue = value
            state.email.valid = false
            state.email.currentValidation = .local
            let valid = Effects.localEmailValidation(value)

            guard valid else {
                state.email.currentValidation = nil
                return
            }

            state.email.currentValidation = .remote
            Task {
                let valid = await Effects.remoteEmailValidation(value)
                state.email.valid = valid
                state.email.currentValidation = nil
            }

        case .passwordInputChanged(let value):
            state.password = value

        case .loginButtonClicked:
            guard state.canLogin else {
                fatalError("Shouldn't be here")
            }

            Task {
                await Effects.showConfirmation(text: "Are you sure?") {
                    state.loggingIn = true
                    defer {
                        state.loggingIn = false
                    }
                    do {
                        let token = try await Effects.login()
                        continuation.yield(.loginFinished(token))
                    } catch {
                        continuation.yield(.showErrorToast)
                    }
                } no: {
                    // Nothing
                }
            }
        }
    }
}

Removing the feedback events has simplified the code quite a bit. We can now read top to bottom again and the related parts are together, having a much more cohesive code than before.

Case 3: Removing events as values

But, to be honest… unless we need to log or have traceability with those input events, it’s much simpler to avoid that massive switch and rely on plain, simple functions to replace them.

class ViewModel {
    enum Output {
        case showErrorToast
        case loginFinished(_ token: String)
    }

    private(set) var state: State
    let stream: AsyncStream<Output>
    private let continuation: AsyncStream<Output>.Continuation

    init() {
        let (stream, continuation) = AsyncStream.makeStream(of: Output.self)
        self.stream = stream
        self.continuation = continuation
        self.state = .init()
    }

    func onAppear() {
        Task {
            for await online in Effects.onlineStream() {
                self.state.online = online
            }
        }
    }

    func emailInputChanged(value: String) {
        state.email.rawValue = value
        state.email.valid = false
        state.email.currentValidation = .local

        let valid = Effects.localEmailValidation(value)

        guard valid else {
            state.email.currentValidation = nil
            return
        }

        state.email.currentValidation = .remote
        Task {
            let valid = await Effects.remoteEmailValidation(value)
            state.email.valid = valid
            state.email.currentValidation = nil
        }
    }

    func passwordInputChanged(value: String) {
        state.password = value
    }

    func loginButtonClicked() {
        guard state.canLogin else {
            fatalError("Shouldn't be here")
        }

        Task {
            await Effects.showConfirmation(text: "Are you sure?") {
                state.loggingIn = true
                defer {
                    state.loggingIn = false
                }
                do {
                    let token = try await Effects.login()
                    continuation.yield(.loginFinished(token))
                } catch {
                    continuation.yield(.showErrorToast)
                }
            } no: {
                // Nothing
            }
        }
    }
}

In my opinion, this last code reads much better than any other.

Conclusion

As you can see, feedback events and the back-and-forth between them can impact the readability of your code, making it quite hard to understand and build a cohesive understanding of the whole functionality.

Take into account that the example is thoroughly presented to maximize these problems. We could have other examples where having a more constrained way of controlling our state, by only allowing it to mutate via events, results in a much more understandable code.

This article only wanted to highlight the price we are paying when adopting these kinds of architectures. Not only because of the ping-pong problem but also because of the impedance mismatch when working with SwiftUI, where bindings and other property wrappers don’t fit naturally and require extra boilerplate.

Not only that, the impedance mismatch happens as well in terms of Xcode and the static analysis and navigation ergonomics it has. We lose the ability to jump directly to the definition of the function (we now jump to the case in the enum, having to search that case in the switch statement to see the implementation of that particular event), or use handy features like “call hierarchy” in Xcode.

In my opinion, a safer approach for most people would be to rely on a humble view model (or some other kind of thin controller/coordinator layer) and move as much logic as possible to a properly modeled domain. Interestingly enough, this was what I proposed back in 2017, in my first blog post about architecture 😅. But that “loose architecture” could very easily get out of hand if not careful, whereas unidirectional architectures usually have much stronger constraints and are more opinionated about where and how state and effects are handled. As always, everything has its pros and cons. Choose wisely.

The Dark Side of Unidirectional Architectures in Swift was originally published in The Swift Cooperative on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Aspect-oriented programming (AOP from now on) is all about adding cross-cutting concerns to our code base in a scalable manner.

I still remember the first time I came across the term “Aspect Oriented Programming”. It was quite a long time ago, Swift didn’t exist yet, and we were happily writing Objective-C code. ARAnalytics was one of the first libraries to adopt the AOP paradigm to simplify adding analytics across our code base.

Taking a closer look at the code, we can see that implementing AOP in Objective-C is just implementing method swizzling, as Peter Steinberger stated in his Aspects library.

Think of Aspects as method swizzling on steroids.

Unlike Objective-C, Swift is a really strict, statically-typed language with not many capabilities to intercept messages and change behavior at runtime. In practice, what this means is that we have to set some foundations of good design in our code so the impact of applying cross-cutting concerns to our codebase is minimal. We are going to need two main ingredients:

• Some sort of dependency injection capabilities so we can apply late-binding and change the underlying implementation at will.
• The decorator pattern, which is the interception design pattern that allows us to change the behavior that we want at runtime.

Let’s start!

AOP in Swift: towards a good design

A very common approach to model our application is to have a single “store/repository/service/aggregate” that bundles all the capabilities around a specific domain model in our application. If our application is about managing todos, we’ll have some sort of “TodoService”. If our app is about managing TV Shows, we’ll have a “ShowService”. You get the idea. While that approach is a perfectly valid one for lots of medium-sized apps, it can be problematic for other, more complex applications. As with most things in software, everything depends.

Imagine a ShowService that looks like this:

protocol ShowService {
    func allShows() async -> [Show]
    func allEpisodes(for show: Show) async -> [Episode]
    func markEpisodeAsWatched(episode: Episode) async
    func markShowAsWatched(_ show: Show, until episode: Episode?) async
}

As we said, even if most things in software are subjective and open to discussion depending on the specific context, it’s nice to have some “principles” that guide us. And those principles are usually the SOLID ones.

ISP violation

As most big interfaces, it's very likely that ShowService will break the Interface Segregation Principle, by forcing clients to implement methods that they don’t need. It’s very common to see this when implementing mocks for instance, with methods like XCTFail to verify that they aren’t called.

struct ShowServiceMock: ShowService {
    var shows: [Show]

    func allShows() -> [Show] {
        shows
    }
    
    func allEpisodes(for show: Show) -> [Episode] {
        XCTFail("Shouldn't be called")
        return []
    }

    func markEpisodeAsWatched(episode: Episode) {
        XCTFail("Shouldn't be called")
    }

    func markShowAsWatched(_ show: Show, until episode: Episode?) {
        XCTFail("Shouldn't be called")
    }
}

SRP violation

When violating ISP, it’s quite common to violate SRP as well. SRP is all about cohesion and having to change for just one reason. As the number of methods grow in our ShowService interface, it’ll be harder and harder to keep that cohesion and SRP.

OCP violation

Any new feature related to TV Shows will require adding a new method to ShowService, forcing every implementation of the service to accommodate that change and fix the compilation error.

Big interfaces tend to be bottlenecks

At the end of the day, having big interfaces like this will lead to bottlenecks when adding new behavior related to that domain model. Any new change will lead to compilation errors and recompilations all across our app. One of the mantras of good software design is to depend on modules that are more stable than you (they change less often). In our dependency graph, the leaf modules should be the most stable ones, as they will force recompilation of the whole graph whenever they change. If we take a closer look at ShowService, we are making the whole app depend on a highly unstable module that changes very often. So yes, a recipe for disaster 😅. FWIW, this kind of bottleneck it’s also very common in backend and microservices architecture, and it’s called “The Entity Service Antipattern”.

First approach: CQRS

A first approach would be to separate our big interface into two, distinct interfaces: one for reading, and one for writing. This is called Command Query Responsibility Segregation.

// Reads
protocol ShowQueryService {
    func allShows() async -> [Show]
    func allEpisodes(for show: Show) async -> [Episode]
}

// Writes
protocol ShowCommandService {
    func markEpisodeAsWatched(episode: Episode) async
    func markShowAsWatched(_ show: Show, until episode: Episode?) async
}

This separation usually makes sense because the needs we are going to have for reading are quite different from the ones we are going to have for writing. For instance, some security policies will only apply when changing state (writing) and not when just reading.

But as you can imagine, this is not a big improvement. We’ve scoped better the impact of change, but we still have two “big interfaces” that will change often. We can do better.

Second approach: small services

An obvious approach would be to “go extreme” and have all the different capabilities as different protocols.

protocol AllShowsService {
    func allShows() async -> [Show]
}

protocol AllEpisodesService {
    func allEpisodes(for show: Show) async -> [Episode]
}

protocol MarkEpisodeAsWatchedService {
    func markEpisodeAsWatched(episode: Episode) async
}

protocol MarkShowAsWatchedService {
    func markShowAsWatched(_ show: Show, until episode: Episode?) async
}

If you are used to working with clean architecture and use cases, these are exactly that.

It has some pros and cons. Having a protocol per method could lead to an explosion of interfaces. But it also has the main advantage of complying with some of the SOLID principles we talked about previously. We now comply with ISP (and most likely SRP as well). Also, when adding a new capability, we only have to create a new tuple (interface, implementation), without breaking a lot of the code we have and minimizing the impact of recompilations. So it’s not all bad. Remember, it all depends. Software is all about trade-offs.

But thinking about “Aspects”, we’ll have to implement one implementation per protocol for each aspect we need. For instance, if we want to implement a “Logging Aspect”, we’ll need a AllShowsLoggingService and another MarkShowAsWatchedLoggingService, etc… So, it doesn’t seem like an approach that scales nicely to implement cross-cutting concerns in our app.

Let’s go with the third, and final approach.

Third approach: a unified Service interface

If we want to implement AOP in a scalable manner, we need to have a single interface/seam for all our services that we want to apply “aspects” to.

protocol Service<Input, Output> {
    associatedtype Input
    associatedtype Output

    func callAsFunction(input: Input) async throws -> Output
}

Just for ergonomics reasons, let’s also have this.

extension Service where Input == Void{
    func callAsFunction() async throws -> Output {
        try await callAsFunction(input: ())
    }
}

Having a single interface, we can have something like this.

class AllShowsService: Service {
    func callAsFunction(input: Void) async throws -> [Show] {
        // Implementation...
    }
}

class MarkShowAsWatchedService: Service {
    func callAsFunction(input: (show: Show, episode: Episode?)) async throws {
        // Implementation...
    }
}

typealias AllShowsServiceType = Service<Void, [Show]>
typealias MarkShowAsWatchedServiceType = Service<(show: Show, episode: Episode?), Void>

class ViewModel<AllShowsService: AllShowsServiceType, MarkShowAsWatchedService: MarkShowAsWatchedServiceType> {
    private let allShowsService: AllShowsService
    private let markShowAsWatchedService: MarkShowAsWatchedService

    init(allShowsService: AllShowsService, markShowAsWatchedService: MarkShowAsWatchedService) {
        self.allShowsService = allShowsService
        self.markShowAsWatchedService = markShowAsWatchedService
    }

    func markAllShowsAsWatchedButtonTapped() async {
        do {
            let allShows = try await allShowsService()
            await withThrowingTaskGroup(of: Void.self) { group in
                for show in allShows {
                    group.addTask {
                        try await self.markShowAsWatchedService(input: (show, nil))
                    }
                }
            }
        } catch {
            print("Some error happened", error)
        }
    }
}

Now, our ViewModel can be created as long as we inject two inputs:

• Service<Void, [Show]>
• Service<(show: Show, episode: Episode?), Void>

As Service is a single interface, we can have just an implementation of that interface per aspect to apply it to any service across our app.

Let’s implement some aspects then! As you will see, all aspects will be very similar, following the decorator pattern

Logging aspect

A very normal and useful aspect is simply to add some logging capabilities to our services. It can be implemented as simply as follows:

class LoggingService<Decoratee: Service>: Service {
    typealias Input = Decoratee.Input
    typealias Output = Decoratee.Output

    let decoratee: Decoratee
    
    init(decoratee: Decoratee) {
        self.decoratee = decoratee
    }

    func callAsFunction(input: Input) async throws -> Output {
        let output = try await decoratee(input: input)
        dump(output)
        return output
    }
}

Premium user aspect

Another, very useful cross-cutting concern in the application could be to only allow to perform some actions in case the user is premium. By injecting a simple () async -> Bool function to abstract the way we check whether the user is premium or not, we can have our PremiumService decorator like this:

class PremiumService<Decoratee: Service>: Service {
    struct Error: Swift.Error {}

    typealias Input = Decoratee.Input
    typealias Output = Decoratee.Output

    let decoratee: Decoratee
    let isPremiumUser: () async -> Bool

    init(decoratee: Decoratee, isPremiumUser: @escaping () async -> Bool) {
        self.decoratee = decoratee
        self.isPremiumUser = isPremiumUser
    }

    func callAsFunction(input: Input) async throws -> Output {
        guard await isPremiumUser() else {
            throw Error()
        }
        return try await decoratee(input: input)
    }
}

Caching aspect

Another common aspect is caching or memoization. By simply constraining the Service Input to be Hashable and the Output to be Codable, we can implement it for all our services.

private(set) var cache: [AnyHashable: Data] = [:]

class CachingService<Decoratee: Service>: Service where Decoratee.Output: Codable, Decoratee.Input: Hashable {
    typealias Input = Decoratee.Input
    typealias Output = Decoratee.Output

    let decoratee: Decoratee

    init(decoratee: Decoratee) {
        self.decoratee = decoratee
    }

    func callAsFunction(input: Input) async throws -> Output {
        if let cachedData = cache[input] {
            return try JSONDecoder().decode(Output.self, from: cachedData)
        }

        let output = try await decoratee(input: input)
        cache[input] = try JSONEncoder().encode(output)
        return output
    }
}

Delay Aspect

Network Link Conditioner is a very useful tool to simulate different types of network conditions and force our internet connection to be very bad. We could leverage aspects to do exactly that.

class DelayService<Decoratee: Service>: Service {
    typealias Input = Decoratee.Input
    typealias Output = Decoratee.Output

    let decoratee: Decoratee
    let duration: UInt64

    init(decoratee: Decoratee, nanoseconds duration: UInt64) {
        self.decoratee = decoratee
        self.duration = duration
    }

    func callAsFunction(input: Input) async throws -> Output {
        try await Task.sleep(nanoseconds: duration)
        return try await decoratee(input: input)
    }
}

Or we could have another aspect to always force an error, for instance.

Aspects are composable

Once we have all our aspects in place, we can simply modify our view model to inject the type of service we want, decorated by any number of aspects.

let viewModel = ViewModel(
    allShowsService: DelayService(decoratee: LoggingService(decoratee: AllShowsService()), nanoseconds: 5 * NSEC_PER_SEC),
    markShowAsWatchedService: LoggingService(decoratee: MarkShowAsWatchedService())
)

As you can see, we have chained different aspects together, as they are composable.

But the important thing is that adding decorators is something that we can do from the main module of the app, where we presumably build the whole object graph, via some sort of composition root pattern. That way, we can change the behavior of our services by adding new cross-cutting concerns without touching and recompiling any of those modules.

Ergonomics

While chaining decorators can be a little bit cumbersome, we can leverage extensions to improve ergonomics and have a more idiomatic way of composing them.

extension Service {
    var withLogging: LoggingService<Self> {
        LoggingService(decoratee: self)
    }

    func withDelay(nanoseconds duration: UInt64) -> DelayService<Self> {
        DelayService(decoratee: self, nanoseconds: duration)
    }
}

// Instead of this
DelayService(decoratee: LoggingService(decoratee: AllShowsService()), nanoseconds: 5 * NSEC_PER_SEC),

// We can now do this
AllShowsService()
    .withLogging
    .withDelay(nanoseconds: 5 * NSEC_PER_SEC)

Automating decorators

Sourcery is a great meta-programming tool to automate a lot of boilerplate code. As you can imagine, decorators are a great candidate to apply this tool, so we have some sort of “template” for each aspect and let Sourcery generate the different implementations. This is especially useful when we want to apply the very same aspect to lots of different interfaces. Take a look here.

Conclusion

While it’s true that I miss Objective-C dynamism for these kinds of tasks, I see the lack of runtime support to allow easy AOP in Swift as an opportunity to apply good design principles to unlock it.

Enabling AOP doesn’t necessarily make your code better, the same way that having testable code doesn’t mean it’s good code. It’s more the other way around. Not being able to test our code is a problem. Being able to test it doesn’t mean anything. We can see AOP in a similar way.

We did an interesting exercise to unlock AOP capabilities in our code. But let’s not forget the complexity we’ve added. Finding the balance between added complexity and loose coupling to adapt better to the future is one of the most difficult things we have to do as developers. This post is simply a tool. As always, use the right tool for the job.

Aspect-Oriented Programming in Swift was originally published in The Swift Cooperative on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Polymorphism is one of the most powerful tools we have at our disposal. Coming from Objective-C, Swift exposed us to parametric polymorphism via generics, but this article is all about the other type of polymorphism, arguably the most common one: subtype polymorphism. Let’s see how it works with view models and more generally, SwiftUI observable objects.

iOS 17 and the new Observation framework

I wrote about the new Observation framework here. It’s one of the best additions we’ve recently had in SwiftUI. If you are lucky enough to target the latest iOS 17 in your apps, things are quite straightforward.

First, let’s introduce the example we want to build: a counter screen that increments or decrements a value differently: synchronously or asynchronously. First, let’s define the view model abstraction.

@MainActor
protocol CounterViewModelType: Observable {
    var count: Int { get }
    var isLoading: Bool { get }

    func increment()
    func decrement()
}

Simple enough. Just a number that will be shown on screen, a flag indicating if it’s loading the number and two actions to increment and decrement.

Underneath you can see the app working with the synchronous implementation of the CounterViewModelType.

And here’s the asynchronous one.

The simplest app ever! But as always, foundational concepts are better explained with simple, naive examples to avoid unnecessary noise around the important concepts.

Let’s start with the synchronous implementation:

@Observable
class SyncCounterViewModel: CounterViewModelType {
    private(set) var count = 0

    func increment() {
        count += 1
    }

    func decrement() {
        count -= 1
    }

    var isLoading: Bool { false }
}

And now, the asynchronous one:

@Observable
class AsyncCounterViewModel: CounterViewModelType {
    private(set) var count = 0
    private(set) var isLoading = false

    func increment() {
        afterOneSecond { [weak self] in self?.count += 1 }
    }

    func decrement() {
        afterOneSecond { [weak self] in self?.count -= 1 }
    }

    private func afterOneSecond(_ callback: @escaping () -> Void) {
        Task {
            isLoading = true
            try! await Task.sleep(nanoseconds: 1 * NSEC_PER_SEC)
            isLoading = false
            callback()
        }
    }
}

And finally, the view layer.

@MainActor
struct CounterView: View {
    let viewModel: any CounterViewModelType

    var body: some SwiftUI.View {
        VStack {
            Button("Increment") { viewModel.increment() }
                .disabled(viewModel.isLoading)

            Text(viewModel.isLoading ? "Loading…" : "\(viewModel.count)")

            Button("Decrement") { viewModel.decrement() }
                .disabled(viewModel.isLoading)
        }
    }
}

CounterView(viewModel: {
    if Int.random(in: 0..<100) % 2 == 0 {
        SyncCounterViewModel()
    } else {
        AsyncCounterViewModel()
    }
}())

As you can see, passing a different implementation of the view model at runtime works as expected when working with the new Observation framework. Unfortunately, if you aren’t as lucky as to use iOS 17 already (like most of us I guess), things get much more interesting…

Pre-iOS 17 and the old ObservableObject

Let’s refactor our previous code to work with ObservableObject. The first step is to modify our view model abstraction to conform to it.

@MainActor
protocol CounterViewModelType: ObservableObject {
    var count: Int { get }
    var isLoading: Bool { get }

    func increment()
    func decrement()
}

We also need to modify both sync and async implementations to publish their properties via @Published.

class SyncCounterViewModel: CounterViewModelType {
    @Published private(set) var count = 0
    …
}

class AsyncCounterViewModel: CounterViewModelType {
    @Published private(set) var count = 0
    @Published private(set) var isLoading = false
    …
}

And finally, we have to add the @ObservedObject property wrapper on the view layer.

struct CounterView: View {
    @ObservedObject var viewModel: any CounterViewModelType
    …
}

And… we get our first error.

Type ‘any CounterViewModelType’ cannot conform to ‘ObservableObject’

This is interesting. CounterViewModelType is an ObservableObject , so it’d be sensible to assume that any CounterViewModelType would also conform to ObservableObject . Unfortunately, that’s not how Swift works when we use protocols as existential types (unlike using protocols as generic constraints). As meta as this sounds, protocols do not conform to themselves in Swift. Take a look at this.

// Using `Codable` as type -> compiler error
struct Container: Codable {
    let data: Codable
}

// Using `Codable` as generic constraint -> it works
struct Container<Data: Codable>: Codable {
    let data: Data
}

So, let’s do that, let’s change our view to use our CounterViewModelType as a generic constraint.

@MainActor
struct CounterView<ViewModel: CounterViewModelType>: View {
    @ObservedObject var viewModel: ViewModel
}

But as expected, this no longer compiles

CounterView(viewModel: {  () -> any CounterViewModelType in
    if Int.random(in: 0..<100) % 2 == 0 {
        SyncCounterViewModel()
    } else {
        AsyncCounterViewModel()
    }
}())

Type ‘any CounterViewModelType’ cannot conform to ‘CounterViewModelType’

This was expected. As CounterView is now generic over a specific CounterViewModelType, the compiler needs to disambiguate the concrete type when creating the instance. The previous code would make ViewModel == any CounterViewModelType , and, if you remember… protocols do not conform to themselves! 😅

So, we have to change things so the view model is not given to us. Rather, we create the specific view model explicitly, so the compiler has a specific type, conforming to the CounterViewModelType.

if Int.random(in: 0..<100) % 2 == 0 {
    CounterView(viewModel: SyncCounterViewModel()) // CounterView<SyncCounterViewModel>
} else {
    CounterView(viewModel: AsyncCounterViewModel()) // CounterView<AsyncCounterViewModel>
}

This works. But we can’t always afford the privilege of creating the view model ourselves. Sometimes, for whatever reason, the view model is just given to us. We want a more dynamic approach to provide this view model dependency to our view. And in those cases… Well, we need a different approach.

Leaving ObservableObject behind

It seems that ObservableObject and polymorphism don’t get along very well… Let’s try something different. Let’s forget about ObservableObject and let’s declare our view model like a container that emits states over time.

@MainActor
protocol ViewModelType<State> {
    associatedtype State
    
    var statePublisher: Published<State>.Publisher { get }
}

Now, let’s define our new state and protocols for the counter screen:

struct CounterState {
    var count: Int
    var isLoading: Bool
}

@MainActor
protocol CounterViewModelType: ViewModelType<CounterState> {
    func increment()
    func decrement()
}

Having that in place, our two view model implementations would be:

class SyncCounterViewModel: CounterViewModelType {
    var statePublisher: Published<CounterState>.Publisher { $state }
    @Published private var state = CounterState(count: 0, isLoading: false)

    func increment() {
        state.count += 1
    }

    func decrement() {
        state.count -= 1
    }
}

class AsyncCounterViewModel: CounterViewModelType {
    var statePublisher: Published<CounterState>.Publisher { $state }
    @Published private var state = CounterState(count: 0, isLoading: false)

    func increment() {
        afterOneSecond { [weak self] in self?.state.count += 1 }
    }

    func decrement() {
        afterOneSecond { [weak self] in self?.state.count -= 1 }
    }

    private func afterOneSecond(_ callback: @escaping () -> Void) {
        Task {
            state.isLoading = true
            try! await Task.sleep(nanoseconds: 1 * NSEC_PER_SEC)
            state.isLoading = false
            callback()
        }
    }
}

As you can see, we have a little bit of extra code, by having to define the statePublisher computed property, which forwards the projected value of our @Published property.

The view layer would look like this:

struct CounterView: View {
    let viewModel: any CounterViewModelType

    @State private var state = CounterState(count: 0, isLoading: false)

    var body: some SwiftUI.View {
        VStack {
            Button("Increment") { viewModel.increment() }
                .disabled(state.isLoading)

            Text(state.isLoading ? "Loading…" : "\(state.count)")

            Button("Decrement") { viewModel.decrement() }
                .disabled(state.isLoading)
        }
        .onReceive(viewModel.statePublisher) {
            state = $0
        }
    }
}

We need two things:

• Declare a new @State variable with the state that will render the view.
• Subscribe to the underlying view model publisher, setting the new state.

That gets the job done without a lot of boilerplate. But as always, things can be improved.

The final solution

I always like to think from an API point of view. That is, which is the API I would like to have and work backwards from there. I’d like to:

1. Avoid having to subscribe each time to the view model publisher and reset the state.
2. I’d like to avoid setting an initial, arbitrary, @State variable on the view. The view model should be in charge of providing the initial state, not the view itself.

With those two preconditions, our ideal solution would look like this:

struct CounterView: View {
    let viewModel: any CounterViewModelType

    var body: some SwiftUI.View {
        WithViewModel(viewModel: viewModel) { state in
            VStack {
                Button("Increment") { viewModel.increment() }
                    .disabled(state.isLoading)

                Text(state.isLoading ? "Loading…" : "\(state.count)")

                Button("Decrement") { viewModel.decrement() }
                    .disabled(state.isLoading)
            }
        }
    }
}

Let’s then create that WithViewModel wrapper.

@MainActor
protocol ViewModelType<State> {
    associatedtype State
    
    var statePublisher: Published<State>.Publisher { get }
}

@MainActor
struct WithViewModel<WrappedView, State>: View where WrappedView: View {
    @SwiftUI.State private var state: State?
    private let publisher: Published<State>.Publisher
    private let wrappedView: (State) -> WrappedView

    init<ViewModel>(
        viewModel: ViewModel,
        @ViewBuilder wrappedView: @escaping (State) -> WrappedView
    ) where ViewModel: ViewModelType<State> {
        self.wrappedView = wrappedView
        publisher = viewModel.statePublisher
    }

    var body: some View {
        root.onReceive(publisher) {
            state = $0
        }
    }

    @ViewBuilder
    private var root: some View {
        if let state {
            wrappedView(state)
        }
    }
}

Conclusion

Thanks for reaching the end of the article. It was hopefully an interesting exercise to make polymorphic observable objects work flawlessly with SwiftUI.

I think the final solution gets the job done with a fairly clean API, without fighting the SwiftUI framework too much to make it work.

But as I previously said, if you are lucky enough to target iOS 17, the new Observation framework solves all your problems. Well, almost all of them.

SwiftUI View Models: A Polymorphic Approach was originally published in The Swift Cooperative on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

I first wrote about state containers back in 2017. In its simplest form, a state container is just a wrapper type over some State type.

class StateContainer<State>: ObservableObject {
    @Published var state: State
}

Most unidirectional architecture frameworks have a similar base class, so we model all our feature state inside that State type, whether that’s data that should trigger view renders or not.

And that’s one of the main bottlenecks of some Redux-ish architectures that tend to model all the app state in a single place: view bodies recompute even if the state change was unrelated to that view. There are certainly ways to fix that (like TCA’s ViewStore), but as always, that comes with complexity and also with a feeling that we are kind of fighting the framework.

Fortunately, the new Observation framework is here to fix this. Or not… Let’s see.

Unnecessary re-rendering

Let’s have some foundation in place first via the simplest example that I could come up with. An app that generates a random number and shows it on screen. It also has a “noop” button, which does nothing (it just sets a piece of private state).

// CounterView.swift
struct CounterView: View {
    @StateObject private var viewMoldel = CounterViewModel()

    var body: some View {
        VStack {
            Text("\(viewMoldel.state.count)")
            Button("Random number") { viewMoldel.generateRandomNumber() }
            Button("Noop") { viewMoldel.noop() }
        }
    }
}

// CounterViewModel.swift
struct CounterViewState {
    fileprivate(set) var count = 0
    fileprivate var privateCount = 0
}

class CounterViewModel: StateContainer<CounterViewState> {
    func generateRandomNumber() {
        state.count = Int.random(in: 0 ..< 100)
    }

    func noop() {
        state.privateCount = Int.random(in: 0 ..< 100)
    }
}

As you can imagine, setting both the count (which is the state read in the view body) or the privateCount (which is not read by the view), will trigger the view body to recompute.

A possible option to fix this issue is to extend the State type so we have a little more control over when the change should trigger a render pass. Something like this:

protocol StateType {
    static func shouldViewUpdate(lhs: Self, rhs: Self) -> Bool
}

extension StateType {
    static func shouldViewUpdate(lhs: Self, rhs: Self) -> Bool {
        true
    }
}

class StateContainer<State: StateType>: ObservableObject {
    var state: State { // Ideally protected
        willSet {
            guard State.shouldViewUpdate(lhs: newValue, rhs: state) else {
                return
            }
            objectWillChange.send()
        }
    }
}

And now, each State type can tell when a change should trigger the view render:

struct CounterViewState: StateType {
    fileprivate(set) var count = 0
    fileprivate var privateCount = 0

    static func shouldViewUpdate(lhs: Self, rhs: Self) -> Bool {
        lhs.count != rhs.count
    }
}

If you are familiar with React, this is similar to shouldComponentUpdate.

Of course, this is not ideal and it’s quite error-prone. Having to update shouldViewUpdate whenever we add properties read by the view will likely end up getting out-of-sync. There are other better ways to do this, like having an explicit Rendered type.

protocol StateType {
    associatedType Rendered: Equatable
    var rendered: Rendered { get }
}

extension StateType {
    static func shouldViewUpdate(lhs: Self, rhs: Self) -> Bool {
        lhs.rendered != rhs.rendered
    }
}

In this case, the view will always read our rendered type and will only render as long as the new rendered is different from the previous one. But as always, this imposes constraints on our StateType, increasing the overall complexity and removing some freedom about how to model our state.

Fortunately, the new Observation framework is here to help.

Enter the @Observable macro

iOS 17 changed completely how we observe changes from SwiftUI views.

• SwiftUI is no longer coupled with the Combine framework when it comes to observing external state updates (we don’t need @Published properties any longer).
• Performance is improved as the view will only update as long as the related state changes (the one read inside the view body).

That premise is really nice. So let’s refactor our previous code and see what happens:

@Observable
class StateContainer<State> {
    var state: State

    init(initialState: State) {
        self.state = initialState
    }
}

// Inside our view...
@State private var viewMoldel = CounterViewModel()

Interestingly, the view body is still recomputed when tapping on the “noop” button 🤔.

If we think about it, “it makes sense”. We are marking the StateContainer as @Observable, which observes all the underlying properties inside it (in this case, only the state). Being state a value type, changing a piece of private state inside it mutates the whole value type, which will trigger the view body recomputation, regardless of the actual mutation and if that affects the view or not.

While this “makes sense”, it is also confusing and it can greatly affect performance and unnecessary re-renders when modeling our state using value types.

The solution would be to mark the underlying State as @Observable. Unfortunately, this cannot be done with value types. At least for now…

Leaving value types behind

As long as I like to model my state with value types, both the Observable framework and SwiftData (with its @Model macro) are forcing a lot of our types to be reference types, whether we like that or not…

The solution to our problem is just to change our State type to be a class.

class StateContainer<State> { } // This no longer needs to be Observable

@Observable
final class CounterViewState {
    fileprivate(set) var count = 0
    fileprivate var privateCount = 0
}

But if we really want to use value types, we have other options…

ObservableState

The Pointfree guys have come up with a clever way to bypass this limitation for value types, by creating their own macro @ObservableState. Hopefully, that macro will get its own library one day so we can use it without the whole TCA library. The change is just as simple as marking our value type with the @ObservableState macro.

@ObservableState
struct State {
    var count = 0
    fileprivate var privateCount = 0
}

Only you can decide if adding that macro is worth it for the value semantics benefits… 🤷‍♂.

Conclusion

Fortunately, all this won’t be an issue as long as we don’t use these kinds of generic state containers with that single State type. If we just happen to use a simple view model, in most cases, we can just mark our view model as @Observable and be sure that mutating a private property won’t trigger view re-renders.

But the truth is that this problem affects a lot of unidirectional libraries that are migrating to the Observable framework. Of course, there’s a simple “solution”, by forcing the State type to be an Observable reference type.

protocol StateContainer {
    associatedtype State: Observable
    var state: State { get }
}

Depending on the app, that might be a big constraint (State can’t be an enum for instance…) for negligible performance benefits. As always, it depends.

In any case, hopefully, Swift will support Observable value types in the future, making all this article obsolete.

Looking forward to that.

SwiftUI Observation Framework: State Containers was originally published in The Swift Cooperative on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Coming from UIKit and imperative UI frameworks, SwiftUI is a paradigm shift. It tries to avoid sync issues between our view and our state (which presumably are one of the main sources of bugs in UI development), in a way where we simply tell SwiftUI the immutable description of how we’d like our view to look and the framework handles the rest. Views are usually subscribed to a source of truth so, when it changes, the “pure” function (State) -> View Description re-executes so that SwiftUI interprets that view description into a real view. We could simplify things and say that SwiftUI is all about two functions.

• (State) -> View Description (Us)
• (ViewDescription) -> Real View (SwiftUI)

This is all really nice. But there’s a subtle detail under all this: we no longer control the view lifecycle.

With UIKit, we did control when our views were created and destroyed. We had the instance, and we could do whatever we wanted with it. Now, the framework is in charge of those instances and real views are just implementation details. Not only that, we don’t control the lifecycle of the view descriptions either. Those view values can be called at any time, multiple times, and it’s also up to the framework to do that. We shouldn’t make any assumptions based on how things work today, because SwiftUI will likely change how our view values are created in the future.

Fair enough, we don’t control our views… But can we still have control over the underlying state of those views? That is, can we still control when our view models are created and destroyed? It’s still very common to hook onto some lifecycle methods like init and deinit inside our view models to subscribe and unsubscribe to different data sources, implement RAII patterns (like Combine’s Cancellable protocol, whose subscriptions are automatically canceled when destroyed), etc… Is that still something we can do? Should we instead rely on different lifecycle methods like onAppear and onDisappear? The truth is that, depending on the SwiftUI version, my opinion has changed. Let me rephrase that. Depending on the SwiftUI version, Apple has confused me even more.

Let’s start from the beginning.

It all started with @ObservedObject

Let’s have a simple example first. Let’s suppose we have two screens:

• The first one computes a random number every two seconds and uses that number as the initial value to create a second screen when a button is tapped.
• The second one uses that previous initial number and allows the user to increment or decrement that value.

struct ContentView: View {
    @State private var showingSheet = false
    @State private var number = 0

    var body: some View {
        Button("Show counter with value: \(number)") {
            showingSheet = true
        }
        .sheet(isPresented: $showingSheet) {
            CounterView(viewModel: CounterViewModel(initialValue: number))
        }
        .task {
            while true {
                try! await Task.sleep(nanoseconds: 2 * NSEC_PER_SEC)
                number = Int.random(in: 0..<100)
            }
        }
    }
}

struct CounterView: View {
    @ObservedObject private var viewModel: CounterViewModel

    init(viewModel: CounterViewModel) {
        self.viewModel = viewModel
    }

    var body: some View {
        VStack {
            Button("Increment", action: viewModel.increment)
            Text("Number is \(viewModel.count)")
            Button("Decrement", action: viewModel.decrement)
        }
    }
}

class CounterViewModel: ObservableObject {
    @Published private(set) var count = 0

    init(initialValue: Int) {
        count = initialValue
    }

    func increment() {
        count += 1
    }

    func decrement() {
        count -= 1
    }
}

Of course, that code results in the wrong behavior as we can see in the video.

As you might have guessed, the underlying issue is that the CounterView, together with its CounterViewModel, are being recreated…

The first version of SwiftUI came with a simple way of observing changes to an external piece of state. @ObservedObject was not opinionated about how to handle the underlying lifecycle of the observed object, it was up to us.

In simple scenarios, we could have a single ObservableObject, inject it as an environment object at the root node of your application, and access it in any children node. It was simple, but depending on the scale and the complexity of the app, it might not be the best solution.

If SwiftUI doesn’t handle the lifecycle of our view models, we should come up with a way to do so. A common solution would be to delegate that object lifecycle responsibility to some sort of dependency container (a favorite of mine is Factory) and leverage scopes to fix our issue.

import Factory

extension Container {
    func counterViewModel(initialValue: Int) -> Factory<CounterViewModel> {
        self { CounterViewModel(initialValue: initialValue) }.shared
    }
}

// In ContentView...
CounterView(viewModel: Container.shared.counterViewModel(initialValue: number)())

In this case, by using the shared scope, the same view model is reused when the view tries to create a new one. Once the view is dismissed, the underlying view model is destroyed as well, creating a new one the next time we present the screen.

Even if we have managed to reuse the very same view model, view models are still eager. Even if SwiftUI hasn’t created/shown the real view yet, the fact that the view description has been created forces our view model to be created… (NavigationLink is well known for its eager behavior). This means that patterns like RAII or attaching subscriptions to view model initialization could not be the best idea in SwiftUI, and maybe, only maybe, onAppear and similar methods are a better approach… Well, iOS 14 and @StateObject changed that.

@StateObject and iOS 14 to the rescue

Fortunately, iOS 14 and @StateObject allowed to sync the lifecycle of our view models to the lifecycle of our real views.

• Real views are reusing the correct view model, no matter how many times we create new view descriptions and instantiate new view models.
• View models are created lazily when the real view is created, not when the view description is created.
• View models are destroyed when the real view is destroyed.

Replacing our previous @ObservedObject with @StateObject is simple.

struct CounterView: View {
    @StateObject private var viewModel: CounterViewModel

    init(viewModel: CounterViewModel) {
        _viewModel = .init(wrappedValue: viewModel)
    }
   
    …
}

That change makes the app behave correctly. Even if the CounterView is re-created each time (alongside its view model), the new view model instance will only be used as the initial state, in case SwiftUI decides to remove the counter view completely from the hierarchy and show it again.

But isn’t it strange that we have to recreate the view model each time? As we previously mentioned, we could have code on init and deinit that could potentially be problematic if we run it multiple times… Yes, it’s generally a good idea to do few things on initializers, but sometimes it’s simply convenient to clean things up when objects are destroyed. The problem in this case is the place where we decided to create the view model. A subtle change fixes the issue.

struct CounterView: View {
    @StateObject private var viewModel: CounterViewModel

    init(initialValue: Int) {
        _viewModel = .init(wrappedValue: CounterViewModel(initialValue: initialValue))
    }

    …
}

Instead of injecting the view model into the CounterView, we simply pass the initial value and let the view create the view model. The trick is the wrappedValue parameter, which is a function, disguised by an @autoclosure.

init(wrappedValue thunk: @autoclosure @escaping () -> ObjectType)

That way, SwiftUI manages to only call that function to create the view model the first time the real view is created, and never the following times where the view description is re-created.

Having that function also gives us that lazy behavior for view models we mentioned previously. Let’s make a tiny change in our view layer to show the counter view navigated.

NavigationLink("Show counter with value: \(number)") {
    CounterView(initialValue: number)
}

NavigationLink creates the underlying CounterView eagerly. That means that any view model we need to create CounterView would also be created eagerly. Fortunately, @StateObject works perfectly for this case, creating the view model lazily (via the @autoclosure function we mentioned earlier) at the exact moment when the real view is presented on the screen.

@StateObject is quite easy to misuse though. Unless we use the correct initializer and have the view model instantiation inside the @autoclosure, we’ll lose all those nice benefits of not creating the view models multiple times and have them created lazily. But if done correctly, it provides a perfect way so views can manage the underlying lifecycle of their view models.

At this point. I was fully convinced. Relying on initialization and deinitialization for subscriptions and unsubscriptions and implementing the RAII pattern this way was still feasible in SwiftUI. Not only feasible. It was a good idea!

Well, I’m no longer sure.

iOS 17 and the @Observable macro

iOS 17 changed everything with the new @Observable macro. It not only decoupled SwiftUI from Combine, but it also made SwiftUI far more efficient about when to update views and when not, depending on the underlying state that is read in the body property.

Let’s blindly follow Apple’s guide to migrate from the old Combine world to the new shiny @Observable world.

@Observable class CounterViewModel {
    private(set) var count = 0
    …
}

struct CounterView: View {
    @State private var viewModel: CounterViewModel

    init(initialValue: Int) {
        viewModel = CounterViewModel(initialValue: initialValue)
    }
    …
}

Changes are minimal. CounterViewModel no longer needs to be an ObservableObject and can simply adopt the new @Observable macro syntax. Then, we no longer need to use @StateObject and we can use @State, which is freeing to use regardless of the nature of the object type (whether we use values or reference types). @State still makes sure that the proper view model is always used by the view.

It seems like a naive change. Out of the blue though, we’ve lost two important things we had with @StateObject.

1. The view model is created multiple times now, each time the ContentView view is recomputed.
2. The view model is no longer created lazily.

In fact, we’ve lost another thing… The fact that the view model’s deinit is never called. An important thing indeed! At the moment I’m writing this article, with Xcode 15.0, all @State properties are leaked. Fortunately, this issue has been fixed in Xcode 15.2 beta.

As we did with @ObservedObject, let’s finally use the dependency container approach to fix both issues, the fact that we are creating multiple view models, eagerly.

To avoid creating multiple view models, we’ll have the very same code we previously had, by leveraging the shared scope to reuse the previously in-memory view model. As for the lazy part, we’ll simply have a function as a way to obtain our view model:

import Factory

extension Container {
    func counterViewModel(initialValue: Int) -> Factory<CounterViewModel> {
        self { CounterViewModel(initialValue: initialValue) }.shared
    }
}

struct CounterView: View {
    private let viewModel: () -> CounterViewModel

    init(initialValue: Int) {
        viewModel = { Container.shared.counterViewModel(initialValue: initialValue)() }
    }

    …
}

Conclusion

I guess the conclusion to all this might be that we shouldn’t rely on controlling the view model’s lifecycle.

While @StateObject seemed like the perfect way to rely back on proper init and deinit behavior (at least the proper way we were used to with UIKit), that behavior has been broken with the new @Observable macro approach. Yes, we can use external dependency containers to fix all these issues, but those aren’t free and can be hard to maintain and error-prone (not to mention that they feel like workarounds to me).

Relying on the implicit call of init and deinit might be a bad practice we should avoid with SwiftUI. Instead, I think a safer approach is to explicitly rely on lifecycle methods that SwiftUI views give us (whether those are onAppear, onDisappear, or different ones).

But that’s only my opinion, at least for now. In any case, I’m still confused. Who knows, maybe iOS 18 will change my mind, again.

SwiftUI View Models: Lifecycle Quirks was originally published in The Swift Cooperative on Medium, where people are continuing the conversation by highlighting and responding to this story.

During the last few months, I’ve been reading “Unit Testing Principles, Practices, and Patterns” by Vladimir Khorikov. It’s definitely one of the best books I’ve read about testing. One of the things I’ve liked the most is that the author offers a “framework of reference” to analyze how good a test is based on the following traits:

• Protection against regressions.
• Resistance to refactoring.
• Fast feedback.
• Maintainability.

Those traits are what the author calls “the four pillars of a good unit test”. And the interesting part is that we cannot maximize all of them. Some types of tests provide the best protection against regression and resistance to refactoring but with very slow feedback (like UI testing). At the end of the day, we have to think and decide the best trade-offs for our specific application and use cases.

I’ve been thinking a lot about this and how to apply that framework to improve my testing, especially applied to the view layer, where things are especially tricky. And more specifically to SwiftUI, where we are still rethinking good practices and patterns to better fit this new exciting platform.

This article will not tell you “the best way to test SwiftUI code”. Rather, I’ll walk you through a simple example and the different ways we have at our disposal on iOS to test it, its trade-offs, and my subjective thoughts and observations.

Let’s go!

Initial code

The example application is simple but complex enough to showcase interesting testing techniques. It loads a bunch of todos from an API, shows them on the screen, and saves them to disk.

The code looks like this.

import SwiftUI

struct TodoListView: View {
    @State private var state: ListViewState = .idle
    private let databaseManager: DatabaseManager = .shared

    var body: some View {
        Group {
            switch state {
            case .idle:
                Button("Start") {
                    Task {
                        await refreshTodos()
                    }
                }

            case .loading:
                Text("Loading…")

            case .error:
                VStack {
                    Text("Oops")
                    Button("Try again") {
                        Task {
                            await refreshTodos()
                        }
                    }
                }

            case .loaded(let todos):
                VStack {
                    List(todos) {
                        Text("\($0.title)")
                    }
                }
            }
        }.onChange(of: state) {
            guard case .loaded(let todos) = $0 else {
                return
            }

            databaseManager.save(data: todos)
        }
    }

    private func refreshTodos() async {
        state = .loading
        do {
            let todos = try await loadTodos().sorted { $0.title < $1.title }
            state = .loaded(todos)
        } catch {
            state = .error
        }
    }

    private func loadTodos() async throws -> [Todo] {
        let url = URL(string: "https://jsonplaceholder.typicode.com/todos/")!
        let (data, _) = try await URLSession.shared.data(from: url)
        let todos = try JSONDecoder().decode([Todo].self, from: data)
        return todos
    }
}

enum ListViewState: Equatable {
    case idle
    case loading
    case loaded([Todo])
    case error
}

struct Todo: Codable, Identifiable, Equatable {
    var userId: Int
    var id: Int
    var title: String
    var completed: Bool
}

final class DatabaseManager {
    static let shared: DatabaseManager = .init()
    private init() {}

    func save<T>(data: T) where T: Encodable {
        // TBD
    }
}

That code is far from ideal, but it gets the job done without overcomplicating things for now.

We want to test that:

• The initial screen layout is correct.
• The screen shows the correct feedback to the user while the information is being loaded.
• The screen shows feedback to the user in case an error arises.
• The screen shows the sorted list of todos to the user after downloading them from the network.
• The todos are correctly saved to disk.

We’ll test all those use cases with different tools, starting with the simpler one: using XCUITest.

UI testing via XCUITest

XCUITest is Apple’s first-party framework for creating UI tests. Using UI tests as our first approach in legacy code bases without tests is usually a smart choice. It doesn’t require any changes in the application, and it provides a safety net that allows further refactoring afterward, something that will be needed to have better unit tests.

The code looks like this.

import SnapshotTesting
import XCTest

final class TodoListViewUITests: XCTestCase {
    func testIdle() {
        // Given
        let app = XCUIApplication()
        app.launch()

        // Then
        assertSnapshot(
            matching: app.screenshot().withoutStatusBarAndHomeIndicator,
            as: .image
        )
    }

    func testLoading() {
        // Given
        let app = XCUIApplication()
        app.launch()

        // When
        app.buttons.element.tap()

        // Then
        assertSnapshot(
            matching: app.screenshot().withoutStatusBarAndHomeIndicator,
            as: .image
        )
    }

    func testLoaded() {
        // Given
        let app = XCUIApplication()
        app.launch()

        // When
        app.buttons.element.tap()

        // Then
        guard app.collectionViews.element.waitForExistence(timeout: 5) else {
            XCTFail()
            return
        }
            
        assertSnapshot(
            matching: app.screenshot().withoutStatusBarAndHomeIndicator,
            as: .image
        )
    }
}

private extension XCUIScreenshot {
    // Let's get rid of both the status bar and home indicator to have deterministic results.
    var withoutStatusBarAndHomeIndicator: UIImage {
        let statusBarOffset = 40.0
        let homeIndicatorOffset = 20.0
        let image = image
        return .init(
            cgImage: image.cgImage!.cropping(
                to: .init(
                    x: 0,
                    y: Int(statusBarOffset * image.scale),
                    width: image.cgImage!.width,
                    height: image.cgImage!.height - Int((statusBarOffset + homeIndicatorOffset) * image.scale)
                )
            )!,
            scale: image.scale,
            orientation: image.imageOrientation
        )
    }
}

Some interesting remarks:

• Combining UI tests with screenshot testing is really powerful, as it simplifies quite a lot the view assertion part. Screenshot testing has quite a few downsides that are out of the scope of this article, but they are extremely convenient.
• To make them work deterministically, we must remove both the status bar and the home indicator (yes, the home indicator sometimes changes between test runs ¯\_(ツ)_/¯).
• We cannot test the error case as we don’t have an easy way to control the network.
• Not controlling the network means that tests are slow, relying on timeouts. If we run the tests without having an internet connection, they will fail, etc.
• The loading test is not deterministic. Depending on how fast the network and API response is, the snapshot will be done in the “Loading…” screen or in the loaded screen.
• The loaded test might as well not be deterministic, depending on the network result (loadTodos endpoint). At the moment, it returns the very same data every time, but that might change.
• We cannot test that the data was stored in the database. The UI tests run in a different process than the test runner, so accessing the underlying FileManager‘s data is impossible.
• It’s really hard and cumbersome to prepare tests to go to the specific screen we want to test. The app opens from scratch, and we need to navigate to the screen under test first before performing assertions.

As you can see, we have many important problems with using XCUITest. It doesn’t seem like the best approach. And, of course, it shouldn’t. UI tests should cover just a small part of critical business paths, as they are the tests that more reliably mimic user interaction.

But the most important problem is the time it takes to run the test suite, 15 seconds for just four tests. And that’s with a very good internet connection.

Yes, there are ways to use launchArguments and ProcessInfo to know that we are running UI tests and performing different tasks, like controlling the network and providing a less flaky experience. But that not only couples the main code with testing code, but it also worsens one of the other pillars of good unit tests, maintainability.

In summary, while UI tests are extremely good at catching regressions and resisting code changes and refactors, the slow feedback and bad maintainability make them only a good choice for a small number of tests, ideally, those covering really important, high-level use cases.

UI testing via EarlGrey 2.0

In the past, we had KIF, a good white-box UI testing alternative to XCUITest. While KIF still works, it has some limitations. The main one is that we cannot interact with alerts and other windows different from the main one. AFAIK this was the main reason why Google abandoned their first version of EarlGrey, which used a similar white-boxed approach to UI testing, in favor of leveraging the existing XCUITest platform, and adding some “magic” on top. In 2023, I think EarlGrey 2.0 is the only good alternative to XCUITest worth considering, IMO.

With EarlGrey 2.0, we can create a specific, properly configured view and set it as the window’s root view controller. To control the network and database, we need to do a small refactor of TodoListView.

• We’ll inject an async function to control the API call.
• We’ll inject an abstraction of the database manager, allowing us to inject the proper mock later.

import SwiftUI

struct TodoListView: View {
    @State private var state: ListViewState = .idle

    private let databaseManager: DatabaseManagerProtocol
    private let loadTodos: () async throws -> [Todo]

    init(
        databaseManager: DatabaseManagerProtocol,
        loadTodos: @escaping () async throws -> [Todo] = loadTodos
    ) {
        self.databaseManager = databaseManager
        self.loadTodos = loadTodos
    }

    var body: some View { … }

    private static func loadTodos() async throws -> [Todo] { … }
}

protocol DatabaseManagerProtocol {
    func save<T>(data: T) where T: Encodable
}

final class DatabaseManager: DatabaseManagerProtocol {
    static let shared: DatabaseManager = .init()
    private init() {}

    func save<T>(data: T) where T: Encodable {
        // TBD
    }
}

With that in place, the tests look similar to the previous ones. The given methods will configure the TodoListView with the correct todos and a database spy that we can use to double-check that they have been saved correctly.

import XCTest
import SnapshotTesting

final class TodoListViewUITests: XCTestCase {
    func testIdle() {
        // Given
        let app = XCUIApplication()
        app.launch()

        // Then
        assertSnapshot(
            matching: app.screenshot().withoutStatusBarAndHomeIndicator,
            as: .image
        )
    }

    func testLoading() {
        // Given
        let app = XCUIApplication()
        app.launch()

        let todosSaved = todoListViewHost().givenLoadingTodoListView()

        // When
        app.buttons.element.tap()

        // Then
        assertSnapshot(
            matching: app.screenshot().withoutStatusBarAndHomeIndicator,
            as: .image
        )

        XCTAssertFalse(todosSaved())
    }

    func testLoaded() {
        // Given
        let app = XCUIApplication()
        app.launch()

        let todosSaved = todoListViewHost().givenLoadedTodoListView()

        // When
        app.buttons.element.tap()

        // Then
        assertSnapshot(
            matching: app.screenshot().withoutStatusBarAndHomeIndicator,
            as: .image
        )

        XCTAssertTrue(todosSaved())
    }

    func testError() {
        // Given
        let app = XCUIApplication()
        app.launch()
        
        let todosSaved = todoListViewHost().givenErrorTodoListView()
        
        // When
        app.buttons.element.tap()
        
        // Then
        assertSnapshot(
            matching: app.screenshot().withoutStatusBarAndHomeIndicator,
            as: .image
        )
        
        XCTAssertFalse(todosSaved())
    }
}

EarlGrey requires the notion of a “host”, which is a kind of proxy that lets us move between the two worlds: the “test runner process” world and the “app process” world.

As you can imagine, those two worlds cannot be crossed wildly. There are some limitations. We can only use types that are visible to the Objective-C runtime, as you can see from the @objc keyword in the TodoListViewHost protocol. Also, the different files must belong to very specific targets. The whole configuration is quite cumbersome.

This article is not intended to be an EarlGrey’s tutorial. There’s extensive documentation and examples on their web page if you are interested.

These are the two files needed for our example.

@objc
protocol TodoListViewHost {
    func givenLoadedTodoListView() -> () -> Bool
    func givenLoadingTodoListView() -> () -> Bool
    func givenErrorTodoListView() -> () -> Bool
}

// Hosts cannot be reused across tests. Make sure to create a new one each time.
let todoListViewHost: () -> TodoListViewHost = {
    unsafeBitCast(
        GREYHostApplicationDistantObject.sharedInstance,
        to: TodoListViewHost.self
    )
}

import SwiftUI
@testable import Testing

extension GREYHostApplicationDistantObject: TodoListViewHost {
    func givenLoadingTodoListView() -> () -> Bool {
        givenTodoListView {
            try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
            fatalError("Should never happen")
        }
    }

    func givenLoadedTodoListView() -> () -> Bool {
        givenTodoListView {
            // Load unsorted todos so we can verify that they are properly sorted in the view.
            Set(0...9).map { .init(userId: $0, id: $0, title: "\($0)", completed: false) }
        }
    }

    func givenErrorTodoListView() -> () -> Bool {
        givenTodoListView {
            struct SomeError: Error {}
            throw SomeError()
        }
    }

    private func givenTodoListView(loadTodos: @escaping () async throws -> [Todo]) -> () -> Bool {
        let databaseSpy = DatabaseManagerSpy()
        let view = TodoListView(databaseManager: databaseSpy, loadTodos: loadTodos)
        UIWindow.current.rootViewController = UIHostingController(rootView: view)
        return { databaseSpy.called }
    }
}

private extension UIWindow {
    static var current: UIWindow {
        UIApplication.shared.connectedScenes
            .compactMap { $0 as? UIWindowScene }
            .flatMap(\.windows)
            .filter(\.isKeyWindow)
            .first!
    }
}

private class DatabaseManagerSpy: DatabaseManagerProtocol {
    var called: Bool = false

    func save<T>(data: T) where T: Encodable {
        called = true
    }
}

We have improved the initial UI tests quite a lot:

• Tests are now much more deterministic. They never go to the network, and they take less time to execute because of that.
• We can reliably test the loading and loaded cases, as well as the error case.
• We can test that the todos have been properly saved (or not saved) into the database (well, at least we can test that the message is properly sent to the database manager).
• We can set a specific view as the window’s root view without having to navigate to the specific screen as we have to do with normal UI tests.

But…

• Maintainability is still hard. The “given” is scattered across different files and targets.
• The bridge to cross both processes rely on @objc, which is not very convenient and an important limitation for the types we can use.
• We still have a very slow feedback loop. 12 seconds is still quite a lot of time for just four tests.
• We are coupled now with EarlGrey, a Google’s framework whose future is unknown… That’s something we should take into account. What’s the impact of Google abandoning that framework?

Let’s keep looking for better alternatives to test our view. Let’s finally move to unit tests.

Unit testing the view

We can hardly justify those big numbers for our main test suite. One of the most important aspects of tests is that they allow refactoring with confidence, and for that, we need to execute tests a lot while performing changes. UI tests don’t allow that. They are kind of a last-resort safety net to make sure we haven’t broken anything, but we should have better solutions.

If we want to unit test the view, we need to have a way to perform actions on it. In UIKit, this was as easy as exposing the subviews and exercising those actions via APIs like button.sendActions(for: .touchUpInside)(even if that’s not exactly correct, as subviews should be implementation details of the parent view).

But SwiftUI is different. We don’t have access to the underlying subviews, as they are implementation details that the framework decides based on a View value.

Fortunately, there are tools like ViewInspector that we can use to access view elements and mimic those view interactions.

A unit test of the view looks like this.

func testLoading() throws {
    // Given
    let databaseSpy = DatabaseManagerSpy()
    let sut = TodoListView(databaseManager: databaseSpy) {
        try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
        fatalError("Should never happen")
    }

    // When
    try sut.inspect().find(button: "Start").tap()

    // Then
    assertSnapshot(matching: sut, as: .wait(for: 0.01, on: .image))
    XCTAssertFalse(databaseSpy.called)
}

While the ViewInspector library correctly retrieves and taps the button via try sut.inspect().find(button: "Start").tap(), the final snapshot is not the loading view but the idle view. Why?

If we set some logs in the view body, we can see that the view body is correctly recomputed but always with the idle state… 🤔

Let’s see what happens if, instead of handling the state via an @State property wrapper, we have a view model via a @StateObject.

Let’s create the view model first, extracting all the logic from the view.

@MainActor
final class TodoListViewModel: ObservableObject {
    @Published private(set) var state: ListViewState = .idle {
        didSet {
            guard case .loaded(let todos) = state else {
                return
            }

            databaseManager.save(data: todos)
        }
    }

    private let databaseManager: DatabaseManagerProtocol
    private let loadTodos: () async throws -> [Todo]

    private var tasks: [Task<Void, Never>] = .init()

    deinit {
        for task in tasks {
            task.cancel()
        }
    }

    init(
        databaseManager: DatabaseManagerProtocol,
        loadTodos: @escaping () async throws -> [Todo] = loadTodos
    ) {
        self.databaseManager = databaseManager
        self.loadTodos = loadTodos
    }

    enum Message {
        case startButtonTapped
        case tryAgainButtonTapped
    }

    func send(_ message: Message) {
        switch message {
        case .startButtonTapped, .tryAgainButtonTapped:
            tasks.append(
                Task {
                    await refreshTodos()
                }
            )
        }
    }

    private func refreshTodos() async {
        state = .loading
        do {
            let todos = try await loadTodos().sorted { $0.title < $1.title }
            state = .loaded(todos)
        } catch {
            state = .error
        }
    }

    static func loadTodos() async throws -> [Todo] {
        let url = URL(string: "https://jsonplaceholder.typicode.com/todos/")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Todo].self, from: data)
    }
}

We have extracted all the important logic in the view model, having the view layer dumb, only forwarding events to the view model and rendering itself based on its state.

The view layer’s API hasn’t changed, though. It’s still created by injecting a database and a way to load todos, keeping the view model private.

struct TodoListView: View {
    @StateObject private var viewModel: TodoListViewModel

    init(
        databaseManager: DatabaseManagerProtocol,
        loadTodos: @escaping () async throws -> [Todo] = TodoListViewModel.loadTodos
    ) {
        _viewModel = .init(wrappedValue: .init(databaseManager: databaseManager, loadTodos: loadTodos))
    }

    var body: some View {
        Group {
            switch viewModel.state {
            case .idle:
                Button("Start") {
                    viewModel.send(.startButtonTapped)
                }

            case .loading:
                Text("Loading…")

            case .error:
                VStack {
                    Text("Oops")
                    Button("Try again") {
                        viewModel.send(.tryAgainButtonTapped)
                    }
                }

            case .loaded(let todos):
                VStack {
                    List(todos) {
                        Text("\($0.title)")
                    }
                }
            }
        }
    }
}

As the view API didn’t change, the test looks the same:

func testLoading() throws {
    // Given
    let databaseSpy = DatabaseManagerSpy()
    let sut = TodoListView(databaseManager: databaseSpy) {
        try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
        fatalError("Should never happen")
    }

    // When
    try sut.inspect().find(button: "Start").tap()

    // Then
    assertSnapshot(matching: sut, as: .wait(for: 0.01, on: .image))
    XCTAssertFalse(databaseSpy.called)
}

As you might expect, the test still fails, but having the view model gives us much more insights than before.

try sut.inspect().find(button: "Start").tap() is causing the view model to be initialized three times. Then assertSnapshot causes the final initialization of the view model. In total, while the view is initialized only once, its underlying view model is initialized four times. For some reason, the view model is not correctly retained by the underlying view when running on tests. It’s destroyed and recreated when accessed several times. In fact, we can see the following runtime warnings…

Let’s now try something different. Let’s inject the view model, so we have a way to retain the view model in the test scope ourselves.

struct TodoListView: View {
    @StateObject private var viewModel: TodoListViewModel

    init(viewModel: @escaping @autoclosure () -> TodoListViewModel) {
        _viewModel = .init(wrappedValue: viewModel())
    }

    …
}

Now, the test looks like this.

func testLoading() throws {
    // Given
    let databaseSpy = DatabaseManagerSpy()
    let viewModel = TodoListViewModel(databaseManager: databaseSpy) {
        try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
        fatalError("Should never happen")
    }
    let sut = TodoListView(viewModel: viewModel)

    // When
    try sut.inspect().find(button: "Start").tap()

    // Then
    assertSnapshot(matching: sut, as: .wait(for: 0.01, on: .image))
    XCTAssertFalse(databaseSpy.called)
}

We still get the Accessing StateObject’s object without being installed on a View. This will create a new instance each time. error, but the view model is only initialized once, as expected, so everything works correctly. To avoid the aforementioned runtime warning, we can send the messages directly to the view model to “simulate” the interaction with the UI and remove the ViewInspector usage (which kind of feels like a hack to me…).

Having the view model around in the test can also be handy to assert its state if needed.

assertSnapshot(
    matching: viewModel.state,
    as: .dump
)

The dump strategy can be more fragile than expected sometimes, coupling ourselves with the specific shape of the underlying types we use for our state. Sometimes, it’s a little bit more future-proof to use a different strategy, like the JSON one, when our state conforms to Encodable.

The final test suite looks like this.

@MainActor
final class TodoListViewUnitTests: XCTestCase {
    func testIdle() {
        // Given
        let (viewModel, _) = givenTodoListViewModel {
            fatalError("Should never happen")
        }
        let sut = TodoListView(viewModel: viewModel)

        // Then
        assertSnapshot(matching: sut, as: .image)
        assertSnapshot(matching: viewModel.state, as: .json)
    }

    func testLoading() async throws {
        // Given
        let (viewModel, todosSaved) = givenTodoListViewModel {
            try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
            fatalError("Should never happen")
        }
        let sut = TodoListView(viewModel: viewModel)

        // When
        viewModel.send(.startButtonTapped)
        try await Task.sleep(nanoseconds: 1_000_000) // Wait for Tasks...

        // Then
        assertSnapshot(matching: sut, as: .image)
        assertSnapshot(matching: viewModel.state, as: .json)
        XCTAssertFalse(todosSaved())
    }

    func testLoaded() async throws {
        // Given
        let (viewModel, todosSaved) = givenTodoListViewModel {
            // Load unsorted todos so we can verify that they are properly sorted in the view.
            Set(0...9).map { .init(userId: $0, id: $0, title: "\($0)", completed: false) }
        }
        let sut = TodoListView(viewModel: viewModel)

        // When
        viewModel.send(.startButtonTapped)
        try await Task.sleep(nanoseconds: 1_000_000) // Wait for Tasks...

        // Then
        assertSnapshot(matching: sut, as: .image)
        assertSnapshot(matching: viewModel.state, as: .json)
        XCTAssertTrue(todosSaved())
    }

    func testError() async throws {
        // Given
        let (viewModel, todosSaved) = givenTodoListViewModel {
            struct SomeError: Error {}
            throw SomeError()
        }
        let sut = TodoListView(viewModel: viewModel)

        // When
        viewModel.send(.startButtonTapped)
        try await Task.sleep(nanoseconds: 1_000_000) // Wait for Tasks...

        // Then
        assertSnapshot(matching: sut, as: .image)
        assertSnapshot(matching: viewModel.state, as: .json)
        XCTAssertFalse(todosSaved())
    }
}

private class DatabaseManagerSpy: DatabaseManagerProtocol {
    var called: Bool = false

    func save<T>(data: T) where T: Encodable {
        called = true
    }
}

@MainActor private func givenTodoListViewModel(loadTodos: @escaping () async throws -> [Todo]) -> (
    viewModel: TodoListViewModel,
    todosSaved: () -> Bool
) {
    let databaseSpy = DatabaseManagerSpy()
    let viewModel = TodoListViewModel(databaseManager: databaseSpy, loadTodos: loadTodos)
    return (viewModel, { databaseSpy.called })
}

So, we’ve gone from 12 seconds to 0,11 seconds. Still, 110 ms for just four unit tests could be considered a big number, especially when we have a big team with many developers and screens, where those numbers start to add up quickly, ending up with a test suite that needs several minutes to run.

For simple apps, this approach is a good trade-off. They are “fast enough”, and easy to read and maintain while covering quite a lot of surface area (view + view model) to maximize the protection against regressions and resistance to refactoring traits.

Testing the view layout and view model separately

Testing the view layout and the view model separately means that we could have our main test suite running just our view models, with our most important business logic running super fast, while the view layout tests, which run slower, could be run in a different target, at a different pace, maybe only by our CI, etc. They wouldn’t be integrated into the development process (in our continuous CMD+U while changing code). In a way, they would be more like “UI tests”. Even if they run much faster than UI tests, they still run slow.

The view model tests look like this:

@MainActor
final class TodoListViewModelUnitTests: XCTestCase {
    func testIdle() {
        // Given
        let (sut, _) = givenTodoListViewModel {
            fatalError("Should never happen")
        }

        // Then
        assertSnapshot(matching: sut.state, as: .json)
    }

    func testLoading() async throws {
        // Given
        let (sut, todosSaved) = givenTodoListViewModel {
            try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
            fatalError("Should never happen")
        }

        // When
        sut.send(.startButtonTapped)
        try await Task.sleep(nanoseconds: 1_000_000) // Wait for Tasks...

        // Then
        assertSnapshot(matching: sut.state, as: .json)
        XCTAssertFalse(todosSaved())
    }

    func testLoaded() async throws {
        // Given
        let (sut, todosSaved) = givenTodoListViewModel {
            // Load unsorted todos so we can verify that they are properly sorted in the view.
            Set(0...9).map { .init(userId: $0, id: $0, title: "\($0)", completed: false) }
        }

        // When
        sut.send(.startButtonTapped)
        try await Task.sleep(nanoseconds: 1_000_000) // Wait for Tasks...

        // Then
        assertSnapshot(matching: sut.state, as: .json)
        XCTAssertTrue(todosSaved())
    }

    func testError() async throws {
        // Given
        let (sut, todosSaved) = givenTodoListViewModel {
            struct SomeError: Error {}
            throw SomeError()
        }

        // When
        sut.send(.startButtonTapped)
        try await Task.sleep(nanoseconds: 1_000_000) // Wait for Tasks...

        // Then
        assertSnapshot(matching: sut.state, as: .json)
        XCTAssertFalse(todosSaved())
    }
}

Removing the screenshot of the view has decreased the time quite a lot. From 110 ms to just 20 ms.

These tests are still not ideal, though. We have those Task.sleep due to the underlying asynchronicity of the view model that could eventually lead to flaky tests. We have different ways to avoid that:

1. Making the view model’s API async

Having the send method asynchronous will lead to changes in the view model’s API, breaking the view. Also, we now have to manage the Task lifecycle inside the view layer if we need to cancel it, for instance.

@MainActor
final class TodoListViewModel: ObservableObject {
    func send(_ message: Message) async {
        switch message {
        case .startButtonTapped, .tryAgainButtonTapped:
            await refreshTodos()
        }
    } 
    …
}

struct TodoListView: View {
    @StateObject private var viewModel: TodoListViewModel

    init(viewModel: @escaping @autoclosure () -> TodoListViewModel) {
        _viewModel = .init(wrappedValue: viewModel())
    }

    var body: some View {
        Group {
            switch viewModel.state {
            case .idle:
                Button("Start") {
                    Task {
                        await viewModel.send(.startButtonTapped)
                    }
                }
     …
    }
    …
}

But the tests will be simpler, without waits.

func testLoaded() async {
    // Given
    let (sut, todosSaved) = givenTodoListViewModel {
        // Load unsorted todos so we can verify that they are properly sorted in the view.
        Set(0...9).map { .init(userId: $0, id: $0, title: "\($0)", completed: false) }
    }

    // When
    await sut.send(.startButtonTapped)

    // Then
    assertSnapshot(matching: sut.state, as: .json)
    XCTAssertTrue(todosSaved())
}

Unfortunately, not all tests will be as simple as that. The loading test will lead to an infinite wait.

func testLoading() async {
    // Given
    let (sut, todosSaved) = givenTodoListViewModel {
        try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
        fatalError("Should never happen")
    }

    // When
    await viewModel.send(.startButtonTapped) // we wait forever here

    // Then
    assertSnapshot(
        matching: sut.state,
        as: .json
    )
    XCTAssertFalse(todosSaved())
}

Also, I’m not sure it’s the correct API, though. It seems that we are only exposing the send method async because of tests… 🤔.

2. Using expectations

We can leverage expectations to wait until we have the state we need.

@MainActor
final class TodoListViewModelTests: XCTestCase {
    func testLoading() async {
        // Given
        let (sut, todosSaved) = givenTodoListViewModel {
            try await Task.sleep(nanoseconds: 1_000_000 * NSEC_PER_SEC)
            fatalError("Should never happen")
        }

        // When
        let expectation = expectation(description: "waiting for state")
        var cancellables = Set<AnyCancellable>()
        sut.$state.sink { state in
            guard case .loading = state else { return }
            expectation.fulfill()
        }.store(in: &cancellables)

        sut.send(.startButtonTapped)

        await fulfillment(of: [expectation], timeout: 5)

        // Then
        assertSnapshot(matching: sut.state, as: .json)
        XCTAssertFalse(todosSaved())
    }

    func testLoaded() async throws {
        // Given
        let (sut, todosSaved) = givenTodoListViewModel {
            // Load unsorted todos so we can verify that they are properly sorted in the view.
            Set(0...9).map { .init(userId: $0, id: $0, title: "\($0)", completed: false) }
        }

        // When
        let expectation = expectation(description: "waiting for state")
        var cancellables = Set<AnyCancellable>()
        sut.$state.sink { state in
            guard case .loaded = state else { return }
            expectation.fulfill()
        }.store(in: &cancellables)

        sut.send(.startButtonTapped)

        await fulfillment(of: [expectation], timeout: 5)

        // Then
        assertSnapshot(matching: sut.state, as: .json)
        XCTAssertTrue(todosSaved())
    }

    func testError() async throws {
        // Given
        let (sut, todosSaved) = givenTodoListViewModel {
            struct SomeError: Error {}
            throw SomeError()
        }

        // When
        let expectation = expectation(description: "waiting for state")
        var cancellables = Set<AnyCancellable>()
        sut.$state.sink { state in
            guard case .error = state else { return }
            expectation.fulfill()
        }.store(in: &cancellables)

        sut.send(.startButtonTapped)

        await fulfillment(of: [expectation], timeout: 5)

        // Then
        assertSnapshot(matching: sut.state, as: .json)
        XCTAssertFalse(todosSaved())
    }
}

3. Separating logic from effects

I have talked extensively about this approach in the past. We can extract the decision-making from the view model to the state type.

enum ListViewState: Equatable, Codable {
    case idle
    case loading
    case loaded([Todo])
    case error

    enum Message {
        case input(Input)
        case feedback(Feedback)

        enum Input {
            case startButtonTapped
            case tryAgainButtonTapped
        }

        enum Feedback {
            case didFinishReceivingTodos(Result<[Todo], Error>)
        }
    }

    enum Effect: Equatable {
        case loadTodos
        case saveTodos([Todo])
    }

    mutating func handle(message: Message) -> Effect? {
        switch message {
        case .input(.startButtonTapped), .input(.tryAgainButtonTapped):
            self = .loading
            return .loadTodos

        case .feedback(.didFinishReceivingTodos(.success(let todos))):
            self = .loaded(todos.sorted { $0.title < $1.title })
            return .saveTodos(todos)

        case .feedback(.didFinishReceivingTodos(.failure)):
            self = .error
            return nil
        }
    }
}

The view model, which becomes a humble object after extracting all the logic, looks like this now (just forwarding messages to the state type and interpreting effects).

@MainActor
final class TodoListViewModel: ObservableObject {
    @Published private(set) var state: ListViewState = .idle

    private let databaseManager: DatabaseManagerProtocol
    private let loadTodos: () async throws -> [Todo]

    private var tasks: [Task<Void, Never>] = .init()

    deinit {
        for task in tasks {
            task.cancel()
        }
    }

    init(
        databaseManager: DatabaseManagerProtocol,
        loadTodos: @escaping () async throws -> [Todo] = loadTodos
    ) {
        self.databaseManager = databaseManager
        self.loadTodos = loadTodos
    }

    func send(_ message: ListViewState.Message.Input) {
        send(.input(message))
    }

    private func send(_ message: ListViewState.Message) {
        guard let effect = state.handle(message: message) else { return }
        tasks.append(
            Task {
                await perform(effect: effect)
            }
        )
    }

    private func perform(effect: ListViewState.Effect) async {
        switch effect {
        case .loadTodos:
            do {
                let todos = try await loadTodos()
                send(.feedback(.didFinishReceivingTodos(.success(todos))))
            } catch {
                send(.feedback(.didFinishReceivingTodos(.failure(error))))
            }

        case .saveTodos(let todos):
            databaseManager.save(data: todos)
        }
    }

    private static func loadTodos() async throws -> [Todo] {
        let url = URL(string: "https://jsonplaceholder.typicode.com/todos/")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode([Todo].self, from: data)
    }
}

The tests are now simpler than ever.

@MainActor
final class TodoListViewModelUnitTests: XCTestCase {
    func testLoading() {
        // Given
        var sut = ListViewState.idle

        // When
        let effect = sut.handle(message: .input(.startButtonTapped))

        // Then
        assertSnapshot(matching: (sut, effect), as: .dump)
    }

    func testLoaded() {
        // Given
        var sut = ListViewState.loading

        // When
        let todos: [Todo] = Set(0...9).map { .init(userId: $0, id: $0, title: "\($0)", completed: false) }
        let effect = sut.handle(message: .feedback(.didFinishReceivingTodos(.success(todos))))

        // Then
        let expectedTodos = todos.sorted { $0.title < $1.title }
        XCTAssertEqual(effect, .saveTodos(expectedTodos))
        XCTAssertEqual(sut, .loaded(expectedTodos))
    }

    func testError() async throws {
        // Given
        var sut = ListViewState.loading

        // When
        struct SomeError: Error {}
        let effect = sut.handle(message: .feedback(.didFinishReceivingTodos(.failure(SomeError()))))

        // Then
        XCTAssertNil(effect)
        XCTAssertEqual(sut, .error)
    }
}

As you can see, we can have the normal XCTAssertEqual assertions, or we can assert the tuple (state, effect) snapshot (which can be quite handy when building the final assertion value is cumbersome). Take into account that assertSnapshot is several orders of magnitude slower than using XCTAssertEqual, so use it with caution.

Also, we have reduced the time to 10 ms. We don’t have waits, everything is deterministic, and we are testing the view logic, which has the highest ROI in unit testing.

Unit testing the state this way allows us to test all the corner cases very easily. Then, we can have a few “higher level” tests of the view model, with all its dependencies, verifying just some happy cases to double-check that everything works correctly together.

In his book, Vladimir Khorikov says that the most important parts of our code, the ones with the most domain significance, should have no dependencies. And that’s exactly what we’ve done by extracting the logic to the ListViewState type.

A note about refactoring the view model

In his book, Vladimir considered resistance to refactoring as the most important trait of a test. Quite a special one as well, as a test either has resistance to refactoring or not. It’s a binary choice. There are no trade-offs here. To do that, we should see our components as black boxes with inputs and outputs and avoid white-box testing and testing interactions as much as possible. Let’s see an example with the view model.

• Input: messages/events sent from the view.
• Output: state (to be rendered by the view) and observable behavior.

In this case, the observable behavior is the todos being saved to the database (a side effect).

Let’s imagine we want to refactor the view model by extracting some piece of functionality, the sorting algorithm, for instance, to a standalone component, like a use case. That’s perfectly reasonable. What might not be a good idea is to test that the view model sends certain messages to that use case. The use case is just an implementation detail of how the view model has decided to achieve its business goal. We can decide to split all the responsibilities of the view model into several collaborators, which should be tested separately. But when testing the view model, those collaborators (the stable dependencies) should be considered implementation details. If we decide in the future that the use case should talk to a repository for data access, that shouldn’t break the test because the inputs and outputs of the “view model black box” are the same. We should still assert:

• The final state (via public API).
• The observable behavior: the todos saved in the database or not (via database mock/spy).

Testing the view layout

After testing the view model, arguably the most important part, we still have to test that the view layer looks correct. We want to test the view layout comfortably without creating the view model and all its dependencies. We have two ways to do that

1. Container/presentational views

It was Dan Abramov who first popularized this pattern in React back in 2015 with this article. It’s fairly simple. We should split our “normal SwiftUI views” in two:

• Container view: performs the logic and side effects and communicates with the presentation view for display purposes.
• Presentational view: it displays data and notifies of view events.

In our example, it would be as simple as creating an internal Presentation type. The input would be ListViewState, and the output would be the messages sent from the view.

struct TodoListView: View {
    @StateObject private var viewModel: TodoListViewModel

    init(viewModel: @escaping @autoclosure () -> TodoListViewModel) {
        _viewModel = .init(wrappedValue: viewModel())
    }

    var body: some View {
        Presentation(input: viewModel.state, output: viewModel.send)
    }

    struct Presentation: View {
        var input: ListViewState
        var output: (ListViewState.Message.Input) -> Void

        var body: some View {
            Group {
                switch input {
                case .idle:
                    Button("Start") {
                        output(.startButtonTapped)
                    }

                case .loading:
                    Text("Loading…")

                case .error:
                    VStack {
                        Text("Oops")
                        Button("Try again") {
                            output(.tryAgainButtonTapped)
                        }
                    }

                case .loaded(let todos):
                    VStack {
                        List(todos) {
                            Text("\($0.title)")
                        }
                    }
                }
            }
        }
    }
}

Take into account that Presentation should be internal to be accessible from tests but shouldn’t be included as the public API of the container view.

The tests look like this.

final class TodoListViewTests: XCTestCase {
    func testIdle() {
        // Given
        let sut = TodoListView.Presentation(input: .idle) { _ in }

        // Then
        assertSnapshot(matching: sut, as: .image)
    }

    func testLoading() {
        // Given
        let sut = TodoListView.Presentation(input: .loading) { _ in }

        // Then
        assertSnapshot(matching: sut, as: .image)
    }

    func testLoaded() {
        // Given
        let todos: [Todo] = (0...9).map { .init(userId: $0, id: $0, title: "\($0)", completed: false) }
        let sut = TodoListView.Presentation(input: .loaded(todos)) { _ in }

        // Then
        assertSnapshot(matching: sut, as: .image)
    }

    func testError() {
        // Given
        let sut = TodoListView.Presentation(input: .error) { _ in }

        // Then
        assertSnapshot(matching: sut, as: .image)
    }
}

We can even combine the state tests with the view layout tests.

func testLoading() {
    // Given (a initial state)
    var state = ListViewState.idle

    // When (the user taps the start button)
    let effect = state.handle(message: .input(.startButtonTapped))

    // Then (both state and view layout are in the correct loading state)
    assertSnapshot(
        matching: (state, effect),
        as: .dump
    )
    assertSnapshot(
        matching: TodoListView.Presentation(input: state) { _ in },
        as: .image
    )
}

Take into account that having the Presentation type is also very convenient for previews, where we can easily have different previews configured with different states without mocking the view model.

2. Frozen view models

Because sometimes, we don’t want to create that Presentation type… To do that, we’d need to inject a “dummy” view model that does nothing and can be created with a specific initial state. This is important because the view lifecycle can call view model methods under the hood. We can always “freeze” a view model by creating an abstraction of the view model ad-hoc with a no-op implementation, but it’s much easier and ergonomic (without incurring test-induced design damage) when using architectures where we fully control the side effects, like the one described here.

Creating a “dummy reducer” that does nothing is as simple as this.

extension ViewModel {
    static func freeze(with state: State) -> ViewModel<State, Input, Feedback, Output> {
        .init(state: state, reducer: DummyReducer())
    }
}

private class DummyReducer<State, Input, Feedback, Output>: Reducer where State: Equatable {
    func reduce(
        message: Message<Input, Feedback>,
        into state: inout State
    ) -> Effect<Feedback, Output> {
        .none
    }
}

And the test looks like this.

func testLoading() {
    // Given
    let sut = TodoListView(viewModel: .freeze(state: .loading))

    // Then
    assertSnapshot(
        matching: sut,
        as: .image
    )
}

Conclusion

Thanks a lot for reaching the end of the article. It was another long read 😅.

We’ve seen different ways to test our view layer, both the view logic and also the layout.

While it’s quite clear that most of our tests should be unit tests and not UI tests, it’s unclear which approach to take.

• Should we test the view and view model together and only verify the view layout?
• Should we test the view model and view layout separately?
• Should we move the view logic outside the view model, to a value layer with no dependencies where it can easily be tested?

All approaches are perfectly valid, and depending on your project and your needs, you might find one more appropriate than the other.

• Do you have a simple app with just a few screens and developers? The first approach may be the most reasonable.
• Do you have a big app with lots of developers and screens? Consider moving the view layout testing to a different target so the main test suite remains fast.
• Do you have quite complex business logic and requirements with lots of corner cases? Extracting the logic into a value type with no dependencies could simplify testing.

As always, it depends 😄. As much as we always like to have “our way of doing things”, we should think critically, understand the app domain and requirements, and develop testing solutions that best fit our needs.

I’m really interested in knowing what you think. Do you have strong opinions about how we should test our view layer? Let me know in the comments.

Thanks!

SwiftUI Testing: a Pragmatic Approach was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Back in 2017, I wrote about the concept of “State Containers”. Six years later, I still like to build most of my apps around them, using the very same concept for the two main layers inside my apps:

• The view layer: a view model is a “view state container” modeling view-specific state and business logic.
• The domain layer: usually aggregate root models (or data repositories/services), representing the business rules and keeping the integrity and consistency around a specific bounded context (or entity) in the application.

A lot has changed since 2017, though. In 2019, Apple introduced SwiftUI. Two years later, async/await came along. While we always like to think of good architectures as those not coupled to the specifics of the framework, good architectures are also good citizens of those same frameworks and the general ecosystem. So… How have SwiftUI and async/await changed the concept of state containers in these last six years? Let’s see.

The Case Against MVVM in SwiftUI

But first, let's talk about some recent conversations in the iOS community regarding MVVM and whether it is a good fit for SwiftUI. The premise is that “the View is the view model” already, so MVVM is unnecessary.

I disagree with that premise. While it’s true that SwiftUI already has built-in primitives (in the form of property wrappers) to simplify a lot of the glue code around state observation and re-rendering, the view is just a declarative description of how the view layer looks like. A view model is so much more than that. It’s the place where the view-related business logic lives.

But let’s start with the right question. Why would we want to move code out of the view layer? Without entering in (sometimes subjective) debates about responsibilities and how software should be split, there’s something clear: unless we move the code out of the view layer, it will be complicated to unit test. But where should we put that code?

My answer to this, as most times, is “it depends”. Sometimes, we can have that logic inside a domain state container observed from different views that need the same information. Sometimes, it’s just view-specific business logic. In that case, I like to put that logic inside a view model (a view state container). Other times, it’s a matter of processing different information from different data sources and validating it to produce a view state. In all these scenarios, a view model makes a lot of sense. It makes sense because it bundles essential business logic, which is only important for that view. Moving this view-specific business logic to a domain model will likely make it less cohesive and, eventually, the wrong abstraction.

Ultimately, it’s just a matter of moving business logic out of the view in a place where it makes sense, guided by cohesion and coupling principles (or SOLID principles in general), so it can be easily testable.

Finally, I wonder why the best iOS course in the world, Standford’s CS193P, still teaches MVVM as the main presentation pattern for SwiftUI apps.

Also, Apple seems to feel the same way about not using View as the view model 🤔.

Now, get back to state containers.

The Shape of a State Container

I like to think of state containers (also "Stores" from now on) as just “black boxes” with some inputs and outputs. Specifically, a black box with some observable state that can also emit outputs.

@MainActor
protocol StoreType<State, Output>: ObservableObject where State: Equatable {
    associatedtype State
    associatedtype Output
    associatedtype StateStream: AsyncSequence where StateStream.Element == State
    associatedtype OutputStream: AsyncSequence where OutputStream.Element == Output

    var stateStream: StateStream { get }
    var outputStream: OutputStream { get }

    var state: State { get set }
}

Some important decisions in that code are worth mentioning.

• I have decided to use ObservableObject and @MainActor, so we can be sure that it can be used correctly from a SwiftUI view layer, regardless of the specific type of state: view state or domain state. We should allow enough flexibility to decide whether a view or domain layer makes sense.
• While Combine’s future is still unclear, I feel it’s safer and more future-proof to provide an API based on AsyncSequence and not couple the store with Combine in this case.

One interesting nitpick detail about choosing AsyncSequence instead of Combine is that the API is incorrect. Both StateStream and OutputStream should be streams that never fail, but there’s no way to constrain that with the AsyncSequence type. In Combine, and thanks to the recent primary associated types in protocols, it would be as easy and succinct as this:

associatedtype StateStream: Publisher<State, Never>
associatedtype OutputStream: Publisher<Output, Never>

Unlike Combine, AsyncSequence works by using async throwing functions, whose errors are always untyped by design.

mutating func next() async throws -> Self.Element?

Interestingly, Swift allows conforming to a protocol that declares a throwing function by omitting the throw keyword in the implementation. That means that the equivalent of the Never type in the Combine world would be to use a concrete implementation of AsyncSequence with a non-throwing next function:

mutating func next() async -> Self.Element?

Fortunately, we will end up using the concrete StateStream and OutputStream types, so all this won’t be a problem.

Now, it’s time to create the different flavors of that StoreType.

Different Flavors of State Size

This section brings us to the first two main flavors there are, depending on how we decide to organize our state:

• One single piece of state for the whole application (the Redux way).
• Different distributed pieces of state across the app (the Flux way).

Each one has its pros and cons. The distributed approach's main "con" is keeping data consistent across those different state containers, which can be a hard problem to solve. This problem disappears altogether by just having a single state value. That is a huge advantage. But as you might expect, there are also some big cons with the single-state value approach: performance and coupling.

The performance problem

The performance problem comes in two ways. The mutation can be expensive due to the big state value and the lack of persistent structures in Swift. But, more importantly, any change of that value will retrigger view re-renders across the app (or lots of recomputations of functions and Equatable checks). Even if SwiftUI can be smart enough not to render some view nodes, your view bodies will still be called, and you could reach performance bottlenecks. For simple apps, this might not be a problem. I know many apps using TCA, the well-known iOS architecture using the Redux approach, which are working great. But for more complex apps, you might likely run into performance issues, although you can always use a multi-store approach. For more info, take a look at Krzysztof Zabłocki’s blog post TCA Performance and Multi-Store.

The coupling problem

The coupling problem is something that a lot of libraries using the Redux pattern have. You are just coupled to the whole “AppState” value. Some libraries like TCA solve that by adding quite a lot of complexity to the architecture. Propagating state changes and messages from children states to eventually the root state comes with many “TCA DSL” and helpers that you have to learn: like using their prisms library (CasePaths) to work correctly with enums. Depending on your team and their knowledge about functional programming paradigms, the price to couple your whole app to TCA might be fine or simply too much. I still think TCA might be one of the best state management libraries available for iOS nowadays.

As for my personal preference, I prefer to use distributed state containers and bind the state as low as possible in the view hierarchy to avoid many view re-renders and body recomputations. Also, having the correct bounded contexts and modules that don’t need complex synchronization greatly helps. If you want to read more, Redux is half of a pattern is a great article.

Different Flavors of Separating Logic and Effects

Mixing everything

Let’s start with the simplest flavor, which I already talked about in this blog post, and the one most people should be used to. Having state and effects mixed together by using a Store base class that we’ll subclass (if needed).

@dynamicMemberLookup
class Store<State, Output>: StoreType where State: Equatable {
    private let stateSubject: CurrentValueSubject<State, Never>
    lazy var stateStream = stateSubject.removeDuplicates().values

    private let outputSubject: PassthroughSubject<Output, Never> = .init()
    lazy var outputStream = outputSubject.values

    init(state: State) {
        self.state = state
        stateSubject = .init(state)
    }

    @Published
    var state: State {
        didSet {
            if !Thread.isMainThread {
                // While `Store` is a main actor, we could have some non-isolated contexts where the state
                // is not changed on the main thread. This problem can be minimized by setting "Strict Concurrency Checking"
                // to "complete".
                assertionFailure("Not on main thread")
            }

            // We have traceability of the state here, being able to log it if needed.
            stateSubject.send(state)
        }
    }

    func send(output: Output) {
        outputSubject.send(output)
    }

    subscript<Value>(dynamicMember keypath: KeyPath<State, Value>) -> Value {
        state[keyPath: keypath]
    }
}

We can use it in its simplest form, just wrapping some values that we can change and observe:

enum Output { case somethingHappened }
let store = Store<Int, Output>(state: 0)

Task {
    for await state in store.stateStream {
        print("New state", state)
    }
}

Task {
    for await output in store.outputStream {
        print("New output", output)
    }
}

store.state = 1
store.send(output: .somethingHappened)

Usually, we’ll subclass that Store type, where we’ll have those state changes and outputs with the appropriate business logic.

enum NumbersViewState: Equatable {
    case idle
    case loading
    case loaded([Int])
    case error
}

enum NumbersViewOutput {
    case numbersDownloaded
}

final class NumbersViewModel: Store<NumbersViewState, NumbersViewOutput> {
    init() {
        super.init(state: .idle)
    }

    func load() async {
        state = .loading

        do {
            let numbers = try await apiClient.numbers()
            state = .loaded(numbers)

            // In this case, the output message is not adding anything meaningful, but it's just
            // an example of some "fire and forget" event that can be useful for things that, unlike state, are not persistent.
            send(output: .numbersDownloaded)
        } catch {
            state = .error
        }        
    }
}

Simple enough. We subclass the Store type and provide methods (inputs) to bundle the business logic, execute side effects, change state, and trigger output messages.

Then, we can very easily subscribe to that NumbersViewModel , both from SwiftUI (by using @StateObject or @ObservedObject), or from UIKit, by listening to StateStream and rendering the state to UIKit views correctly.

Task {
    for await state in numbersViewModel.stateStream {
        switch state {
        case .idle, .loading:
            loadingView.isHidden = false
            numbersView.isHidden = true
            errorView.isHidden = true

        case .loaded(let numbers):
            loadingView.isHidden = true
            errorView.isHidden = true
            numbersView.isHidden = false
            numbersView.render(with: numbers)

        case .error:
            loadingView.isHidden = true
            numbersView.isHidden = true
            errorView.isHidden = false
        }
    }
}

I’ve personally had great success with this first kind of flavor. While it lacks some proper encapsulation of the state (as it can be mutated from outside the concrete store subclass due to the lack of protected semantics in Swift), it’s familiar, simple, flexible, gives us accurate traceability of the state changes, and keeps them on the main thread due to @MainActor semantics. I don’t know of any concrete well-known iOS libraries using this pattern, but I know some of them in the Android world. Airbnb’s Mavericks could be the most important one. Orbit is another nice one.

But sometimes, having traceability of the state is just not enough. We want to know why that state changed and have a more constrained way of managing effects. And for that, we’ll need to complicate things a little bit.

Separating logic from effects

As I said, this is where things get much more complex (but also fun). I also talked about this flavor in the past here.

While appealing, the simplicity and flexibility of the previous approach have their drawbacks. The main one is that the freedom to manage logic, state changes, and effects however we want comes at a price. In straightforward examples like the previous one, it’s hard to see the advantage of complicating that. But with more complex business logic, teams, and requirements, having a more constrained and formal approach to dealing with state and effects is extremely useful and tends to scale better in my experience.

Let’s have some preconditions first.

• We need a way to establish the relationship between the messages, the state changes, and the effects triggered by them.
• We need to have proper encapsulation of the different message types. Wrong message encapsulation is, unfortunately, very common amongst these types of architectures. It’s not the same a public onAppear message than a private didReceiveData message.
• We need a way to model our effects correctly, leveraging async/await.

During these last few years, there have been many (too many, I’d say) flavors of these unidirectional architectures, each with its own “opinions” and “trade-offs” in the way they manage state and effects.

• Some of those are “too Combine heavy”, forcing you to couple your app to those Combine combinators.
• Some others bring the concept of “mutation” on top of the concept of “message” (or event/action) so they can differentiate between the actual “state change” and the “intention of change”. The main inspiration is Vue’s architecture, Vuex. ReactorKit is an excellent iOS library using that concept.
• Some other flavors model effects as “feedbacks”: a simple (Publisher<State>) -> Publisher<Event> function. ReactiveFeedback is another great library following this pattern.

In my experience, those flavors complicate things unnecessarily and make the code harder to understand. Especially the concept of modeling effects as “feedback packages”, as it worsens readability and obfuscates control flow. Let’s imagine that we want to understand what happens in the system whenever an action happens:

• First, we’d go to the function that processes the message and changes the state. That function is usually called a reducer.
• Then, to know what effects are triggered by the previous message, we’d have to check all the different “feedbacks” to see if that new state will trigger any of those.

That makes the code hard to understand and to build the appropriate mental model needed to change that code. Here’s a nice article explaining some of these problems in an MVI architecture.

The solution? Instead of “magically running” the effects based on the state change, let the reducer decide the effects to run.

That way, we can follow precisely the code execution from the point where a message is sent into the system to the point where all the effects have finished running.

Input message -> State changed -> Effect -> Feedback message…

The different ways of commanding effects

There are different ways that a reducer can decide the effect to run:

• We can wrap the effectful computation inside a data structure with the correct async context. Something like this

func handle(event: Event, state: inout State) -> Effect<Event> {
    switch event {
    case .onAppear:
        state = .loading
        return .task { send in
            let numbers = await apiClient.numbers()
            send(.didFinishFetching(numbers))
        }

    case .didFinishFetching(let numbers):
        state = .loaded(numbers)
        return .none
    }
}

This is how Pointfree’s TCA library works.

• Another option is to return a value representing the effect that will be interpreted later (by an effects handler).

func handle(event: Event, state: inout State) -> [Effect] {
    switch event {
    case .onAppear:
        state = .loading
        return [.downloadNumbers]

    case .didFinishFetching(let numbers):
        state = .loaded(numbers)
        return .none
    }
}

class EffectHandler {
    func handle(effect: Effect) async {
        switch effect {
        case .downloadNumbers:
            let numbers = await apiClient.numbers()
            send(.didFinishFetching(numbers))
        }
    }
}

This is how Spotify’s Mobius library works, which, IIRC, it’s based on Andy Matuschak's writing: A composable pattern for pure state machines with effects.

• The last option is to return a type conforming to a protocol that bundles the asynchronous work.

func handle(event: Event, state: inout State) -> [Effect] {
    switch event {
    case .onAppear:
        state = .loading
        return [DownloadNumbers()]

    case .didFinishFetching(let numbers):
        state = .loaded(numbers)
        return .none
    }
}


class DownloadNumbers: Effect {
    func run() async {
        let numbers = await apiClient.numbers()
        send(.didFinishFetching(numbers))
    }
}

This is how Square’s Workflow architecture works.

Each of these flavors has its pros and cons.

• The first approach has fewer “jumps” and it’s very easy to see the result of the effect and go to the feedback message .didFinishFetching. The downside is that, for complex effects, the reducer can end up big and complicated. But we can always extract that code into separate functions as needed.
• The second approach has the advantage of being able to test the reducer very easily. We can exercise the function without needing to create dependencies or mock anything. The reducer becomes the “pure layer”, which is easy to test, while the “effects handler” becomes the “impure layer”, which we may not need to test, as it should be a humble object.
• The third approach might have a more self-contained, cohesive package for a specific effect, bundling the dependencies needed without polluting the reducer with all the different effects dependencies.

I don’t have strong opinions about the best option here, to be completely honest. The second approach is the one I’ve used the most, and it has worked well for me. But sometimes, those “jumps” between the reducer function and the effect handling could be inconvenient. I recommend putting both in the same file to jump between both parts easily.

And about testing with the second approach… while we can test the reducer to see the actual effects values returned by a particular message, that test might not be the best test considering that effects are implementation details (at least from the store’s public API point of view). The actual state container “observable API” we should assert against is the tuple (state, output). Changing how we handle our effects without modifying our observable API and behavior shouldn’t break our tests.

For those reasons, I guess the first option might be my preferred option and the one I will implement in the next section.

Final implementation

Let’s now build the complete implementation of the aforementioned architecture. Feel free to copy everything into a playground and play with the result.

As I mentioned, having a correct encapsulation of the messages is important and leads to a safer and cleaner API. That’s why we have three types of messages:

• Input: .onAppear events for view stores or .downloadData commands for domain stores.
• Feedback: .didDownloadData event. These are private, sent from the effects, and cannot be sent directly from a store instance.
• Output: Fire and forget events when we need to signal information that should not persist, unlike the state.

The Effect type has two responsibilities:

• Wrapping the asynchronous work, the effect itself.
• Notifying of any output message.

struct Effect<Feedback, Output> {
    typealias Operation = (@Sendable @escaping (Feedback) async -> Void) async -> Void
    
    fileprivate let output: Output?
    fileprivate let operation: Operation

    init(
        output: Output?,
        operation: @escaping Operation
    ) {
        self.output = output
        self.operation = operation
    }
}

extension Effect {
    static var none: Self {
        return .init(output: nil) { _ in }
    }

    static func output(_ output: Output) -> Self {
        return .init(output: output) { _ in }
    }

    static func run(operation: @escaping Operation) -> Self {
        self.init(output: nil, operation: operation)
    }
}

The reducer will be the one modifying the state given a specific message and returning the correct Effect type.

@MainActor
protocol Reducer<State, Input, Feedback, Output>: AnyObject where State: Equatable {
    associatedtype State
    associatedtype Input
    associatedtype Feedback = Never
    associatedtype Output = Never

    func reduce(
        message: Message<Input, Feedback>,
        into state: inout State
    ) -> Effect<Feedback, Output>
}

With Message being just the sum type of the Input and Feedback messages.

enum Message<Input, Feedback>: Sendable where Input: Sendable, Feedback: Sendable {
    case input(Input)
    case feedback(Feedback)
}

And finally, the Store.

import Combine

@MainActor
@dynamicMemberLookup
class Store<State, Input, Feedback, Output>: ObservableObject where State: Equatable, Input: Sendable, Feedback: Sendable {
    @Published
    private(set) var state: State

    private let reducer: any Reducer<State, Input, Feedback, Output>

    private let stateSubject: CurrentValueSubject<State, Never>
    lazy var stateStream = stateSubject.removeDuplicates().values

    private let outputSubject: PassthroughSubject<Output, Never> = .init()
    lazy var outputStream = outputSubject.values

    private var tasks: [Task<Void, Never>] = []

    deinit {
        for task in tasks {
            task.cancel()
        }
    }

    init(
        state: State,
        reducer: some Reducer<State, Input, Feedback, Output>
    ) {
        self.state = state
        self.reducer = reducer
        stateSubject = .init(state)
    }

    @discardableResult
    func send(_ message: Input) -> Task<Void, Never> {
        let task = Task { await send(.input(message)) }
        tasks.append(task)
        return task
    }

    func send(_ message: Input) async {
        await send(.input(message))
    }

    private func send(_ message: Message<Input, Feedback>) async {
        guard !Task.isCancelled else { return }

        let effect = reducer.reduce(message: message, into: &state)
        stateSubject.send(state)

        if let output = effect.output {
            outputSubject.send(output)
        }

        await effect.operation { [weak self] feedback in
            guard !Task.isCancelled else { return }

            await self?.send(.feedback(feedback))
        }
    }

    subscript<Value>(dynamicMember keypath: KeyPath<State, Value>) -> Value {
        state[keyPath: keypath]
    }
}

Let’s now build the previous NumbersViewModel example by using the new architecture.

import Foundation

final class APIClient {
    func numbers() async throws -> [Int] {
        try await Task.sleep(nanoseconds: 1 * NSEC_PER_SEC)
        return [1, 2, 3]
    }
}

final class NumbersViewReducer: Reducer {
    enum State: Equatable {
        case idle
        case loading
        case loaded([Int])
        case error
    }

    enum Input {
        case onAppear
    }

    enum Feedback {
        case numbersDownloaded(Result<[Int], Error>)
    }

    enum Output {
        case numbersDownloaded
    }

    private let apiClient = APIClient()

    func reduce(message: Message<Input, Feedback>, into state: inout State) -> Effect<Feedback, Output> {
        switch message {
        case .input(.onAppear):
            state = .loading
            return .run { [weak self] send in
                guard let self else { return }

                do {
                    let numbers = try await apiClient.numbers()
                    await send(.numbersDownloaded(.success(numbers)))
                } catch {
                    await send(.numbersDownloaded(.failure(error)))
                }
            }

        case .feedback(.numbersDownloaded(.success(let values))):
            state = .loaded(values)
            return .output(.numbersDownloaded)

        case .feedback(.numbersDownloaded(.failure)):
            state = .error
            return .none
        }
    }
}

import SwiftUI

struct NumbersListView: View {
    @StateObject private var viewModel = Store(
        state: NumbersViewReducer.State.idle,
        reducer: NumbersViewReducer()
    )

    var body: some View {
        Group {
            switch viewModel.state {
            case .idle, .loading:
                Text("…")

            case .loaded(let values):
                List(values, id: \.self) { value in
                    Text("\(value)")
                }

            case .error:
                Text("Some error happened")
            }
        }.onAppear {
            viewModel.send(.onAppear)
        }
    }
}

Conclusion

Thanks a lot for reaching the end of the article. It was a long (and hopefully interesting) read.

During these last years, we’ve had an explosion of state management libraries. We’ve seen how unidirectional architectures have taken over the Mobile space, especially alongside new UI declarative frameworks like SwiftUI (and Jetpack Compose on Android), where they perfectly fit.

But not only SwiftUI… async/await has also made a big impact on how we develop our apps and handle concurrency and side effects, which has impacted many of the new architectures that have emerged during these last years.

All the separation of state management and effects has emerged a lot of new functional paradigms within the iOS community, with many people already using TCA as their default architecture for any new iOS project with SwiftUI. This is great news and shows the maturity of the iOS ecosystem at this point.

While Swift will keep evolving, I don’t particularly foresee any major changes in the coming years that will dramatically change how we develop applications, or at least in a way that can impact state management libraries so drastically, as has happened recently.

Well… Maybe “Swift Data” to replace Core Data… we’ll see in a few months at WWDC23.

The Many Flavors of Unidirectional Architectures in Swift was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Turning JSON into actual Swift types is something most apps have to deal with eventually. At the beginning of Swift, Apple was not opinionated about how we should approach that task. So people came up with a bunch of different libraries to do so. Some of them are quite esoteric. Fortunately, Apple came up with its own first-party solution, Codable.

Turning JSON into Swift types can be as easy as conforming those types to the Codable protocol. You might not need to do anything else. The compiler will do its magic and synthesize the appropriate parsing code for you. That’s lovely. There’s no better code than the one you don’t have to write. Sometimes, the “parsing code” you have to write is minimal, providing a CodingKeys enum with the appropriate mapping between your type property names and the JSON keys.

Unfortunately, that’s where the magic ends. The honeymoon with Codable tends to end pretty soon. The more complex, statically safe, and correct our types are, the more impedance we have between the JSON and our types, and the more likely it is that we’ll end up writing quite a lot of complex parsing code inside init(from decoder:) throws.

I still remember my days writing Objective-C. Swift has definitely made me a better developer. And one of the main reasons is that I now tend to think much more deeply about my data, trying to encapsulate all the correct semantics and invariants into that domain model. I tend to think about data first. Objective-C lacked a lot in that regard. Luckily, Swift has all the proper primitives to model our domain correctly: optionals, generics, powerful enums, values types…

While it can be tempting to couple our models to the JSON shape and let Codable do its magic to avoid boilerplate, I do think we should think about the correct data first, and then interpret the JSON correctly via the (JSON) -> Model function. The inherently dynamic nature of JSON leaking into our domain model will likely make it “worse”.

The JSON -> Model function

I tend to see this function as a kind of anticorruption layer. The sooner we validate the JSON and turn it into the correct types inside our domain, the better. That validation can vary greatly depending on how much control we have over the API.

• On one side of the spectrum, we have a specifically-tuned API via a Backend for Frontend, where the schema contract has been thoroughly thought out and agreed upon amongst Mobile and API developers. Both API and the Mobile app will evolve hand in hand.
• On the other side, we need to communicate with a third-party API we don’t control.

On either side of the spectrum, the custom parsing/validation code we end up writing is very different. The third-party API will likely require more “validation” to fit our model.

We have two places to put that parsing code:

1. Use Codable and implement init(from decoder:) throws.
2. Use some kind of intermediate “data layer” model (let’s call this DTO — Data Transfer Object) and have an extra function (DTO) -> Model throws for that transformation.

I guess the word DTO doesn’t feel as idiomatic in Swift as it might be in other languages like Java or C#. And while I agree that the idiomatic way to approach parsing in Swift is to go the Codable path, it is good sometimes to consider other alternatives and see if they solve the problem better (or worse).

This article doesn’t try to convince anyone that the DTO approach is a better one (in fact, I don’t think it is for a lot of cases). It only tries to show a “different approach”. A new tool and alternative to that parsing code we are writing inside init(from decoder:) throws. Sometimes, it might simplify things. Some other times, it may not.

My humble opinion is that writing custom Codable code is not only boilerplate, but also hard. There are quite a few new “idioms” to learn about keyed containers, unkeyed ones, coding keys, etc.

Any time we have to deal with some “special” case (such as not failing if an element of an array fails to decode, or unknown cases for enums), we end up having to implement init(from decoder:) throws and writing quite a gnarly parsing code.

While some of that pain can be eased by using property wrappers, the complexity is still there. We only moved it (even coupling ourselves to a third-party library along the way).

A Richer Domain

Let’s suppose we are trying to transform the following JSON into the correct type.

let json = """
{
    "name": "Luis",
    "twitter": "@luisrecuenco"
}
"""

Our first approach could be as simple as this:

struct Person: Decodable {
    var name: String
    var twitter: String
}

We can even have twitter: String? and be a little more flexible if the twitter key is not always present.

But wouldn’t it be great to have a Twitter type?

First, to validate the username handler correctly and second, to encapsulate all future business logic related to Twitter (I wrote a lot more about this and refinement types in general in a previous article called Value integrity in Swift). Let’s change the code to do that.

struct Person: Decodable {
    var name: String
    var twitter: Twitter
}

struct Twitter: Decodable {
    var handler: String
}

This doesn’t work, as expected. The Twitter type expects to be decoded by a keyed container with the handler key, but we get a single-value container.

Fortunately, the solution is as easy as making the Twitter type conform to RawRepresentable. Let’s do that.

struct Twitter: RawRepresentable, Decodable {
    var rawValue: String

    init?(rawValue: String) {
        self.rawValue = rawValue
    }
}

This is “ok”. We are forced to couple our Twitter type with RawRepresentable, so we are forced to use a specific property name, expose rawValue with the same visibility as the Twitter type, etc.

Let’s now try to use validation. If we receive a Twitter handler without the @, we fail.

struct Person: Decodable {
    var name: String
    var twitter: Twitter?
}

struct Twitter: RawRepresentable, Decodable {
    var rawValue: String

    init?(rawValue: String) {
        guard rawValue.first == "@" else { return nil }
        self.rawValue = rawValue
    }
}

This code works as long as:

• We receive a correct Twitter handler with @.
• We don’t receive any Twitter on the JSON.

But, as soon as we receive an invalid Twitter handler (so the validation fails), the whole decoding process fails as well. This forces us to implement the parsing code manually:

init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)
    name = try container.decode(String.self, forKey: .name)
    twitter = try container.decodeIfPresent(String.self, forKey: .twitter).flatMap(Twitter.init)
}

This kind of process happens a lot with Codable.

Coupling our domain with Codable damages refactoring. It’s very likely that any refactor in our domain breaks the underlying decoding without the compiler telling anything (having to rely on tests to catch those issues).

Those new types, as long as they conform to Decodable, will make the compiler synthesize “new decoding magic”, which will likely crash at runtime.

While implementing init(from decoder:) throws fixes that issue (the compiler will now force all properties to be correctly set), sometimes it’s better to have a proper separation between “the schema types” and the “domain types”.

Let’s now take a look at another alternative, where Person.DTO is our “schema type”, matching the JSON, whereas Person and Twitter are plain structs.

struct Person {
    var name: String
    var twitter: Twitter?
}

struct Twitter {
    var handler: String

    init?(handler: String) {
        guard handler.first == "@" else { return nil }
        self.handler = handler
    }
}

extension Person {
    struct DTO: Decodable {
        var name: String
        var twitter: String?
    }

    init(from dto: DTO) {
        name = dto.name
        twitter = dto.twitter.flatMap(Twitter.init)
    }
}

When we change the shape of our domain, the compiler will force us to update the init(from dto:) function, which is exactly what we want. As long as Person.DTO structure doesn’t change (keeping the JSON schema contract), we are good, and the compiler will help with refactoring.

But using a DTO is not always better. As always, it depends. So let’s analyze both approaches a little bit more thoroughly.

Comparing the Codable vs. DTO approaches

The other day I was watching this talk by Ben Scheirman. It’s a great talk, you should watch it. In that talk, Ben presents three different use cases, and we’ll use those to see how the DTO approach compares.

1. Nested JSON to flatten type

The goal is to turn the following JSON payload into the Beer type.

{
    "id": 123,
    "name": "Endeavor",
    "brewery": {
        "id": "sa001",
        "name": "Saint arnold"
    }
}

struct Beer {
    var id: Int
    var name: String
    var breweryId: String
    var breweryName: String
}

First, let’s have the Codable approach (the one shown in the talk):

let json = """
{
    "id": 123,
    "name": "Endeavor",
    "brewery": {
        "id": "sa001",
        "name": "Saint arnold"
    }
}
""".data(using: .utf8)!

struct Beer: Decodable {
    var id: Int
    var name: String
    var breweryId: String
    var breweryName: String

    enum CodingKeys: String, CodingKey {
        case id
        case name
        case brewery
    }

    enum BreweryCodingKeys: String, CodingKey {
        case id
        case name
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        id = try container.decode(Int.self, forKey: .id)
        name = try container.decode(String.self, forKey: .name)

        let breweryContainer = try container.nestedContainer(keyedBy: BreweryCodingKeys.self, forKey: .brewery)
        breweryId = try breweryContainer.decode(String.self, forKey: .id)
        breweryName = try breweryContainer.decode(String.self, forKey: .name)
    }
}

let beer = try! JSONDecoder().decode(Beer.self, from: json)
dump(beer)

Before digging into the DTO approach, let’s have some minimal infrastructure code to simplify things. We’ll define what an object that can be decoded from a DTO looks like and how to decode it easily.

protocol DecodableFromDTO {
    associatedtype DTO: Decodable
    init(from dto: DTO) throws
}

extension JSONDecoder {
    func decode<T>(_ type: T.Type, from data: Data) throws -> T where T : DecodableFromDTO {
        try T(from: decode(T.DTO.self, from: data))
    }
}

With that in place, we can have this:

let json = """
{
    "id": 123,
    "name": "Endeavor",
    "brewery": {
        "id": "sa001",
        "name": "Saint arnold"
    }
}
""".data(using: .utf8)!

struct Beer {
    var id: Int
    var name: String
    var breweryId: String
    var breweryName: String
}

extension Beer: DecodableFromDTO {
    struct DTO: Decodable {
        struct Brewery: Decodable {
            var id: String
            var name: String
        }
        var id: Int
        var name: String
        var brewery: Brewery
    }

    init(from dto: DTO) throws {
        id = dto.id
        name = dto.name
        breweryId = dto.brewery.id
        breweryName = dto.brewery.name
    }
}

let beer = try! JSONDecoder().decode(Beer.self, from: json)
dump(beer)

I guess both approaches are quite similar. Let’s first analyze the Signal-to-noise ratio, understanding noise as all the parsing lines of code.

• Codable SNR = 41/20 ~ 48% of noise
• DTO SNR = 39/18 ~ 46% of noise

As we can see, the noise we get is quite similar.

Another interesting thing to consider is the impact of changes. How many places do we have to update for any change in the JSON/model?

• Codable: update CodingKeys and init(from decoder:) throws.
• DTO: update DTO struct and init(from dto:) throws.

Again, similar results. We can interpret this in two ways:

• The DTO approach is not worth it, as we are not really getting many advantages from it.
• The DTO approach, which usually is considered as adding more boilerplate, extra DTO type, etc, is not really much worse than the Codable approach.

Deciding which code is simpler is quite subjective (as many things in programming, unfortunately). Some people might write parsing code inside init(from decoder:) throws very naturally, and Codable containers are second-nature for them.

Some other people might find the extra DTO + (DTO) -> Model function as a simpler approach. I tend to favor the DTO approach slightly in this case. As I mentioned previously, having the schema types decoupled from my domain types allows me to evolve my domain more safely and rapidly.

2. Flat JSON to nested type

The goal is to turn the following JSON payload into the Beer and Brewery types:

{
    "id": 123,
    "name": "Endeavor",
    "brewery_id": "sa001",
    "brewery_name": "Saint Arnold"
}

struct Beer {
    var id: Int
    var name: String
    var brewery: Brewery
}

struct Brewery {
    var id: String
    var name: String
}

As before, let’s go with the Codable approach first:

let json = """
 {
    "id": 123,
    "name": "Endeavor",
    "brewery_id": "sa001",
    "brewery_name": "Saint Arnold"
}
""".data(using: .utf8)!

struct Beer: Decodable {
    var id: Int
    var name: String
    var brewery: Brewery

    enum CodingKeys: String, CodingKey {
        case id
        case name
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        id = try container.decode(Int.self, forKey: .id)
        name = try container.decode(String.self, forKey: .name)
        brewery = try Brewery(from: decoder)
    }
}

struct Brewery: Decodable {
    var id: String
    var name: String

    enum CodingKeys: String, CodingKey {
        case id = "brewery_id"
        case name = "brewery_name"
    }
}

let beer = try! JSONDecoder().decode(Beer.self, from: json)
dump(beer)

Now, the DTO-based approach:

let json = """
 {
    "id": 123,
    "name": "Endeavor",
    "brewery_id": "sa001",
    "brewery_name": "Saint Arnold"
}
""".data(using: .utf8)!

struct Beer {
    var id: Int
    var name: String
    var brewery: Brewery
}

struct Brewery {
    var id: String
    var name: String
}

extension Beer: DecodableFromDTO {
    struct DTO: Decodable {
        var id: Int
        var name: String
        var brewery_id: String
        var brewery_name: String
    }

    init(from dto: DTO) {
        id = dto.id
        name = dto.name
        brewery = Brewery(id: dto.brewery_id, name: dto.brewery_name)
    }
}

let beer = try! JSONDecoder().decode(Beer.self, from: json)
dump(beer)

SNR:

• Codable SNR = 39/16 ~ 41% of noise
• DTO SNR = 37/14 ~ 37% of noise

Impact of changes:

• Codable: update Beer‘s CodingKeys and init(from decoder:) throws. Update Brewery‘s CodingKeys and maybe, implement init(from decoder:) throws there.
• DTO: update DTO struct and init(from dto:) throws.

The DTO approach seems slightly better, especially because the changes we’d have to make in case of JSON/model updates are a bit better scoped and less scattered. But the advantages are minor, really.

3. Heterogeneous arrays

Let’s now have a much more interesting example. The goal is to turn the following JSON payload into the Feed type.

{
    "items": [
        {
            "type": "text",
            "id": 55,
            "text": "This is a text feed item"
        },
        {
            "type": "image",
            "id": 56,
            "image_url": "http://placekitten.com/200/300"
        }
    ]
}

struct Feed {
    let items: [FeedItem]
}

class FeedItem {
    let id: Int
}

class TextFeedItem: FeedItem {
    let text: String
}

class ImageFeedItem: FeedItem {
    let imageUrl: URL
}

Let’s go with the Codable approach first.

let json = """
{
    "items": [
        {
            "type": "text",
            "id": 55,
            "text": "This is a text feed item"
        },
        {
            "type": "image",
            "id": 56,
            "image_url": "http://placekitten.com/200/300"
        }
    ]
}
""".data(using: .utf8)!

struct AnyCodingKey: CodingKey {
    let stringValue: String

    init?(stringValue: String) {
        self.stringValue = stringValue
    }

    var intValue: Int?

    init?(intValue: Int) {
        fatalError()
    }
}

extension AnyCodingKey: ExpressibleByStringLiteral {
    init(stringLiteral value: StringLiteralType) {
        self.init(stringValue: value)!
    }
}

class FeedItem: Decodable {
    let id: Int

    init(id: Int) {
        self.id = id
    }
}

class TextFeedItem: FeedItem {
    let text: String

    init(text: String, id: Int) {
        self.text = text
        super.init(id: id)
    }

    enum CodingKeys: String, CodingKey {
        case text
    }

    required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        text = try container.decode(String.self, forKey: .text)
        try super.init(from: decoder)
    }
}

class ImageFeedItem: FeedItem {
    let url: URL

    init(url: URL, id: Int) {
        self.url = url
        super.init(id: id)
    }

    enum CodingKeys: String, CodingKey {
        case imageUrl = "image_url"
    }

    required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        url = try container.decode(URL.self, forKey: .imageUrl)
        try super.init(from: decoder)
    }
}

struct Feed: Decodable {
    let items: [FeedItem]

    enum CodingKeys: String, CodingKey {
        case items
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        var itemsContainer = try container.nestedUnkeyedContainer(forKey: .items)
        var itemsContainerCopy = itemsContainer
        var items: [FeedItem] = []
        while !itemsContainer.isAtEnd {
            let typeContainer = try itemsContainer.nestedContainer(keyedBy: AnyCodingKey.self)
            let type = try typeContainer.decode(String.self, forKey: "type")
            let feedItem: FeedItem
            switch type {
            case "text":
                feedItem = try itemsContainerCopy.decode(TextFeedItem.self)
            case "image":
                feedItem = try itemsContainerCopy.decode(ImageFeedItem.self)
            default:
                fatalError()
            }
            items.append(feedItem)
        }
        self.items = items
    }
}

let feed = try! JSONDecoder().decode(Feed.self, from: json)
dump(feed)

In this case, the DTO approach is trickier. In the previous examples, the JSON schema contract was clear, and we could create the correct DTO type that matched that schema.

But now, the schema depends on the type key. If "type" = "text", we get a different payload than when "type" = "image". To fit this dynamic nature into our DTO-based approach, we are going to leverage a JSON type I implemented in a previous article called Statically-typed JSON payload in Swift.

enum JSON: Codable {
    case int(Int)
    case string(String)
    case bool(Bool)
    case double(Double)
    case array([JSON])
    case dictionary([String: JSON])

    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        switch self {
        case .int(let int): try container.encode(int)
        case .double(let double): try container.encode(double)
        case .string(let string): try container.encode(string)
        case .bool(let bool): try container.encode(bool)
        case .array(let array): try container.encode(array)
        case .dictionary(let dictionary): try container.encode(dictionary)
        }
    }

    init(from decoder: Decoder) throws {
        var container = try decoder.singleValueContainer()
        do { self = .int(try container.decode(Int.self)) } catch {
            do { self = .string(try container.decode(String.self)) } catch {
                do { self = .bool(try container.decode(Bool.self)) } catch {
                    do { self = .double(try container.decode(Double.self)) } catch {
                        do { self = .array(try container.decode([JSON].self)) } catch {
                            self = .dictionary(try container.decode([String: JSON].self))
                        }
                    }
                }
            }
        }
    }
}

extension JSON {
    func decode<T>(_ type: T.Type) throws -> T where T: Decodable {
        try JSONDecoder().decode(type, from: JSONEncoder().encode(self))
    }
}

With that JSON type in place, let’s implement our full DTO-based parsing.

let json = """
{
    "items": [
        {
            "type": "text",
            "id": 55,
            "text": "This is a text feed item"
        },
        {
            "type": "image",
            "id": 56,
            "image_url": "http://placekitten.com/200/300"
        }
    ]
}
""".data(using: .utf8)!

class FeedItem {
    let id: Int

    init(id: Int) {
        self.id = id
    }
}

class TextFeedItem: FeedItem {
    let text: String

    init(text: String, id: Int) {
        self.text = text
        super.init(id: id)
    }
}

class ImageFeedItem: FeedItem {
    let url: URL

    init(url: URL, id: Int) {
        self.url = url
        super.init(id: id)
    }
}

struct Feed {
    let items: [FeedItem]
}

extension Feed: DecodableFromDTO {
    struct DTO: Decodable {
        var items: [JSON]

        struct Text: Decodable {
            var id: Int
            var text: String
        }

        struct Image: Decodable {
            var id: Int
            var image_url: URL
        }

        struct DecodingError: Error {}
    }

    init(from dto: DTO) throws {
        items = try dto.items.map { json in
            guard case .dictionary(let item) = json, case .string(let type) = item["type"] else { throw DTO.DecodingError() }
            switch type {
            case "text":
                let textDTO = try json.decode(DTO.Text.self)
                return TextFeedItem(text: textDTO.text, id: textDTO.id)

            case "image":
                let imageDTO = try json.decode(DTO.Image.self)
                return ImageFeedItem(url: imageDTO.image_url, id: imageDTO.id)

            default:
                throw DTO.DecodingError()
            }
        }
    }
}

let feed = try! JSONDecoder().decode(Feed.self, from: json)
dump(feed)

SNR:

• Codable SNR = 95/45 ~ 47% of noise.
• DTO SNR = 85/35 ~ 41% of noise.

Impact of changes:

• Codable: update TextFeedItem, ImageFeedItem, and Feed’s CodingKeys and init(from decoder:) throws (and maybe FeedItem as well).
• DTO: the JSON type adapts to any kind of JSON shape, so we only have to update Feed.DTO.Text, Feed.DTO.Image and init(from dto:) throws.

As before, it seems that the impact of changes is better scoped in the DTO version. But in this case, the main advantage to me is that the code inside init(from dto:) throws is much simpler than the code inside init(from decoder:) throws.

Mix and match

In case we need to combine DecodableFromDTO objects with Decodable objects, we can use the DecodeFromDTO property wrapper for that.

let json = """
{
    "name": "Luis",
    "beer": {
        "id": 123,
        "name": "Endeavor",
        "brewery": {
            "id": "sa001",
            "name": "Saint arnold"
        }
    }
}
""".data(using: .utf8)!

@propertyWrapper
struct DecodeFromDTO<T>: Decodable where T: DecodableFromDTO {
    var wrappedValue: T

    init(from decoder: Decoder) throws {
        wrappedValue = try T(from: T.DTO(from: decoder))
    }
}

struct Person: Decodable {
    var name: String
    @DecodeFromDTO var beer: Beer
}

let person = try! JSONDecoder().decode(Person.self, from: json)
dump(person)

Conclusion

While neither the SNR nor the impact of changes have been objectively better or different in any of the approaches, I still think separating the schema types from the domain types is a good practice that scales better, leads to richer types, and facilitates refactoring.

Also, the declarative nature of the DTO approach, with its structure matching the JSON schema (which could be automated by tools like Quicktype), feels much nicer to me than a lot of complex imperative parsing code. But at the end of the day, this is just a tool, and we should use the right tool for the job.

Parsing in Swift: a DTO-based Approach was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.