iOS was first released in 2007, since then it has implemented Model-View-Controller (MVC) development design pattern. This design pattern is a common way to organize code so that it is reusable and more easily extensible.
In this post, we are going to look closer at the existing iOS MVC pattern variation and offer an alternative, and perhaps better, pattern for iOS development.
Introducing MVVM
One issue facing iOS developers is how to deal with major iOS updates for existing projects. More specifically, how to implement UI/UX changes as iOS evolves. Because iOS uses a combined view-controller design, this task can require a greater level of effort than should be necessary. Here’s why: because the view and controller are coupled, an iOS view-controller class will usually contain both UI logic and business logic. This means that changes in the way the view is presented (UI logic) will usually also require changes to business logic within the same view controller class.
Further, as view controller classes implement increasingly complex UI requirements, the amount of business-logic code also tends to grow within the same view controller class. This, is turn, typically results in large, unwieldy, and difficult-to-read view controller classes.
Wouldn’t it be better to have thin, flexible, easy-to-read view controller classes in iOS?
The MVVM Design Pattern
The “Model-View ViewModel” design pattern, or “MVVM”, is similar to the MVC as implemented in iOS, but provides better decoupling of the UI and business logic. This decoupling results in thin, flexible, and easy-to-read view controller classes in iOS
Business Logic and workflows are contained in ViewModel and all UI related logic is there in View-Controllers, and knows nothing about business logic.
MVVM is built around three fundamental parts: data model, view/view-controller, and viewModel:
1) Data Model
Just like in the MVC design pattern, the MVVM data model is a class that declares properties for managing business data.
2) ViewModel
The viewModel is at the heart of the MVVM design pattern and provides the connection between the business logic and the view/view controller. The view (UI) responds to user input by passing input data (defined by the model) to the viewModel. In turn, the viewModel evaluates the input data and responds with an appropriate UI presentation according business logic workflow.
3) View/View Controller
The view/view controller is the context (i.e. the view controller class) that presents user interface elements. It contains no business logic
Advantages of MVVM Design Pattern
Thin view controllers that are easily debugged
In MVVM, view controllers are concerned only with the UI. MVVM UI encapsulation means finding and fixing UI issues is usually a straightforward process that no longer involves digging through business logic trying to locate the root cause of a particular bug.
Flexible business logic and work flows
Adding and modifying workflows (e.g. which view shows when) is done very quickly in the MVVM design pattern. MVVM UI/business logic decoupling means changes can usually be done with simple one or two line changes in the viewModel.
Code reuse
Most init, setup, and view presentation methods are implemented in the viewModel class. As such, each new view controller shares those methods, which means no redundant view controller code.
