How To Make iPhone Apps – MVC, One Pattern To Rule Them All

Welcome to part 3 of my series on How To Make iPhone Apps with no programming experience – where we’ll turn even the non-programmer into an iOS developer! Here’s the article index for the entire series in case you missed it. Today, we introduce the model view controller architecture pattern that all iOS apps are… View Article
Written by

Chris C

Updated on

Sep 25 2019

Table of contents

    Welcome to part 3 of my series on How To Make iPhone Apps with no programming experience – where we’ll turn even the non-programmer into an iOS developer! Here’s the article index for the entire series in case you missed it.

    Today, we introduce the model view controller architecture pattern that all iOS apps are based off of! By the end of this tutorial, you’ll be armed with the practical knowledge of Objective-C from the previous 2 parts of this series and you’ll understand the concepts of architecting iPhone apps with MVC.

    1. MVC – Introduction

    As implied with the name, the MVC software design pattern refers to three separate roles: the model, the view and the controller.

    The idea is that the objects in your application will take on these roles and work together to create and manage the user interface. Not all objects will assume one of these 3 roles; For example you might have a class that contains a bunch of helper methods however, the model, view and controller roles are the central actors to making your app function.

    The Model

    The model represents the data in your application. It’s responsible for sorting, validating and organizing your data.

    The View

    The view is the user interface or what the user sees and interacts with.

    You can create views programmatically through code using Apple classes such as UIView or you can create a XIB file to represent the view and visually layout your elements through Interface Builder.

    The Controller

    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.

    In the same vein, the controller also takes the changed data (due to user interaction or something else) and communicates it back to the model.

    The Model And View Never Talk To Each Other
    They shouldn’t even know about each other in the ideal case.

    The beauty of this modular architecture is that the separation of roles allow us to make modifications easily with less bugs.

    For example, if in the future, you need to make a change to the way the data is fetched or organized, all you need to do is switch out the model. As long as you keep the interface of the model the same (the header file), then the views and controllers will be none the wiser.

    Here’s a diagram illustrating what we’ve talked about:

    Model View Controller Diagram

    What’s a UIViewController?
    When you create a controller in XCode, you might get confused because it’s named UIViewController but it is a controller.
    What’s a UIView?
    Views in XCode are named UIView and they represent the view that gets displayed to the user.

    2. The Lifecycle Of ViewControllers

    When the user sees a screen of your application, there’s a process of steps that happens. First a UIViewController gets loaded into memory, then it sets up the UIView and the view gets presented to the user. When the user moves on from that view, the UIView gets torn down and the UIViewController gets unloaded from memory.

    In the UIViewController class, there are specific methods that you can override to perform tasks during each of those events.

    What is Overriding?
    Remember that we had talked about inheritance in Part 1?

    The subclass inherits all the methods, variables and properties of it’s parent. Well, overriding is a term in object oriented programming where you specify the same method signature in the subclass’s header file as it exists in the parent’s header file. However, in the implementation file of the subclass, you add to the original functionality or you change the implementation completely.

    Here’s an example:


    @interface BaseViewController : UIViewController
    - (void)resetView;


    @implementation BaseViewController
    - (void)resetView
        // Some code to reset the view

    I’ve got a class that has a resetView method.


    #import "BaseViewController.h"
    // Notice this class is a subclass of BaseViewController (parent)
    @interface HomeViewController : BaseViewController

    HomeViewController subclasses BaseViewController and will inherit the resetView method.

    That means other classes will be able to call resetView on a HomeViewController object.


    @implementation HomeViewController
    - (void)resetView
        // This will call the resetView method in the parent
        [super resetView];
        // Some additional code

    In this implementation file however, I override the resetView method and add my own implementation.

    The line, [super resetView], calls the parent’s resetView implementation and will execute the code in that method. If you don’t want to execute the code in the parent’s resetView implementation, you can omit the [super resetView] line entirely. super refers to the parent.

    And finally, below the [super resetView] line, you can add some additional code to extend the functionality of the overridden method.

    Back To The Lifecycle Of ViewControllers
    So we were talking about how there are events at certain points in the lifecycle of viewcontrollers that you can override and execute code in.

    Here they are:


    - (void)viewDidLoad
        [super viewDidLoad];
        // Do any additional setup after loading the view.

    This method occurs after the view has been allocated and loaded into memory. Typically you’ll want to do any initialization of the views in this method such as setting properties of the view, calling methods of the view and generally getting it ready to be displayed to the user.


    - (void)viewWillAppear:(BOOL)animated
        [super viewWillAppear:animated];

    As the name implies, the view is about to be rendered to the user.

    You don’t want to execute any heavy code in here or else the user will notice a lag before the view shows up.


    - (void)viewDidAppear:(BOOL)animated
        [super viewDidAppear:animated];

    At this point, the view has just been displayed to the user.

    Here you may want to show additional views, animate other things in etc.


    - (void)viewWillDisappear:(BOOL)animated
        [super viewWillDisappear:animated];

    The view is about to be removed from the screen.

    For example, you may want to use this opportunity to save certain values or user input.


    - (void)viewDidDisappear:(BOOL)animated
        [super viewDidDisappear:animated];

    After the view has disappeared from display.

    For example, you may use this opportunity to display the next view.

    You might not have the need to run code in all of these overridden methods, but the opportunity exists and you can do so in the right situation.

    Let’s Summarize

    This was a short post but nonetheless really important!

    Now you understand:
    -What MVC means!
    -What the different roles of MVC are responsible for!
    -How models, views and controllers interact with each other!
    -The UIViewController life-cycle!

    What’s Next?

    This concludes the iOS app development tutorial. In the next part, we’ll get started with XCode and introduce you to the environment that you’ll be spending a lot of time in.

    Go To Part 4

    Let’s improve this article together!

    I want to make this series and this article in particular the best and easiest to understand resource for beginners to learn how to develop iPhone apps. If you’ve got any feedback, good or bad, please let me know via the comments below so I can update parts which are confusing, add more examples and to continue updating this resource.

    And if you’ve enjoyed this article or you know someone who might be interested in learning how to build iOS apps, please share this series with them. It’s targeted at the non-programmer (sort of like an iPhone application development for dummies book) so anyone you know will be able to pick this up and progress towards developing iPhone apps!

    Get started for free

    Join over 2,000+ students actively learning with CodeWithChris