DEV Community: Cristian Rojas

You Don't Need MVVM to Test SwiftUI

Cristian Rojas — Thu, 02 Apr 2026 10:50:07 +0000

protocol MovieLoader {
    func load() async throws -> [Movie]
}

struct MovieList: View {
    @State var movies = [Movie]()
    let loader: MovieLoader
    var body: some View {
        List(movies, rowContent: MovieRow.init)
            .task { await load() }
    }

    func load() async {
        movies = (try? await loader.load()) ?? []
    }
}

func test_load_loadsMovies() async {
    let expected = [anyMovie()]
    let stubbed = StubMovieLoader(stubs: expected)
    let sut = MovieList(loader: stubbed)
    await sut.load()
    XCTAssertEqual(sut.movies, expected)
}

If you try to run this test as-is, it will fail.

Thehe reason is that @State in a SwiftUI view only connects to an in-memory store if the view has been mounted into a real view hierarchy. The most common workaround is to move the logic into an @Observable.

@Observable class MovieListViewModel {
    var movies = [Movie]()
    let loader: MovieLoader
    init(loader: MovieLoader = RemoteMovieLoader()) { ... }
    func load() async {
        movies = (try? await loader.load()) ?? []
    }
}

struct MovieList: View {
    @State var vm = MovieListViewModel()
    var body: some View {
        List(vm.movies, content: MovieRow.init)
            .task { await vm.load() }
    }
}

func test_load_loadsMovies() async {
    let expected = [anyMovie()]
    let stubbed = StubMovieLoader(stubs: expected)
    let sut = MovieListViewModel(loader: stubbed)
    await sut.load()
    XCTAssertEqual(sut.movies, expected)
}

This pattern, widely used and considered a de facto standard, comes with some drawbacks:

We abandon value types purely for the sake of testability.
We introduce reference types with all their baggage (lifecycle management and potential leaks) into a framework designed to be as value type-oriented as possible.
We keep mixing UI state logic (how and when it updates) with the storage itself, despite introducing an extra object to abstract it — even though stateless MVVM implementations exist even in UIKit.

The solution, curiously, has been in SwiftUI from the start.
In this article I'd like to present an alternative, building on the work of Lazar Otasevic.

Binding

@State is not testable outside a view hierarchy, but @Binding offers a way to expose state for testing — something that seems to have gone largely unnoticed by the community.
Conceptually, a @Binding can be understood as a simple pair of closures (get and set):

struct Binding<Value> {
    let get: () -> Value
    let set: (Value) -> Void
}

Which makes a view using @Binding fully testable:

struct MovieList: View {
    @Binding var movies: [Movie]
    let loader: MovieLoader
    var body: some View {
        List(movies, rowContent: MovieRow.init)
            .task { await load() }
    }

    func load() async {
        movies = (try? await loader.load()) ?? []
    }
}

func test_load_loadsMovies() async {
    var storage = [Movie]()
    let binding = Binding(get: { storage }, set: { storage = $0 })
    let expected = [anyMovie()]
    let stubLoader = StubMovieLoader(stubs: expected)
    let sut = MovieList(movies: binding, loader: stubLoader)
    await sut.load()
    XCTAssertEqual(storage, expected)
}

The view no longer owns its state, becoming a purely functional component that delegates persistence to its ancestor.

SwiftUI is already a state engine; @Binding is simply the wire that lets us connect that engine to our unit tests.

We can build some helper utilities. Analogous to Apple's static Binding.constant(), we can have a Binding.variable():

extension Binding {
    static func variable(_ initialValue: Value) -> Self {
        var copy = initialValue
        return Binding(get: { copy }, set: { copy = $0 })
    }
}

func test_load_loadsMovies() async {
    let expected = [anyMovie()]
    let stubLoader = StubMovieLoader(stubs: expected)
    let (sut, movies) = makeSUT(loader: stubLoader)
    await sut.load()
    XCTAssertEqual(movies(), expected)
}

