MVC Alternatives [Part 1: MVVM]

Model View Controller is of the first concepts I learned in iOS development. It is most common used design pattern you can see in an iOS app. It is easy to use, suggested by apple and fairly understandable.

If you’ve noticed there are number of other architectures that are created to replace MVC. Here we’ll see a list practical ones and more importantly the answer to this question.

Why MVC needs alternatives?

By definition they sound to be separated but in reality View and controller are tightly coupled, and also each one knows about the other two. And this is where all problems starts:

  1. This is violation of the Single Responsibility Principle
  2. This leads to a common problem so-called Massive View Controller
  3. This reduces reusability of each of entity
  4. Testability of the code is almost impossible

In real life the View and the Model are separated, but the View and the Controller are tightly coupled. All the code for both the controller and the view is written in ViewController. View Controllers get packed with the code quickly for various purposes. This problem is called Massive View Controller.

View and Controller are coupled in real life MVC in iOS

Massive View Controller is the state that a lot of logics and responsibilities such as network connection, converting Date to String, and image manipulation code has been moved into View Controllers. This practice makes your code bulky and hard to change. They clearly are not not belong here, but should we consider them as part of our model? No! They’re certainly not a view. Where else can they be?


MVVM became a trending iOS architecture for couple reasons. It focuses on the separation of user interface from other layers. MVVM is compatible with your existing MVC architecture. This separation makes the apps more testable since the ViewModel knows nothing about the View.

By using MVVM you will separate the whole business logic from UIKit which used to be coupled in MVC.


All the logic about preparing data for UI (e.g. converting date to string) happens in the ViewModel instead of the View. Therefore, it becomes possible to write a simpler tests for these logics without knowing the implementation of the View.

In MVVM, nothing is changed directly in the View, we deal with business logic in the ViewModel and thus the View changes itself accordingly. The View updates itself after observing the change of the ViewModel. Connecting UI components to ViewModel properties is called “Binding”.


The important part of the understanding of the MVVM is that View updates it’s state from the ViewModel through some sort of observer. Basically the whole idea is to notify the View of any state change in the ViewModel.

There are a few options to implement this (in Swift):

There’s nothing about MVVM that forces you to use specific mechanisms to update the viewModel, or the view but usually if you are talking about MVVM the first solution comes to the mind is Functional Reactive Programming.

If you have experience working with functional reactive programming or you are familiar with frameworks like ReactiveCocoa, this will be the exact same as binding a property to a signal. In the case of the MVVM, view will bond the viewModel’s property to a UI element.


Using MVVM can be a solution to the Massive view controller problem (not always! because viewModel itself can become bulky), separates the business logic from UIKit, and makes the code more maintainable, and testable.

iOS Developer, computer science freak

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store