How to Use the Model-View-Controller (MVC) Design Pattern to Develop an iOS App - dummies

How to Use the Model-View-Controller (MVC) Design Pattern to Develop an iOS App

By Jesse Feiler

The iOS frameworks are object oriented. An easy way to understand what that really means is to think about a team working in an office. The work that needs to get done is divided up and assigned to individual team members (in this case, objects). Each team member has a job and works with other team members to get things done.

What’s more, a good team member doesn’t care how other members do their work, just that they do it according to the agreed upon division of labor. Likewise, an object in object-oriented programming takes care of its own business and doesn’t care what the object in the virtual cubicle next door is doing, as long as it will do what it’s supposed to do when asked to do it.

Object-oriented programming was originally developed to make code more maintainable, reusable, extensible, and understandable by encapsulating all the functionality behind well-defined interfaces. The actual details of how something works (as well as its data it uses to do that work) are hidden, which makes modifying and extending an app much easier.

Great — so far — but a pesky question still plagues programmers:

Exactly how do you decide on the objects and what each one does?

Sometimes the answer to that question is pretty easy — just use the real world as a model. (Eureka!) But when it comes to a generic program structure, how do you decide what the objects should be? That may not be so obvious.

The MVC pattern is a well-established way to group app functions into objects. Variations of it have been around at least since the early days of Smalltalk, one of the very first object-oriented languages. MVC is a high-level pattern — it addresses the architecture of an app and classifies objects according to the general roles they play in an app, rather than drilling down into specifics.

The MVC pattern creates, in effect, a miniature universe for the app, populated with three distinct kinds of objects. It also specifies roles and responsibilities for all three types of objects and specifies the way they’re supposed to interact with each other. To make things more concrete (that is, to keep your head from exploding), imagine a big, beautiful, 60-inch, flat-screen TV. Here’s the gist:

  • Model objects: These objects together comprise the content “engine” of your app. They contain the app’s data and logic — making your app more than just a pretty face. In the RoadTrip app, for example, the model maintains a list of events and sights, as well as the name and location of the destination and a background image to use.

    You can think of the model (which may be one object or several that interact) as a particular television program, one that, quite frankly, doesn’t give a hoot about what TV set it’s shown on.

    In fact, the model shouldn’t give a hoot. Even though it owns its data, it should have no connection to the user interface and should be blissfully ignorant about what’s done with its data.

  • View objects: These objects display things on the screen and respond to user actions. Pretty much anything you can see is a kind of view object — the window and all the controls, for example.

    Your views know how to display information they receive from the model object and how to get any input from the user the model may need. But the view itself should know nothing about the model. It may handle a request to display some events, but it doesn’t bother itself with what that request means.

    You can think of the view as a television screen that doesn’t care about what program it’s showing or what channel you just selected.

    The UIKit framework provides many different kinds of views.

    If the view knows nothing about the model, and the model knows nothing about the view, how do you get data and other notifications to pass from one to the other? To get that conversation started (Model: “I’ve just updated my data.” View: “Hey, give me something to display,” for example), you need the third element in the MVC triumvirate, the controller.

  • Controller objects: These objects connect the app’s view objects to its model objects. They supply the view objects with what they need to display (getting it from the model) and also provide the model with user input from the view.

    You can think of the controller as the circuitry that pulls the show off of the cable and then sends it to the screen or requests a particular pay-per-view show.

With Xcode, both the model and view objects are often built with graphical user interfaces such as Interface Builder for views and view controllers and the Data Model Editor for Core Data objects. Controllers are almost always built with code. Building a controller object is the part of MVC that, for many developers, “feels” like traditional coding.

The basic application architecture looks like this.


When you think about your app in terms of model, view, and controller objects, the UIKit framework starts to make sense. Understanding the framework this way also begins to lift the fog hanging over where to make at least part of your app-specific behavior go.

In Objective-C, classes include instance variables, properties, and methods (that can access the instance variables of a class). Classes are about files in your project that contain code. Classes are types in your program.

Objects, on the other hand, exist at runtime and are instances of a class. You can think of a class as a blueprint to build an object of that type.