func makeSUT(movies: [Movie] = [], loader: MovieLoader) -> (MovieList, () -> [Movie]) {
    let movies = Binding.variable(movies)
    let sut = MovieList(movies: movies, loader: loader)
    return (sut, { movies.wrappedValue })
}

Binding.variable doesn't create a special container like @State ; it simply captures a local variable via closures. When the view writes:

movies = newValue

...it's actually executing the set closure, which mutates copy.

And when you read in the test:

movies.wrappedValue

...you're executing the get closure, which returns that same copy. The view and the test share the same storage, since both use the captured variable.

The view's state logic is fully testable. Whoever builds it needs to provide it with its state:

import Movies   
import MoviesUI

// Composition Root
struct MovieListComposer: View {
    @State var movies = [Movie]()
    let loader: MovieLoader
    var body: some View {
        MovieList(movies: $movies, loader: loader)
    }
}

We can also create a generic wrapper for views using this pattern:

struct Host<Initial, Content: View>: View {
    typealias StateCapability = Binding<Initial>

    @State var state: Initial
    let content: (StateCapability) -> Content

    init(
        _ initial: Initial, 
        @ViewBuilder content: @escaping (StateCapability) -> Content
    ) {
        self._state = State(initialValue: initial)
        self.content = content
    }
    var body: some View {
        content($state)
    }
}

struct SomeApp: App {
    var body: some Scene {
        WindowGroup {
            Host([Movie]()) {
                MovieList(movies: $0)
            }
        }
    }
}

Conclusions and Considerations

This pattern enables a high level of testability while preserving the simplicity of SwiftUI's declarative system, without intermediate layers.

You don't need a @observable ViewModel to test state logic in SwiftUI if you don't need idenitity for your specific use case (most cases).
@State has storage that is inaccessible outside the SwiftUI runtime. @Binding has no storage of its own and only represents access to external storage via closures.
By using @Binding, we keep the view as a lightweight, testable struct, without forcing the creation of a class just to satisfy the test runner.
You can still use @Observable for state, since @Binding is the communication interface, not the storage. This decouples the view from how the data is stored (whether in @State , an @Observable, or a property wrapper from CoreData/SwiftData/etc.).
Encapsulating logic in a dedicated struct for reuse across views and a more decoupled architecture is entirely possible. For more details, I recommend the the "True Logic: Stateless and Pure" section of this article from Lazar Otasevic. I've also published an example project that can serve as a reference: OnlyGoodMovies on how to architecture a project around this design pattern.

Reducing Boilerplate in UIKit State Binding

Cristian Rojas — Sun, 15 Jun 2025 22:16:44 +0000

tl;dr

Tired of writing isHidden = true three times every time you bind view state?
This article walks through a small refactor to reduce repetitive UIKit state-binding boilerplate — making your code clearer and easier to maintain.

Introduction

Modeling the state of asynchronous screens using an enum with associated values is a useful and common pattern.

It collapses multiple sources of truth into a single state object, eliminating optionals and reducing complexity:

class SomeScreen {
    var data: SomeData?
    var isLoading: Bool = false
    var errorMessage: String?
}

enum State<T> {
    case loading
    case success(T)
    case error(String)
}

class SomeScreen {
    var state = State<SomeData> = .loading
}

This is particularly useful in SwiftUI where view is a function of state and no bindings are needed:

struct SomeScreen: View {
    @State var state = State<SomeData> = .loading

    var body: some View {
        switch state {
            case .loading: ProgressView()
            case .success(let data): SuccessView(data: data)
            case .error(let error): ErrorView(message: error)
        }
    }
}

In UIKit codebases, it's common to see the pattern used as follows:

final class SomeViewController: UIViewController {
    lazy var indicator  = LoadingView()
    lazy var someView   = SomeView()
    lazy var errorView  = ErrorView()

