MVVM Migration @ Pepperfry iOS App : Part I — Inception
What?! Another blog on MVVM? What’s new in this? Does it talk about the same stuff like the millions of other “MVVM on iOS” blogs?
This blog is all about the journey of the Pepperfry iOS app from MVC to MVVM architecture and believe me, it will be adventurous and interesting!
About Pepperfry’s iOS App:
Initial commit on iOS app was made in May 2016. In this 3+ years since:
- We have deployed 80+ versions on the App Store.
- Added 73,000+ lines of code to the project.
- Constantly added, updated & removed features from the app.
- Followed MVC(Model-View-Controller) architecture.
- Consistently maintained about 99.9% of crash-free sessions on the app.
- Served millions of happy customers.
Initial app architecture:
Before looking into why we moved to MVVM architecture, let’s see our initial app architecture & the issues we faced with it.
MVC is common architecture pattern adopted by iOS developers and it’s the architecture that the Apple SDK is built on.
Like many other iOS apps, our app was also based on MVC architecture. Every module was divided into three parts:- Model, View & Controller.
- Model: Model is the layer where our data resides, things like model objects, parsers normally live here.
- View: View layer is the face of our app. It contains UI elements like label, textview, button & any other element that we see on screen.
- Controller: View Controller in iOS app acts as a controller in MVC. It is the main component in our app as all actions start & build across this entity. It acts as an intermediator between View & Model layers.
With this MVC architecture, we had several service managers, which helped us to distribute the tasks in the app like:
- Networking Manager, which handles the responsibility of server calls.
- App Flow Manager, which helps in managing app flow.
- Configuration Manager, which manages the configuration of the app
Issues with initial architecture :
As you can see, our app architecture was pretty straightforward & easy to implement. Initially, it was great to work with, but later on we encountered hurdles when we were trying to update or add functionality to existing modules.
First of all debugging existing code in View Controller was not an easy task, as it contained most of the business logic. If we wanted to add some functionality to existing code, we had no choice other than View Controller, which lead to spaghetti code. Without proper discipline, the view controller ended up being huge, leading us to believe that MVC meant Massive View Controller.
One fine day, we decided to start writing Unit Tests for our app and the urge for a new architecture was felt strongly by us. Our business logic resided mostly in View Controller and testing View Controller is not an easy task in iOS.
Rise of MVVM :
The UIViewController is the main component of Apple’s iOS SDK. It is the entity which controls all entities in MVC, so ideally it should have only code which manages the interaction between View & Model. But in reality, it contains most of the logic, which leads to unmanageable code.
If we look closely at managing View Controller properly, we can solve most of the problems, which have been mentioned above.
One of the ways is to move business logic from View Controller to another entity called View Model, hence MVVM comes into the picture.
In next part we will be having a deep discussion about MVVM in iOS.
