I'm sure every new iOS developer has the following problem: The View Controllers get very fast crowded with code for various purposes, easily getting to 500 + lines of code.

This is how it looks like for two basic and common screens:

1) The Form Screen: enter image description here

2) The Table View Controller Screen enter image description here

So far I have read about two different solutions:

  1. First Solution: https://bendyworks.com/single-responsibility-principle-ios/. This is based on Notifications, it completely separates the View Controller from the (Intentions) View Model and thus reduces code in the View Controller. I think that it has the downside of breaking code, similar to Go-To structures. It looks like this: enter image description here

  2. The second solution keeps the same crowded View Controllers (button actions are executed inside VC and so on). but uses libraries like TPKeyboardAvoiding, BlocksKit or other solutions most of them based on categories. With this second solution, code is drastically reduced but the view controller still has a lot of responsibility.

What do you think about these solutions? Which is better? Is there a better one?

  • 5
    I can't give a good answer because of time, but this should point you in the right direction.
    – Mike D
    Dec 23, 2014 at 20:31
  • My intention is to collect as many good answers as possible to finally overcome this problem that so many new developers have. Thanks for the link, if I find something new I will surely post it here.
    – Ravul
    Dec 23, 2014 at 20:39
  • Here's a great talk about fighting with fat view controllers by Andy Matuschak https://realm.io/news/andy-matuschak-refactor-mega-controller/ Sep 30, 2015 at 19:13

3 Answers 3


We can use MVVM to resolve this issue.

The Model-View-ViewModel, or MVVM pattern as it’s commonly known, is a UI design pattern. VM takes all logic about preparing model data for UI from VC.

You have got model object with some fields, you want to format some of them, make calculation and combine them.

In MVC case all that logic located in ViewController.
In MVVM you move all of it from VC to VM.

VM will prepare all data for UI and VC just sets it like this.

(in VC class)

self.descriptionLabel = self.viewModel.textForDescriptionLabel;

Tutorials and topics:

  • 3
    Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. Dec 25, 2014 at 9:58
  • I agree with Bart. If no one else will post a summary of all these methods, I will make one as soon as I understand and test them all.
    – Ravul
    Dec 25, 2014 at 10:35
  • 2
    @Ravul updated answer
    – kaspartus
    Dec 25, 2014 at 15:01
  • I have up-voted your answer and thank you for this idea. I am just reading about Functional Reactive Programming and it seems a good idea. I think the answer to this question is an enumeration, with a few advantages, disadvantages and at least one conceptual diagram for the following 4 ways to approach the problem: 1) Reactive Cocoa 2) KVO 3) Delegate method and 4) Classical way of writing a View Controller. I will write it as soon as I test all of these methods if no one else does so before me. If in the meantime I find new ways, that is even better.
    – Ravul
    Dec 25, 2014 at 22:03

I've had to untangle code in massive-sized View Controllers before and it really impeded my ability to navigate content at first. One important thing I realized is that size alone of the View Controller wasn't reason enough to break things apart. There is complexity in having 1 large file and also complexity in having a bunch of little files. Here are some valid reasons to refactor to break a View Controller into smaller parts:


The View Controller shouldn't be doing much more than being the connecting glue between the View and the Model. If you a lot of network connection code, image manipulation code, etc, then consider breaking those out into helper classes.

Multiple Controls with the View Controller as a data source

If you have a bunch of controls on screen that have your View Controller as data source, consider breaking those into separate data source objects and have them be the data source. Or you can also break them into separate View Controllers (like if you View Controller has a table view in addition to other controller, you can break that into its own Table View Controller class).

Duplicate Code

If you have the exact same code in different View Controllers put that in 1 shared location. That will make your code reusable and help manage the complexity.

Here is some additional advice to minimize View Controller complexity:

Storyboard instead of Programmatic

Creating View elements is a lot of code and frame geometry code is a lot of work as well. If not already consider using auto layout constraints and putting as much of the View elements in the storyboard as possible.

Unnecessary code/comments

Also be sure to remove unnecessary code/comments. A lot of times a new View Controller file will come with methods you are not using. If you aren't using a method like didReceiveMemoryWarning then it is safe to take it out. Also, because the View Controller file is so big sometimes it is scary to remove old code or comments. Don't put that off! It only adds to the complexity.


To answer your question about notifications: Notifications aren't a Golden Hammer to use with everything. I find notifications to be useful when multiple View Controllers need to update at the same time because of 1 particular action. Be careful with notifications though, overusing them can cause you a lot of pain trying to track them down.


There's one special architecture they call VIPER (View, Interactor, Presenter, Entity and Routing). I'll try resume here what you need know:


  • they are dummy views;
  • contain objects like UIView, UIViewController, UILabel, etc;
  • waits the content from the Presenter;
  • handle user interaction and pass it to Presenter layer.


  • doesn't know UI objects;
  • get inputs from View layer;
  • handle the view logic (add method will present other screen);


  • handle the navigation logic and transition animations;
  • knows objects like UINavigationController, UIWindow, etc;

So, what I think you will clean in your code:

  • data validations will move to Presenter layer;

  • navigation will move to Wireframe objects (Routing layer);

  • split your view controller observing DRY principle;

  • Complex screens will have two or more Views and Presenters.

You should see the follow link about VIPER architecture http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

Good lucky!

  • 1
    Does this architecture works for small applications? Looks like you have to create a lot of objects to introduce it to the project. Sep 30, 2015 at 19:18
  • yeah, I agree that it's more object than traditional MVC but it's worth. You can see one simple example I created this year github.com/orafaelreis/cascavel Cascavel is like a base project to initialize VIPER projects. Oct 2, 2015 at 11:40
  • Excellent ! The VIPER architecture seems designed exactly to avoid the issue of massive view controllers.
    – Christophe
    Oct 8, 2016 at 23:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.