Lean ViewControllers with MVP & MVVM
MVP (Model View Presenter) & MVVM (Model View ViewModel) can both help to tame the symptoms of massive view controllers. The default architecture pattern for building iOS applications is MVC (Model View Controller) and although there is nothing wrong with MVC pattern, but most of the time view controller becomes the point of code dumping ground and MVC has been jokingly referring to as Massive View Controller.
In Apple's implementation of MVC, the View and Controller are hard to separate. The Controller ends up being a delegate to all the views and a data source for everything, including sending and receiving network requests. The problem might not be apparent until it comes to the Unit Testing. Since the Controller is tightly coupled with the View, it becomes difficult to test distinct units.
MVP treats the ViewController as the View and backs each one with a Presenter that represents the data for that View. This Presenter mediates between the Model and View. The Model and View now never know about each other and code is kept in more distinct independent units. Meaning it is easier to read, keep track of and test.
One drawback of MVP is that the time and amount of code required increases compared to MVC because you have to forward all events from the Presenter and update the View manually. This is where MVVM comes in. MVVM uses bindings to link data in the ViewModel (our mediator) to the View. Now the View is responsible for getting the data it needs and the ViewModel does not know about the View. When changes are made in the ViewModel the View is automatically updated. The results of this is a leaner codebase compared to MVP.
One drawback to MVVM is that, currently, we don't have anything in iOS that performs bindings by default. Our choices are to write them ourselves, use one of the KVO based binding libraries like the RZDataBinding or SwiftBond, or full scale functional reactive programming beasts like ReactiveCocoa, RxSwift or PromiseKit.