[View]  [Edit]  [Lock]  [References]  [Attachments]  [History]  [Home]  [Changes]  [Search]  [Help] 

[U8] iOS UI Framework

The iOS UI is based on Windows and Views which are used to present application content on the screen.

Windows do not have any visible content but provide a basic container for the views. Views define a portion of a window that will be filled with some content. Views can also be used to organize and manage other views.

Every iOS application has at least one window and one view for presenting its content.


A view is an instance of the UIView class (or one of its subclasses) and manages a rectangular area in an application window. Views are responsible for drawing content, handling multitouch events, and managing the layout of any subviews. In the view hierarchy, parent views are responsible for positioning and sizing their child views dynamically.

In general a developer uses several views as building blocks to build a view hierarchy (and corrdinate it through view controllers, see section "iOS UI Elements" below)

As expected most operations on parent views are chained to child views (resizing, events, etc). Each superview stores its subviews in an ordered array and the order in that array also affects the visibility of each child.

Because view objects are the main way the application interacts with the user, they have many responsibilities:


Every view is backed by a layer object (usually an instance of the CALayer class), which manages the backing store for the view and handles view-related animations. A layer can be accessed from that view’s layer property.

Most operations on a view should be through the UIView interface but when more control is needed over the rendering or animation behavior of a view, operations are done through its layer instead.

View Life Cycle

A View uses on-demand drawing model for presenting content. A snapshot is captured on the view's first drawing so it's reusable. When the content is changed the system is notified and the view repeats the process of drawing itself and capturing a snapshot of the new results.

When the contents of your view change you invalidate the view using either the setNeedsDisplay or setNeedsDisplayInRect: method. But before that you need to render your view’s content where the actual drawing process varies depending on the view and its configuration. System views typically implement private drawing methods to render their content. Those same system views often expose interfaces that you can use to configure the view’s actual appearance. For custom UIView subclasses, you typically override the drawRect: method of your view and use that method to draw your view’s content.


A window is an instance of the UIWindow class and handles the overall presentation of the application’s user interface. Windows work with views (and their owning view controllers) to manage interactions with, and changes to, the visible view hierarchy. Every application has at least one window that displays the application’s UI.

A window object has several responsibilities:

In iOS, windows do not have title bars, close boxes, or any other visual goodies. A window is always just a blank container for one or more views.

Most iOS applications create and use only one window during their lifetime. This window spans the entire main screen of the device and is loaded from the application’s main nib file (or created programmatically) early in the life of the application.

Task involving Windows

In general the only time the application interacts with its window is when it creates the window at startup. However, you can use your application’s window object to perform a few application-related tasks:


Animations provide users with visible feedback about changes to the view hierarchy. The system defines standard animations for presenting modal views and transitioning between different groups of views. Many attributes of a view can also be animated directly.

External Representation

Interface Builder is an application used to graphically construct and configure your application’s windows and views. Using Interface Builder the assembled views are placed in a nib file (a resource file). When nib file is loaded at runtime, the objects inside it are reconstituted into actual objects.
This is an interesting starting point for researching programmatic UI building in coco8.

iOS UI Elements

The UI elements fall into four broad categories:

A UI element is a type of view because it inherits from UIView. A view knows how to draw itself onscreen, and it knows when a user touches within its bounds. Controls (such as buttons and sliders), content views (such as collection views and table views), and temporary views (such as alerts and action sheets) are all types of views.

To manage a set or hierarchy of views in your app, you typically use a view controller. A view controller coordinates the display of views, implements the functionality behind user interactions, and can manage transitions from one screen to another. For example, Settings uses a navigation controller to display its hierarchy of views.

Here’s an example of how views and view controllers can combine to present the UI of an iOS app:

Uploaded Image: ios ui.png

For a detailed description of UI elements see this page.