What is iOS MVC in plain terms

MVC stands for M(Model),V( View),C(Controller).

It all comes down to code separation and reusability. Ideally, the View should be completely separated from the Model. If the View doesn’t rely on a specific implementation of the Model, then it can be reused with a different model to present some other data.

The business logic that is processed within the Controller must also be independent of View.
I should be able to use the business logic in other applications, so it must be separated from the View.

For example, if I create an application that is a simple calculator, I should be able to reuse simple operations (addition, subtraction, multiplication, division) in an application that is a scientific calculator (which have all simple operations and more other as cosine, sine, square,…).

If I put all the operations of simple calculator app on the View Controller they are coupled to the View and can not be reused (by example) in the scientific calculator app.


It is the data and data-management of the application.
The model notifies its observers when his properties have changed.
Which observers?
Something associated with and inside Controller, because remember the View and the Model not communicate directly with each other.


A view should be as dumb as possible. The View is a passive interface that displays data and routes user actions to the Controller. 
Model and View shouldn’t even know about each other in the ideal case.

In order to View to be completely separate from the Model, a distinction between domain model and view model should be made.
The domain model are entities as they are in the database, while view model is a model of the fields for display in View.
Swift map function is ideal to turn a domain model in view model.

In iOS apps the ViewController is part of the View.
Because the UIViewController is bound to a specific UI implementation: UIKit.
The Controller should not be dependent on a specific implementation of UI.


It’s the brain in the MVC. 
It is the conductor of the orchestra. It is the manager of the work. I think good name for Controller is Business Controller.
The Controller does not work by itself, it delegates work to others.
It only coordinates and points the direction of the work.
The controller manages the communication between the view and the model. It takes the data from the model and communicates it to the view for display.

A View receives an input of an event and asks the Controller:
You are the brain, what you want to do with this?
Then if the Controller needs data bothers Model layer to provide them.
The Controller then receives Model data and decides whether he wants to View the displays the data in a certain way or even change the view by another view.

You can consult a simple calculator with operations of addition and division following the MVC architecture here:

Remember one more time the controller is the coordinator.

In nutshell, in this app, the job of controller is:

“If this happens call that model operation, otherwise call other model operation.

Then if this result update that (part of) view, otherwise update other (part of) view.”