Select Page

Last week, I had an interesting conversation with a reader, let’s call him John, about the Model-View-ViewModel pattern. The questions John asked me show that developers new to MVVM often miss or overlook the more profound benefits the pattern brings to the table. In this post, I’d like to share with you the most important insights of our conversation.

Creating a View Model

I believe John read my free ebook and came across the chapter in which I discuss the MVVM pattern. The first question he had for me was the most obvious one. He shared with me the implementation of a view controller that looked something like this. For confidentiality reasons, I won’t be sharing John’s implementation.

import UIKit

class ViewController: UIViewController {

    // MARK: - Properties

    private var notes: [Note] = []

    // MARK: -

    private lazy var apiManager = APIManager()

    // MARK: - View Life Cycle

    override func viewDidLoad() {
        super.viewDidLoad()

        // Fetch Notes
        apiManager.fetchNotes { [unowned self] (notes, error) in
            if error != nil {
                // Error Handling
                ...
                
            } else {
                // Update Notes
                self.notes = notes

                // Update View
                self.updateView()
            }
        }
    }

    // MARK: - View Methods

    fileprivate func setupView() { ... }

    fileprivate func updateView() { ... }

}

This may look familiar if you’ve been using the Model-View-Controller pattern to build Swift applications. The moment the view controller has finished loading its view, it performs a network request. It delegates this task to the APIManager class, which is a good start to reduce the responsibilities of the view controller.

John then showed me how we planned to implement the MVVM pattern. This is what that looked liked. I’m keeping the example as simple as possible.

import UIKit

class ViewController: UIViewController {

    // MARK: - Properties

    private var viewModel: ViewModel!

    // MARK: - View Life Cycle

    override func viewDidLoad() {
        super.viewDidLoad()

        // Fetch Notes
        viewModel.fetchNotes { [unowned self] (notes, error) in
            if error != nil {
                // Error Handling
                ...
                
            } else {
                // Update View
                self.updateView(with: notes)
            }
        }
    }

    // MARK: - View Methods

    fileprivate func setupView() { ... }

    fileprivate func updateView(with notes: [Note]) { ... }

}

After showing me the implementation, John asked me the most important question of the conversation. “I just add a view model? Is that necessary for such a simple view controller?” John understands what the Model-View-ViewModel pattern is and how it can be implemented, but his question implied that he missed the more profound benefits of the pattern. He saw the MVVM pattern as a slightly more sophisticated implementation of the MVC pattern, with a few additional bells and whistles.

Before I continue, it’s time to put your brains to work. You’ve now seen both implementations. The MVVM implementation is simple and we could make the implementation a bit better. But that’s not the point. Can you see how this simple view controller is benefiting from the MVVM pattern? Take a minute and think about the possible advantages MVVM has in this simple implementation.

Thinking Bigger

Most developers solve the problems they face without taking a look at the bigger picture. That’s fine and it’s something you only learn after you gain experience building software. For many developers, the implementations I showed you in this post look very similar and I assure you that a surprising number chooses the first implementation over the second one. Why is that? Make a guess.

The first implementation looks less complex and that may be true. It has a few flaws, though. Why is the view controller responsible for making a network request? It’s true that the API manager helps the view controller with this task, but the view controller still knows that the notes it fetches come from a backend. You could argue that these details are hidden by the API manager, but that’s not the point. The point is that the view controller controls a view and it shouldn’t know where the notes come from. It should only need to ask for content to display in its view. It shouldn’t even know about the API manager let alone how it does its job.

The view controller of the MVC implementation also manages state, an array of Note instances. This is typical for the MVC pattern. This isn’t bad or wrong, but the MVVM pattern hides this detail in the view model.

What’s in It for You

If we take a close look at the second implementation in which we use a very simple view model, we discover that the view controller is only responsible for controlling its view. It configures the view it manages and responds to user interaction. These tasks are the only responsibilities a view controller should have.

The view model may appear as just another object in the object graph. But it’s more than that. It hands the view controller an array of notes. The view controller has no idea where the notes come from and it shouldn’t be concerned with these details. They could be fetched from a backend, but they might as well come from a local cache managed by Core Data or Realm.

This also makes unit testing so much easier. Unit testing the view model is trivial and the testability of the view controller automatically improves.

Step Up Your Game

I strongly believe robust, testable code is built in a way that approaches the problem from a different perspective. We could stick with the MVC implementation, but I hope this post has convinced you that it isn’t the best solution. Using MVVM may look complex, but it really isn’t. It simply requires you to think differently and bigger.

If you’re new to Swift development, then it’s fine to embrace the MVC pattern. I believe that’s a good place to start because it keeps everything a bit simpler. However, I hope you don’t stop there. I hope you have the ambition to evolve and grow as a developer.

As developers, it’s very tempting to focus on the shiny stuff Apple throws at us every year, ARKit, Core ML, Metal, … These are great technologies and it’s a lot of fun exploring them. But focusing on your foundation as a developer should be your top priority. Always. That’s my obsession as a developer and the reason for creating Cocoacasts. With a solid foundation, you can play with Apple’s shiny stuff without having to worry about using them.

If you’d like to learn how to step up your game with the MVVM pattern, then you should check out my book and course on MVVM. As I emphasize in this post, we don’t simply implement the MVVM pattern. I show you how to step up your game with MVVM. MVVM is nothing more than a tool to do that.