Member-only story
Using the MVI pattern in Swift iOS App development
In the last couple of years, several new patterns emerged, all praising to make a developer’s life as easy as never before. By separating certain parts of the codebase, each of these patterns tries to make code more readable, easier to test, and eventually more maintainable.
This tutorial assumes a basic understanding of RxSwift, RxCocoa, Databindings, and how to use Cocoapods. Thus I won’t go into detail regarding these topics. Prior knowledge about other MVI* patterns does help but is not required.
MVI(Model-View-Intent) isn’t an entirely new pattern. Instead, it is built upon existing principles that have been used in the industry for years now. As the name already states, MVI adds to the list of MV* patterns. While these designs are traditionally imperative, reactive extensions have become more famous during the last decade. Especially concepts like MVVM moved closer to reactive programming, sometimes replacing imperative paradigms completely.
MVI was designed with reactive programming in mind. By using a framework, such as ReactiveX(http://reactivex.io), it unleashes its full potential, placing it further away from its siblings. While the imperative approach is possible, it counteracts the usefulness of MVI. Keeping that in mind, one should have a basic understanding of reactive programming before working with a pattern such as MVI.
The MV* family
As stated before, MVI is an addition to the MV* patterns family. Especially when compared to the MVP pattern, one might get the impression these two patterns are the same. Components are often named identical, but the use and connection of them are different.
The most common MV* patterns are:
- MVC(Model-View-Controller)
- MVP(Model-View-Presenter)
- MVVM(Model-View-ViewModel)
Let’s first have a look at the elder members of MV*.
