What is a UIViewController

Swift version: 5.6

Paul Hudson @twostraws May 28th 2019

iOS developers often like to talk about the Model-View-Controller architecture (MVC), where every component in their code is either a Model, a View, or a Controller. This is the standard architecture on iOS, which makes it strange that one of the first types you meet is UIViewController – it has both “view” and “controller” in its name, so what is it?

Well, there is no single answer. In the early days of iPhones, UIViewController represented one screen of content. Your mailbox was one view controller, and when you tapped to read a message that was shown in a different view controller.

However, the story is more complex than that, because of view controller containment – you can put one view controller inside another, which helps break up your code. As a result, one screen of content might consist of four or five view controllers all working together.

The main (and inescapable) role of view controllers is to respond to view lifecycle event. That is, your view controller code will get call when your view is created, shown, hidden, and destroyed, so it’s down to you to write code to respond to those events properly.

Some people make their view controllers more view than controller (i.e., make it handle layout code and as little else as possible), some people make it more controller than view (i.e., put layout code into UIView subclasses and put glue code into their view controllers), and some people make it do both: they put all their view code and all their controller code in one place.

If you want to make your view controller more view than controller that’s fine. If you want to make it more controller than view that’s less fine, but it can still work. If you want to use it as both, chances are you’ll stop using Model-View-Controller and start using Massive-View-Controller instead.