The Model View Controller (MVC) Design Pattern in iOS

Elise Harris
3 min readAug 29, 2015

In the Model View Controller design pattern, a website or app divides its labor between three components. The model is where data and most of the objects and methods are stored. Calculations may also be performed there. The model connects to a database. The controller negotiates between the model and the view, it is like a conduit between these camps and may be said to glue them together. The controller uses the view’s UI tools to get content onscreen. It is said to “render” a view. The view is what the user sees. The view may seem to be doing more than it is. It is really just a collection of UI tools that interact with the user for the controller. The controller is really pulling the strings behind user-browser interactions.

Within that broad schema, there are several versions of the MVC pattern, as seen in these schemas from Soroush Khanlou’s blog.

MVC model one
MVC model two

Both images from Khanlou.com, Model View Whatever. The latter seems analogous to this diagram:

MVC map two — another image

Screenshot from Understanding MVC architecture by Jesvin Ciril Joachim

Many languages use MVC, or other versions of the pattern such as Model View Whatever, especially AngularJS, Apple Cocoa, and Java. Ruby on Rails has prebuilt code for these processes, with names like Active Record for the model. MVC behaves differently in Rails, iOS, Java and AngularJS. Soroush Khanlou says that the iOS version of MVC might best be termed Model View Adapter:

as in the Stanford video screenshot below, there is no direct interaction between model and view:

From Stanford’s video MVC and Introduction to Objective-C (September 27, 2011)

Communication patterns work differently in Rails and other frameworks, but those are not the subject of this blog post.

MVC is thus a theoretical construct and an umbrella terms for many different configurations. Programming continues and new versions of it will continue to emerge.

--

--