Building iOS Interfaces: A Primer

This article is Part 1 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 2 – Part 3.

Designing for the Web has taught us the value of getting designers to write HTML/CSS and its role in improving the overall quality of the work. Waterfall workflows involving static mock-ups and hundred of megabytes of sliced assets are long gone in the modern Web design process.

Unfortunately, the same cannot be said for mobile design. A large number of designers find Xcode daunting and prefer to use other tools to prototype their designs before handing them over to a developer to implement them. Platform makers and developers are not making this task any easier; the documentation and the tools are too developer-centric and the community at large considers UI programming part of the developer’s job. It’s time to change that.

Xcode? Swift? UIKit? Oh My!

The most common question I hear when I talk to designers learning iOS is “Where do I start?”. It’s a valid question given the relatively high number of concepts involved in the process. The inability to get a definitive answer to this question often leads to giving up before starting. Nothing is more frustrating in learning than dealing with unknown unknowns—things we don’t know that we don’t know. This introduction aims to address that problem before moving on to more specific topics later.

Frameworks

Let’s start with the basics. The iOS operating system is a closed-source system built by Apple to power every single iPhone, iPad, and iPod Touch out there. It borrows heavily from its grandfather OS X, which has been running on Macs for more than a decade. In turn, the mobile OS heavily influences watchOS (Apple Watch) and tvOS (Apple TV), the newest additions to Apple’s developer toolbelt.

One of the most basic building blocks of iOS are frameworks. A framework is a self-contained collection of APIs that are intended to solve a specific problem such as controls, audio, video, animation, and so forth. Frameworks can reside within other frameworks, resulting in a hierarchy that can easily get confusing if one is not paying attention.

The top-level framework in iOS is called Cocoa Touch, in contrast to Cocoa for OS X. Cocoa Touch hosts all the frameworks you will be dealing with as a UI designer, including Foundation, UIKit, and Core Animation.

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

You will need to import some of these frameworks in your files to have access to certain APIs. For iOS, UIKit is going to be the most common import.

Languages

Now that we have identified the frameworks we are going to use, we need a way to communicate with them. That’s where the programming language comes in. Throughout the years, developers have been able to use languages such as C, Objective-C, and even C++ to call the built-in APIs.

In 2014, Apple introduced Swift as a modern take on their official programming language, and most of their frameworks were updated to take advantage of it.

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

You will need to get familiar with Swift and have some basic understanding of how object-oriented programming works. These may sound daunting at first, but they’re not in actuality; not if you’ve dealt with CSS centering and JavaScript, anyway. Here is an example of a Swift file:

import UIKit

class MyButton: UIButton {
  override func awakeFromNib() {
    super.awakeFromNib()
    backgroundColor = UIColor.yellowColor()
  }
}

The code snippet above defines a new button subclass and makes its default background color yellow. Concepts introduced here include classes and inheritance and are beyond the scope of this introductory article, but are nonetheless essential to take full advantage of the framework APIs.

Software Tools

So far we’ve got frameworks and a language to communicate with them. What we need now is a way to bring these ingredients together to build our UI. Enter Xcode.

Xcode is, for better or worse, the only officially-supported editor for building iOS apps. It’s feature-packed and includes all the first-party frameworks you need to get started. The name is in fact misleading, since the part where you’ll be spending most of your time doesn’t even require writing code: Interface Builder.

Interface Builder allows you build interfaces in a visual way that involves dropping different controls into a canvas and styling them—to a certain degree—without having to write any code. Not everything would work like your favorite graphic editor, but the similarities are there.

A large part of what we do when designing interfaces is layout. For that purpose, Apple has built Auto Layout, a constraint-based system that describes the relationship between views rather than their absolute frames.

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

You will be spending most of your time between your graphic editor and Xcode. Also, Auto Layout is going to be a major part of everything you are likely to touch.

Recap

We’ve gone over the tools and technologies that you need to get familiar with in order to feel more comfortable implementing your iOS designs. You might still be wondering about the order in which you should tackle these—a legitimate question that, if left unanswered, might hinder the learning process, or worse, stop it. Let’s get the bad news out of the way first:

• Getting familiar with all the concepts and tools introduced above is required to fully unlock the potential of the platform.
• With the exception of Swift, it’s hard to disassociate these technologies from each other in the learning process.

Now for the good news:

• Basic Swift is a low-hanging fruit to go for.
• The best way to learn about the frameworks is to use them.
• The learning order matters less when you have a clear goal in mind.
• The frameworks that you will be using are very well documented.

All things considered, one of the most fundamental things in learning is understanding the why. Alas, most of the resources out there are cookie-cutter recipes that focus entirely on the how. Hopefully, this series will set you on the right path to address this very problem.