MVVM(VC)

Practical Software Architecture, Swift Style

The main software architecture pattern in iOS is model-view-controller (MVC), but when projects hit a certain level of complexity the fact that large amounts of code end up living in the ViewController layer in iOS can start to get ugly and hard to work with. This has lead to borrowing patterns from the model-view-viewmodel (MVVM) pattern in many projects at work.

In Objective-C this meant making heavy use of data bindings between the view- model and view layer, with RZDataBinding helping to take a lot of the rough edges off of data bindings. In most cases, this worked really well, and things like coalescing updates took care of many of the edge cases like notification storms or bad intermediate state being generated.

In Swift, there isn't a clear win for data binding yet, so we've pulled back on the "bind everything" side of MVVM. One pattern that I've found useful is keeping view models as lightweight structs, having all of their internal values immutable, and generating a new view-model and replacing it on the view, which updates on didSet for view viewModel variable.

Overall, it's leading to more thinner layers in an app, because it means the viewModel doesn't contain any intelligence about self updating, which moves the self updating logic into the viewController, or into a services layer object that that produces a model object, which then can be parsed into the appropriate view-model.