How to Use Views for iOS App Development

By Jesse Feiler

In an iOS app world, view objects are responsible for the view functionality in the Model-View-Controller architecture. A view is a rectangular area on the screen (it appears to be on top or within a window).

In the UIKit framework, windows are really a special kind of view, but for the purpose of this discussion, this refers to views that sit on top of the window.

What views do

Views are the main way for your app to interact with a user. This interaction happens in two ways:

  • Views display content. This happens, for example, by making drawing and animation happen onscreen. The view object displays the data from the model object.

  • Views handle touch events. Views respond when the user touches a button, for example. Handling touch events is part of a responder chain.

The view hierarchy

Views and subviews create a view hierarchy. You have two ways of looking at it (no pun intended this time): visually (how the user perceives it) and programmatically (how you create it). You must be clear about the differences or you’ll find yourself in a state of confusion that resembles the subway at rush hour.

Looking at it visually, the window is at the base of this hierarchy with a Content view on top of it (a transparent view that fills the window’s Content rectangle). The Content view displays information as well as allowing the user to interact with the app, using (preferably standard) user interface items such as text fields, buttons, toolbars, and tables.

In your program, that relationship is different. The Content view is added to the window view as a subview. But the Content view can also have its own subviews, and so on. Possible relationships include

  • Views added to the Content view become subviews of it.

  • Views added to the Content view become the superviews of any views added to them.

  • A view can have one (and only one) superview and zero or more subviews.

It seems counterintuitive, but a subview is displayed on top of its parent view (that is, on top of its superview). Think about this relationship as containment: A superview contains its subviews.

How a visual hierarchy translates into a structural one.

Controls — such as buttons, text fields, and so on — are actually view subclasses that become subviews. So are any other display areas that you may specify. The view must manage its subviews, as well as resize itself with respect to its superviews. Fortunately, much of what the view must do is already coded for you. The UIKit framework supplies the code that defines view behavior.

The view hierarchy also plays a key role in both drawing and event handling.

You create or modify a view hierarchy whenever you add a view to another view, either programmatically or with the help of the Interface Builder. The UIKit framework automatically handles the relationships associated with the view hierarchy.

Developers typically gloss over this visual-versus-programmatic-view-hierarchy stuff when starting out — and without understanding these concepts, it’s really difficult to get a handle on what’s going on.