Programming iOS 6, 3rd Edition

The View Controller Hierarchy

Because of containment and presentation, there is a hierarchy of view controllers. In a properly constructed iOS app, there should be exactly one root view controller, and it is the only view controller that has neither a parent view controller nor a presenting view controller. Any other view controller, if its view is to appear in the interface, must be a child view controller (of some parent view controller) or a presented view controller (of some presenting view controller).

At the same time, at any given moment, the actual views of the interface form a hierarchy dictated by and parallel to some portion of the view controller hierarchy. Every view visible in the interface owes its presence either to the fact that it is a view controller’s view or to the fact that it is, at some depth, a subview of a view controller’s view. Moreover, a child view controller’s view is, at some depth, its parent view controller’s view’s subview.

The place of a view controller’s view in the view hierarchy will most often be automatic, by virtue of the view controller’s place in the view controller hierarchy. You might never need to put a UIViewController’s view into the view hierarchy manually (and it would be wrong to do so, except in specialized circumstances that I’ll talk about in a moment).

For example, in Figure 19-1, we see three interface elements (from top to bottom):

• The navigation bar, containing the TidBITS logo.
• Some text, which is actually a UILabel, stating ...