---
title: 'Building iOS Interfaces: Views'
teaser: Views are the cornerstone of iOS app interfaces. Let's take a look at what
  they are and how they work.
tags: ios,design,mobile,swift
author: Reda Lemeden
published_on: 2016-02-03
---

*This article is Part 2 of the __Building iOS Interfaces__ series which tackles
*the how and why of implementing iOS designs without prior native programming
*experience--perfect for Web designers and developers. You can find the other
*articles here: [Part 1][previous post] -- [Part 3].*

In the [previous post], we looked at the different technologies and tools
involved in the process of building iOS interfaces, including *UIKit*. In this
article, we will take a closer look at one of the cornerstones of native app
design in iOS: views.

### Conceptual Overview

As we've [established previously][Frameworks], UIKit is the framework that wraps
all the APIs required to build iOS interfaces. These are organized in distinct
*boxes* that each represent a specific UI control, such as buttons, switches,
etc. In object-oriented programming parlance, these are referred to as
*classes*. Each class has a collection of properties that can be used to change
its appearance and behavior. They also expose ways to interact with them through
functions, which are often referred to as *methods* in this context.

For instance, the `UISwitch` class represents the toggle control that is
commonly used in iOS apps. You can change its tint color through its
adequately-named `tintColor` property, and toggle its on/off status using the
`setOn(...)` method.

![UISwitch Example](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/z7oHu6QHRyHDHhIZgqMg_uiswitch-example.jpg)

Note that all UIKit classes are prefixed with "UI", making them easily
identifiable in code.

**How will this affect my day-to-day work?**

Getting familiar with programming concepts such as classes and methods will
allow you to change the look and behavior of your views in code. Even though a
thorough understanding of these concepts might not be required, it could help
shed some light on how things work below the surface.

### Views, Views Everywhere

Let's get this immediately out of the way: anything you see on screen in iOS is
a view. Buttons are views. Switches are views. Images are views. You get the
idea.

A view, represented by a class, should know how to draw itself on screen and
whether to accept user input. Most views expose properties to other parts of the
app so that their content and appearance can be updated to reflect the app
state.

Just like HTML elements, views can be nested within each other. Unlike their
HTML counterparts, most views don't inherit the appearance of their parents,
with the notable exception of `tintColor`, the property that sets the color of
interactive elements. A parent view is referred to as a *superview*, while a
child view is referred to as a *subview*. There is no limit to the number of
views you can nest, but it's always wiser to limit that number for performance
reasons. It's worth noting that parent views are only responsible of laying out
their subviews, not drawing them.

![View Nesting](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/6GrnFol1RDiUHNv66grA_ViewNesting.jpg)

In the example above, view A is the superview of view B, making the latter the
subview of the former. Views C and D are both subviews of view B.

**How will this affect my day-to-day work?**

You will need to organize your UI in a hierarchy of views to make styling and
reusing them easier down the road.

### UIView

There are cases where all you need is a blank view to use as a subview container
or a drawing canvas. For this purpose, Apple provides a base class that doesn't
do much on its own and that all other view classes should *inherit* from:
`UIView`.

While we're at it, let's talk briefly about *inheritance*. When a class is
defined as a *subclass* of another class, it inherits all of its properties and
methods. In this case, the parent class is referred to as a *superclass*.

For instance, the `UISwitch` mentioned earlier is a subclass of `UIView`. This
means that even if the [documentation][UISwitch docs] of `UISwitch` doesn't
mention anything about a `frame` property, you can still access and change that
property on any switch control, because its superclass `UIView` [defines
it][UIView frame].

![Inheritance](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/VjGwP6k8RQuGQVhd8631_Inheritance.jpg)

**How will this affect my day-to-day work?**

Custom interfaces would often require subclassing `UIView` or one of its
subclasses, so getting familiar with these is a good first step. Additionally,
when looking for a particular property or method on a view class, it's often
worth looking at its superclasses as well in the "Inherits From" section at the
top of its documentation page. See the [UISwitch example][UISwitch docs].

### Interface Builder

So, how do you add and manage views in your project? Depending on who you ask,
you will get one of these two answers:

- Using *Interface Builder* (IB for short), the built-in GUI editor in Xcode.
- Using code (Swift).

*These two approaches require different skillsets and affinities, but it's
critical to learn both in order to achieve any meaningful results*. On the one
hand, IB is far from being a stand-alone design tool in its current form, since
customizing even simple things like border width and color requires defining a
custom view in code first. On the other hand, using code for view management is
the easiest way to bloat the codebase with non-trivial layout code.

Before we delve into code, let's take a look at a hands-on example of using IB
to add a button to our UI.

![Single View App](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/7lLtLd2TQyEjpbGo7WiA_single-view-application.jpg)

You can start by creating a new "Single View Application" iOS project in Xcode
using the *File > New > Project...* menu item. The product and organization
names are irrelevant for this exercise, but they need to be there nevertheless.
You can also skip this step by downloading the freshly-created
[example project][Download Project].

![Name your app](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/gG003DE3TDy2qTVpX7tO_create-new-ios-app.jpg)

The file we will be working on is the default `Main.storyboard` which can be
opened using the project navigator in the sidebar.
*Storyboards* are a container format in IB that allows you to group all your app
screens in one large canvas and create transitions between them. They provide a
cheap but effective way to visualize the user flow and view hierarchy.

Each screen on the editor canvas is referred to as a *scene*. Our
`Main.storyboard` has exactly one scene called *View Controller Scene*, and
that's where we will be adding our first subview. You can easily list and
navigate between scenes and views using the tree view in the *Document
Outline* pane.

![Open Storyboard](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/lkCes0hSSaEaZGcl00AB_open-storyboard.jpg)

To add a new view to our scene, we need to first locate the *Object
Library*, which acts like an inventory of built-in views and controls. At the
very bottom of the right sidebar (referred to as *Utilities*), you can bring up
the Object Library by clicking the 3rd icon in the horizontal tab bar. Keep in
mind that you can show or hide both sidebars using the right-most button group
in the window top bar.

![Section Labels](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/uSp5zYvtTQuM5EFwxwQk_section-labels.jpg)

Drag-and-drop a button (`UIButton`) from the object list to the View Controller
Scene. This will effectively add a new button *instance* to our main view.

![UIButton Drag](https://images.thoughtbot.com/building-ios-interfaces-with-swift-views/1bFOM1tfT5dH3gwYbG2F_button-drag.gif)

You can preview the outcome by running the app in the *Simulator* using `Cmd+R`
or the triangle button at the top-left corner of the window. Auto Layout is
outside the scope of this article, but it's worth noting that the button is not
centered in the view because we haven't set up any layout constraints.

### Next Steps

Now that we've established that views are the bread and butter of iOS interfaces
and introduced Interface Builder with a hands-on example, it's time to take a
closer look at how we can customize our views using code. That will be the topic
of the next article in this series.

[previous post]: https://thoughtbot.com/blog/building-ios-interfaces-swift-primer
[UIView frame]: https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIView_Class/#//apple_ref/occ/instp/UIView/frame
[UISwitch docs]: https://developer.apple.com/library/ios/documentation/UIKit/Reference/UISwitch_Class/index.html#//apple_ref/occ/cl/UISwitch
[Frameworks]: https://thoughtbot.com/blog/building-ios-interfaces-swift-primer#frameworks
[Download Project]: https://github.com/thoughtbot/Swiftbot/archive/737b977458734770a58d2655de81b0f14bd68847.zip
[Part 3]: https://thoughtbot.com/blog/building-ios-interfaces-custom-button