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:

When you create a controller in XCode, you might get confused because it’s named UIViewController but it is a controller.
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.
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:
BaseViewController.h
@interface BaseViewController : UIViewController - (void)resetView; @end
BaseViewController.m
@implementation BaseViewController - (void)resetView { // Some code to reset the view } @end
I’ve got a class that has a resetView method.
HomeViewController.h
#import "BaseViewController.h" // Notice this class is a subclass of BaseViewController (parent) @interface HomeViewController : BaseViewController @end
HomeViewController subclasses BaseViewController and will inherit the resetView method.
That means other classes will be able to call resetView on a HomeViewController object.
HomeViewController.m
@implementation HomeViewController - (void)resetView { // This will call the resetView method in the parent [super resetView]; // Some additional code } @end
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:
ViewDidLoad
- (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.
ViewWillAppear
- (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.
ViewDidAppear
- (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.
ViewWillDisappear
- (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.
ViewDidDisappear
- (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
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!
check useful link here..http://mvc4all.com/mvc/what-is-mvc/
Why do we use brackets in some situations and parentheses in others?
I’m new to objective c my self, so im not going to try and Sound all clever, I only have 600 achievement points in iOS development on treehouse.
Anyway I know at least that methods use curly braces. And it seems to me that parenthese are part of the regular c basics and brackets are for accessing the objectiv c framework classes. I’m not sure though!
Peace
Nice job for our beginners.
Thank you for the kind words Charlie 🙂
Very good article. There is other pattern (different from MVC) in ios programming ?
Yes! MVC is the core pattern of iOS apps but there are other patterns used. Here’s a really good article detailing that:
https://www.raywenderlich.com/477-design-patterns-on-ios-using-swift-part-1-2
Great stuff Chris! 🙂
I think if there was a basic Model and View class shown here as well it would definitely help. The Controller is covered quite well. I’m sure it’s coming later in more detail but maybe a brief intro would be beneficial.
Thanks for all your hard work!
I agree; Made a note to expand on this article. Thanks for reading!
Hi,
I have been studying Your tutorials from a long time and they are great and has helped me alot. Thanks and please keep on your work. 🙂
Thanks for reading and the kind words, Himshweta!
Cool also complete this section. Now I can’t wait to get my hands dirty on Xcode. This part was very easy to understand, especially how you describe the MVC, could you in future references make more graphs or figures to explain things. Personally I seem to understand it better. Awesome tutorials overall!
Nice! Thanks for the feedback Frankie 🙂 I’ll include more diagrams and screenshots in future tutorials.
Things are a little complicated in my case. I have an undergraduate in Data Processing and a graduate in System Analysis but I haven’t worked in the IT field for about 10 years. I am completely outdated and I am trying to bring back the knowledge I have, but I also have another problem. I am from a country where the spoken language is not English and even though I was already fluent in English back then, the vocabulary in this field is somewhat new to me since I studied the traditional method and very little of Object Oriented stuff (it was new when I was finishing my schooling). I keep trying to remember and I like your videos a lot, but I keep feeling that there is something I am missing and I can’t tell what it is. How about we try doing a little project together where you can explain NOT ONLY what needs to be placed at a certain spot, but WHY it needs to be done? I think it would help even more!
Please, keep the videos coming!
I sent you an email Adriana! Hopefully I can help you bridge the gap!
A very good article, you are great! But I don’t know why you didn’t mention anything about “Model” part in terms of iPhone. We see View part as UIView, we see UIViewController as controller; but where does the Model part lie?
Model is generally a subclass of NSObject or NSManagedObject.
Hi,
Article is great. Thanks for sharing.
Logic of controller and view is pretty clear but model.
Can you show code example for model part?
Thanks
Hey, Really nice tutarial
Worth readnig. Thank you!