Chapter
2
Storyboards: Appearance
One of the things that makes developing for Apple’s platforms different from other styles of programming is where you begin. You don’t start with data models, architecture, logic, or what have you; you start with the user interface. This has been a guiding principle of Mac development for decades, and it was inherited by iOS, tvOS, and watchOS. Think about what the user sees and does, then figure out how to make that happen. This is one of the secrets why people like apps on these platforms—thinking in terms of the user experience helps developers always look at the app through the user’s eyes.
For developers, that means opening Main.storyboard, and working in the Interface Builder, Xcode’s user interface editor. This is where you create the app’s storyboards. In this chapter, you’ll work with a single storyboard; in the next chapter, you’ll learn how to add more. With Interface Builder, we can visually sketch out how the app is going to look, what the user will see, and even how they’ll move around between scenes. With the UI prepared, you can move on to coding application logic in view controllers, data models, helper functions, and so on.
Yes, you can. Also, please don’t.
It’s a somewhat common sight on Twitter to see developers trashing Interface Builder, asserting that building their UI programmatically is more performant, less buggy, or that they have some other compelling reason to do so. And it is indeed possible. After all, what IB actually does is create and configure instances of the various UI classes and stores them in XML, so they can be loaded at runtime. A UI built entirely in code simply moves this step from design-time to runtime. That’s totally legal.
Thing is, IB does a lot for you: it lets you build your UIs visually (instead of choosing fonts and colors in code), it lets you preview your UIs on the entire range of devices, evaluates your auto layout constraints and finds problems at design-time rather than runtime, it makes it easier to internationalize by letting you totally rework your UI for specific localizations if needed, and so on.
There are times when building some part of your UI in code is necessary, since there are things that IB can’t do well (or at all). But these are uncommon. And with the exception of some games—those which don’t use UIKit and instead build an entire UI layer of their own in Open GL or Metal—it’s unlikely that you’ll be well-served by abandoning storyboards and IB entirely.
…and always be suspicious of self-appointed expert developers on Twitter and Stack Overflow.