    var state = State.loading {
        didSet {
            switch state {
                case .loading:
                    indicator.isHidden = false
                    someView.isHidden = true
                    errorView.isHidden = true
                case .success(let data):
                    indicator.isHidden = true
                    someView.isHidden = false
                    errorView.isHidden = true
                    someView.update(with: data)
                case .error:
                    indicator.isHidden = true
                    someView.isHidden = true
                    errorView.isHidden = false
            }
        }
    }
}

However, this is not only verbose but error prone as we may get bindings mixed up:

...
switch state {
    case .loading:
        indicator.isHidden = false
        someView.isHidden = false ❌
        ...
}

And because each screen following this pattern repeats the same snippet, it quickly becomes boilerplate.

Thankfully, Swift, being the expressive language that it is, allows for some customization that can greatly reduce this boilerplate.

Readable view visibility

By nature, you can name any bool in two opposite ways.

When it comes to visibility you could have a bool that reads:

var isHidden: Bool { ... }

But depending on your preferences you might prefer expressing visibility using the opposite wording:

var isVisible: Bool { ... }

When expressing logic in code, affirmative conditions are usually easier to parse than their negated counterparts:

Although isHidden isn’t grammatically a negative, it behaves like one semantically. Assigning someView.isHidden = false forces your brain into a small mental rephrasing:

The view is not hidden… which means it is visible.

An unnecessary flip compared to:

The view is visible.

isVisible = true maps directly to "this view should be shown", whereas isHidden = false adds a small mental detour.

So in the context of view visibility, isVisible better reflects intent and simplifies state binding.

For example, instead of scattering multiple conditionals across states:

case .loading:
    indicator.isHidden = false
case .success:
    indicator.isHidden = true
case .error:
    indicator.isHidden = true

We can reduce the noise with a single line:

indicator.isVisible = state.isLoading

You can introduce this semantic clarity by extending UIView with a computed property that inverts isHidden:

extension UIView {
    var isVisible: Bool {
        get { !isHidden }
        set { isHidden = !newValue }
    }
}

State helpers

Now that we have a clearer boolean, we'll need to add some helpers to the State model so we can bind the isVisible property easily:

extension State {
    var isLoading: Bool { self == .loading }

    var data: T? {
        switch self {
            case .success(let data): return data
            default: return nil
        }
    }

    var isSuccess: Bool { data != nil }

    var isError: Bool {
        switch self {
            case .error: return true
            default: return false
        }
    }
}

Usage

final class SomeViewController {
    lazy var indicator  = LoadingView()
    lazy var someView   = SomeView()
    lazy var errorView  = ErrorView()

    var state = State<Model>.loading {
        didSet { bindUI() }
    }

    func bindUI() {
        indicator.isVisible = state.isLoading
        someView.isVisible = state.isSuccess
        errorView.isVisible = state.isError
        state.data.map(someView.update)
    }
}

Bonus

When dealing with completion-based async code, it's common to use Swift’s Result type to model success or failure outcomes.

Then the controller / viewModel / whatever, maps the result into a state value:

class SomeViewController {
    ...
    func load() {
        loader.load { result in
            switch result {
                case .success(let data) : self.state = .success(data)
                case .failure(let error): self.state = .error(error)
            }
        }
    }
}

And again, since this block tends to repeat across screens, it’s boilerplate.

It can be refactored out into a custom initializer:

extension State {
    init(result: Result<T, Error>) {
        switch result {
            case .success(let data): self = .success(data)
            case .failure(let error): self = .error(error.localizedDescription)
        }
    }
}

Then in the controller (weak self omitted for brevity):

class SomeViewController {
    ...
    func load() {
        loader.load { self.state = .init(result: $0) }
    }
}

Conclusion

All code is buggy. It stands to reason, therefore, that the more code you have to write the buggier your apps will be. — Rich Harris

These small changes not only reduce repetition and bugs, they also make your ViewControllers more declarative and less error prone.

In a time where UIKit is still very much alive in many codebases, small improvements like this can make day-to-day development a bit cleaner and more maintainable.

Feedback

We all need people who will give us feedback. That’s how we improve. — Bill Gates

Any feedback — technical, editorial, or otherwise — is more than welcome.