Storyboards Tutorial in iOS 7: Part 1

Note from Ray: Tutorial Team member Matthijs Hollemans (the iOS Apprentice Series author) has ported this popular tutorial from iOS 5 by Tutorials to iOS 7. This is a sneak peek of the third edition of the book, which will be updated to iOS 7. We hope you enjoy!

Storyboarding is an exciting feature first introduced with iOS 5 that saves you a lot of time building user interfaces for your apps.

To show you what a storyboard is, I’ll let a picture do the talking. This is the storyboard that you will be building in this tutorial:

You may not know exactly yet what the app does but you can clearly see which screens it has and how they are related. That is the power of using storyboards.

If you have an app with many different screens then storyboards can help reduce the amount of glue code you have to write to go from one screen to the next. Instead of using a separate nib file for each view controller, your app uses a single storyboard that contains the designs of all of these view controllers and the relationships between them.

Storyboards have a number of advantages over regular nibs:

• With a storyboard you have a better conceptual overview of all the screens in your app and the connections between them. It’s easier to keep track of everything because the entire design is in a single file, rather than spread out over many separate nibs.
• The storyboard describes the transitions between the various screens. These transitions are called “segues” and you create them by simply ctrl-dragging from one view controller to the next. Thanks to segues you need less code to take care of your UI.
• Storyboards make working with table views a lot easier with the new prototype cells and static cells features. You can design your table views almost completely in the storyboard editor, something else that cuts down on the amount of code you have to write.

Not everything is perfect, of course, and storyboards do have some limitations. The storyboard version of Interface Builder isn’t as powerful as the old nib editor and there are a few handy things nibs can do that storyboards unfortunately can’t. You also need a big monitor, especially when you write iPad apps!

If you’re the type who hates Interface Builder and who really wants to create his entire UI programmatically, then storyboards are probably not for you. Personally, I prefer to write as little code as possible — especially UI code! — so this tool is a welcome addition to my arsenal.

And if you want to keep using nibs then go right ahead, but know that you can combine storyboards with nibs. It’s not an either-or situation.

In this tutorial you’ll take a look at what you can do with storyboards. You’re going to build a simple app that lets you create a list of players and games, and rate their skill levels. In the process, you’ll learn the most common tasks that you’ll be using storyboards for.

Storyboards tutorial: iOS 7 style

Fire up Xcode and create a new project. You’ll use the Single View Application template as the starting point and then build up the app from there.

Fill in the template options as follows:

• Product Name: Ratings
• Organization Name: fill this in however you like
• Company Identifier: the identifier that you use for your apps, in reverse domain notation
• Class Prefix: leave this empty
• Devices: iPhone

With previous versions of Xcode you had to specifically choose to use storyboards in the new project, but as of Xcode 5 this no longer an option; storyboards are enabled by default.

After Xcode has created the project, the main Xcode window looks like this:

The new project consists of two classes, AppDelegate and ViewController, and the star of this tutorial: the Main.storyboard file. Notice that there are no .xib files in the project.

This is a portrait-only app, so before you continue, uncheck the Landscape Left and Landscape Right options under Deployment Info, Device Orientation.

Let’s take a look at that storyboard. Click Main.storyboard in the list of files to open it in Interface Builder:

Editing storyboards in Interface Builder works pretty much the same way as editing nibs. You can drag new controls from the Object Library (see bottom-right corner) into your view controller to design its layout. The difference is that the storyboard doesn’t contain just one view controller from your app, but all of them.

The official storyboard terminology for a view controller is “scene”, but you can use the terms interchangeably. The scene is what represents the view controller in the storyboard. Previously you would use a separate nib for each scene / view controller, but now they are all combined into a single storyboard.

On the iPhone only one of these scenes is visible at a time, but on the iPad you can show several at once, for example the master and detail panes in a split-view, or the content of a popover.

Note: Xcode 5 enables Auto Layout by default for storyboard and nib files. Auto Layout is a cool new technology for making flexible user interfaces that can easily resize, which is useful on the iPad and for supporting the larger iPhone 5, but it only works on iOS 6 and up. It also has a bit of a learning curve, which is why you’re not using it in this tutorial. To learn more about Auto Layout, see our books iOS 6 by Tutorials and iOS 7 by Tutorials.

Disable Auto Layout from the File inspector for the storyboard:

To get some feel for how the storyboard editor works, drag some controls into the blank view controller:

Find this button at the bottom of the storyboard canvas:

Click it to open the Document Outline in the sidebar on the left:

When editing a nib this area lists just the components from that one nib, but for a storyboard it shows the contents of all your view controllers. Currently there is only one view controller (or scene) in your storyboard but in the course of this tutorial you’ll be adding several others.

There is a miniature version of this Document Outline below the scene, named the Dock:

The Dock shows the top-level objects in the scene. Each scene has at least a View Controller object, a First Responder object, and an Exit item, but it can potentially have other top-level objects as well. The Dock is convenient for making connections to outlets and actions. If you need to connect something to the view controller, you can simply drag to its icon in the Dock.

Note: You probably won’t be using the First Responder very much. This is a proxy object that refers to whatever object has first responder status at any given time. It was also present in your nibs and you probably never had a need to use it then either. As an example, you can hook up the Touch Up Inside event from a button to First Responder’s cut: selector. If at some point a text field has input focus then you can press that button to make the text field, which is now the first responder, cut its text to the pasteboard.

Run the app and it should look exactly like what you designed in the editor (shown here on the 4-inch Retina iPhone simulator running iOS 7.0):

If you’ve ever made a nib-based app before then you always had a MainWindow.xib file. This nib contained the top-level UIWindow object, a reference to the App Delegate, and one or more view controllers. When you put your app’s UI in a storyboard, however, MainWindow.xib is no longer used. So how does the storyboard get loaded by the app?

Let’s take a peek at the application delegate. Open up AppDelegate.h and you’ll see it looks like this:

#import <UIKit/UIKit.h>

@interface AppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) UIWindow *window;

@end

It is a requirement for using storyboards that your application delegate inherits from UIResponder and that it has a UIWindow property. If you look into AppDelegate.m, you’ll see that it does absolutely nothing. All the methods are practically empty. Even application:didFinishLaunchingWithOptions: simply returns YES.

The secret is in the Ratings-Info.plist file. Click on Ratings-Info.plist (you can find it in the Supporting Files group) and you’ll see this:

Storyboard apps use the key UIMainStoryboardFile, or “Main storyboard file base name”, to specify the name of the storyboard that must be loaded when the app starts. When this setting is present, UIApplication will load the named storyboard file and automatically instantiates the first view controller from that storyboard, then puts its view into a new UIWindow object. No programming necessary.

You can also see this in the Project Settings screen in the Deployment Info section:

For the sake of completeness, also open main.m to see what’s in there:

#import <UIKit/UIKit.h>

#import "AppDelegate.h"

int main(int argc, char *argv[])
{
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

The app delegate is not part of the storyboard. You have to pass the name of your app delegate class to UIApplicationMain(), otherwise it won’t be able to find it.