Storyboards Tutorial in Swift: Part 2

Storyboards Tutorial in Swift: Part 2


Update note: This tutorial was updated to iOS 8 and Swift by Caroline Begbie. Original post by Tutorial Team member Matthijs Hollemans.

If you want to learn about storyboards, you’ve come to the right place!

In the first part of this storyboards tutorial series, you covered the basics of using Interface Builder to create and connect various view controllers, along with how to make custom table view cells directly from the storyboard editor.

In this second and final part of this storyboards tutorial series, we’ll cover segues, static table view cells, the Add Player screen, and a game picker screen!

We’ll start where we left off last tutorial, so open your project from last time, or download the example code from the previous tutorial first.

OK, let’s dive into some of the other cool features in storyboards!

Introducing Segues

It’s time to add more view controllers to the storyboard. You’re going to create a screen that allows users to add new players to the app.

Open up Main.storyboard and drag a Bar Button Item into the right slot of the navigation bar on the Players scene with your table view. In the Attributes inspector change its Identifier to Add to make it a standard + button.

Add button

When the user taps this button, you want the app to pop up a new modal screen for entering details of a new player.

Drag a new Navigation Controller into the canvas to the right of the Players scene. Remember that you can double-click the canvas to zoom out so you have more room to work. This new Navigation Controller comes with a Table View Controller attached, so that’s handy.

Here’s the trick: Select the + button that you just added on the Players screen and ctrl-drag to the new Navigation Controller. Release the mouse button and a small popup menu shows up. Select modal from the popup menu:

Reminder: You can’t add to or modify the contents of a storyboard when zoomed out. If you’re having issues creating the segue, try double clicking to zoom back in!

Add button drag

This places a new arrow between the Players screen and the Navigation Controller:

Modal relationship

This type of connection is known as a segue (pronounce: seg-way) and represents a transition from one screen to another. The storyboard connections you’ve seen so far were relationships and they described one view controller containing another. A segue, on the other hand, changes what is on the screen. Segues are triggered by taps on buttons, table view cells, gestures, and so on.

The cool thing about using segues is that you no longer have to write any code to present the new screen, nor do you have to hook up your buttons to IBAction methods. What you just did, dragging from the Bar Button Item to the next screen, is enough to create the transition. (Note: If your control already had an IBAction connection, then the segue overrides that.)

Run the app and press the + button. A new table view will slide up the screen.

Modal appears

This is a so-called “modal” segue. The new screen completely obscures the previous one. The user cannot interact with the underlying screen until they close the modal screen first. Later on you’ll also see “push” segues that push new screens on the navigation stack of a Navigation Controller.

The new screen isn’t very useful yet – you can’t even close it to go back to the main screen. That’s because segues only go one way – so while it can go from the Players scene to this new one, it can’t go back.

Storyboards provide the ability to ‘go back’ with something called an unwind segue, which you’ll implement next. There are three main steps:

  1. Create an object for the user to select, usually a button.
  2. Create an unwind method in the controller that you want to return to.
  3. Hook up the method and the object in the storyboard.

First, open Main.storyboard and select the new Table View Controller scene (the one that says “Root View Controller”). Change the title of the screen to Add Player (by double-clicking in the navigation bar). Then add two Bar Button Items to the navigation bar. In the Attributes inspector, set the Identifier of the button to the left to Cancel, and the one on the right to Done (also change this one’s Style from Bordered to Done).

Cancel and done buttons

Next, add a new file to the project using the Cocoa Touch Class template – name it PlayerDetailsViewController and make it a subclass of UITableViewController. To hook this new class up to the storyboard, switch back to Main.storyboard and select the Add Player scene. In the Identity inspector set its Class to PlayerDetailsViewController. I always forget this very important step, so to make sure you don’t; I’ll keep pointing it out.

Now you can finally create the unwind segue. In PlayersViewController.swift (not the detail controller), add the unwind methods just below the class definition:

@IBAction func cancelToPlayersViewController(segue:UIStoryboardSegue) {
  dismissViewControllerAnimated(true, completion: nil)
@IBAction func savePlayerDetail(segue:UIStoryboardSegue) {
  dismissViewControllerAnimated(true, completion: nil)

Both of these methods simply dismiss the controller when called. Later, you’ll make some changes to savePlayerDetail to allow it to live up to it’s name!

Lastly, switch back to Interface Builder and hook up the Cancel and Done buttons to their respective action methods. Ctrl-drag from the bar button to the exit object above the view controller and then pick the correct action name from the popup menu:

Make connections

Note the name that you gave the cancel method. When you create an unwind segue, the list will show all unwind methods (ie ones with the signature @IBAction func methodname(segue:UIStoryboardSegue)) in the entire app, so ensure that you create a name that you recognize.

Run the app, press the + button, and test the Cancel and Done buttons. A lot of functionality for very little code!

Static Cells

When you’re finished with this section, the Add Player screen will look like this:

Add Player screen

That’s a grouped table view, of course, but you don’t have to create a data source for this table. You can design it directly in Interface Builder — no need to write cellForRowAtIndexPath for this one. The feature that makes this possible is called static cells.

Select the table view in the Add Player scene and in the Attributes inspector change Content to Static Cells. Change Style from Plain to Grouped and give the table view 2 sections.

Static cells

When you change the value of the Sections attribute, the editor will clone the existing section. (You can also select a specific section in the Document Outline on the left and duplicate it.)

The finished screen will have only one row in each section, so select the superfluous cells and delete them either using the canvas or the Document Outline.

Select the top-most Table View Section (from the Document Outline). In its Attributes inspector, give the Header field the value Player Name.


Drag a new Text Field into the cell for this section. Stretch out its width and remove its border so you can’t see where the text field begins or ends. Set the Font to System 17.0 and uncheck Adjust to Fit.

Player Name Cell

You’re going to make an outlet for this text field on the PlayerDetailsViewController using the Assistant Editor feature of Xcode. While still in the storyboard, open the Assistant Editor with the button from the toolbar (the one that looks like a tuxedo / alien face). It should automatically open on PlayerDetailsViewController.swift (if it doesn’t, use the jumpbar in the right hand split window to select that .swift file).

Select the new text field and ctrl-drag to the top of the .swift file, just below the class definition. When the popup appears, name the new outlet nameTextField, and click Connect. After you click Connect, Xcode will add the property to the PlayersDetailViewController class and connect to it in the storyboard:


Creating outlets for views on your table cells is exactly the kind of thing I said you shouldn’t try with prototype cells, but for static cells it is OK. There will be only one instance of each static cell and so it’s perfectly acceptable to connect their subviews to outlets on the view controller.

Set the Style of the static cell in the second section to Right Detail. This gives you a standard cell style to work with. Change the label on the left to read Game by double clicking it and give the cell a Disclosure Indicator accessory.


Just as you did for the Name text field, make an outlet for the label on the right (the one that says “Detail”) and name it detailLabel. The labels on this cell are just regular UILabel objects. You might need to click a few times on the text “Detail” to select the label (and not the whole cell) before cntl clicking and dragging to PlayerDetailsViewController.swift. Once done, it will look something like this:


The final design of the Add Player screen looks like this:


The screens you have designed so far in this storyboard all have the width and height of the 4-inch screen of the iPhone 5, which is 568 points tall. Obviously, your app should work properly with all the different screen sizes, and you can preview all these sizes within your Storyboard.

Open the Assistant Editor from the toolbar, and use the jump bar to select Preview. At the bottom left of the assistant editor, click the + symbol to add new screen sizes to preview. To remove a screen size, select it and hit the Delete key.


For the Ratings app, you don’t have to do anything fancy. It only uses table view controllers and they automatically resize to fit the screen space. When you do need to support different layouts for different sized devices, you will use Auto Layout and the new Size Classes.

Build and run now, and you’ll notice that the Add Player screen is still blank!
add player blank

When you use static cells, your table view controller doesn’t need a data source. Because you used an Xcode template to create the PlayerDetailsViewController class, it still has some placeholder code for the data source and that will prevent the static cells from working properly – that’s why your static content wasn’t visible here. Time to fix it!

Open PlayerDetailsViewController.swift and delete everything from the following line down (except for the class closing bracket):

// MARK: - Table view data source

That should silence Xcode about the warnings it has been giving ever since you added this class to the project.

Run the app and check out the new screen with the static cells. All without writing a line of code – in fact, you threw away a bunch of code!

One more thing about static cells: they only work in UITableViewController. Even though Interface Builder will let you add them to a Table View object inside a regular UIViewController, this won’t work during runtime. The reason for this is that UITableViewController provides some extra magic to take care of the data source for the static cells. Xcode even prevents you from compiling such a project with the error message: “Illegal Configuration: Static table views are only valid when embedded in UITableViewController instances”.

Prototype cells, on the other hand, work just fine in a table view that you place inside a regular view controller. Neither work for nibs, though. At the moment, if you want to use prototype cells or static cells, you’ll have to use a storyboard.

It is not unthinkable that you might want to have a single table view that combines both static cells and regular dynamic cells, but this isn’t very well supported by the SDK. If this is something you need to do in your own app, then see this post on the Apple Developer Forums for a possible solution.

Note: If you’re building a screen that has a lot of static cells — more than can fit in the visible frame — then you can scroll through them in Interface Builder with the scroll gesture on the mouse or trackpad (2 finger swipe). This might not be immediately obvious, but it does work.

You can’t always avoid writing code altogether though, even for a table view of static cells. When you dragged the text field into the first cell, you probably noticed it didn’t fit completely. There is a small margin of space around the text field. The user can’t see where the text field begins or ends, so if they tap in the margin and the keyboard doesn’t appear, they’ll be confused.

To avoid that, you should let a tap anywhere in that row bring up the keyboard. That’s pretty easy to do – just open PlayerDetailsViewController.swift and add a tableView(_:didDeselectRowAtIndexPath:) method as follows:

override func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
  if indexPath.section == 0 {

This just says that if the user tapped the first cell, the app should activate the text field. There is only one cell in the section so you only need to test for the section index. Making the text field the first responder will automatically bring up the keyboard. It’s just a little tweak, but one that can save users a bit of frustration.

Tip: when adding a delegate method, or overriding a view controller method, just start typing the method name (without preceding it with “func”), and then you will be able to select the correct method from the list available.

You should also set the Selection Style for that cell to None (instead of Default) in the storyboard Attributes inspector, otherwise the row appears highlighted if the user taps in the margin around the text field.

Selection Style

All right, that’s the design of the Add Player screen. Now let’s actually make it work.

The Add Player Screen at Work

For now you will ignore the Game row and just let users enter the name of the player.

When the user presses the Cancel button the screen should close and whatever data they entered will be lost. That part already works with the unwind segue.

When the user presses Done, however, you should create a new Player object and fill in its properties and update the list of players.

The prepareForSegue(:sender:) method is invoked whenever a segue is about to take place. You’ll override this method to store the data entered into a new Player object before dismissing the view.

Note: You never call prepareForSegue yourself. It’s a message from UIKit to let you know that a segue has just been triggered.

Inside PlayerDetailsViewController.swift, first add a property at the top of the class:

var player:Player!

This does not instantiate the property but the exclamation mark, defining it as an implicitly unwrapped optional, means that it must be instantiated and have a value before using it.

Next, add the following method to PlayerDetailsViewController.swift:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
  if segue.identifier == "SavePlayerDetail" {
    player = Player(name: self.nameTextField.text, game: "Chess", rating: 1)

The prepareForSegue(_:sender:) method creates a new Player instance with default values for game and rating. It does this only for a segue that has the identifier of SavePlayerDetail. If you were to run the application at this point, it would crash, because you don’t have any identifier called "SavePlayerDetail".

Tip: If you get mysterious crashes that you can’t track down, often they come from having deleted or changed names of objects in the code so that the storyboard does not reference the correct object any more.

In Main.storyboard, find the Add Player scene in the Document Outline and select the unwind segue tied to the savePlayerDetail Action. Change its identifier to "SavePlayerDetail":


Next, select the unwind segue tied to cancelToPlayersViewController, and change the identifier to CancelPlayerDetail. This is necessary now, as the prepareForSegue(_:sender:) method tests the identifier string, and if it does not have one, the app will crash.

Hop over to PlayersViewController and change the unwind segue method savePlayerDetail(segue:) to look like this:

@IBAction func savePlayerDetail(segue:UIStoryboardSegue) {
  let playerDetailsViewController = segue.sourceViewController as PlayerDetailsViewController
  //add the new player to the players array
  //update the tableView
  let indexPath = NSIndexPath(forRow: players.count-1, inSection: 0)
  tableView.insertRowsAtIndexPaths([indexPath], withRowAnimation: .Automatic)
  //hide the detail view controller
  dismissViewControllerAnimated(true, completion: nil)

This obtains a reference to the PlayerDetailsViewController via the segue reference passed to the method. It uses that to add the new Player object to the array of players used in the datasource. Then it tells the table view that a new row was added (at the bottom), because the table view and its data source must always be in sync.

You could have just done tableView.reloadData() but it looks nicer to insert the new row with an animation. UITableViewRowAnimation.Automatic automatically picks the proper animation, depending on where you insert the new row. Very handy.

Try it out, you should now be able to add new players to the list!



Now that you have several view controllers in the storyboard, you might be wondering about performance. Loading a whole storyboard at once isn’t a big deal. The Storyboard doesn’t instantiate all the view controllers right away – only the initial view controller is immediately loaded. Because your initial view controller is a Tab Bar Controller, the two view controllers that it contains are also loaded (the Players scene from the first tab and the scene from the second tab).

The other view controllers are not instantiated until you segue to them. When you close these view controllers they are immediately deallocated, so only the actively used view controllers are in memory, just as if you were using separate nibs.

Let’s see that in practice. Add an initializer and deinitializer to PlayerDetailsViewController:

required init(coder aDecoder: NSCoder) {
  println("init PlayerDetailsViewController")
  super.init(coder: aDecoder)
deinit {
  println("deinit PlayerDetailsViewController")

You’re overriding init(coder:) and deinit, and making them log a message to the Xcode Debug pane. Now run the app again and open the Add Player screen. You should see that this view controller did not get allocated until that point.

When you close the Add Player screen, either by pressing Cancel or Done, you should see the println() from deinit. If you open the screen again, you should also see the message from init(coder:) again. This should reassure you that view controllers are loaded on-demand only, just as they would if you were loading nibs by hand.

Note: If you’ve worked with nibs before, then init(coder:) will be familiar. That part has stayed the same with storyboards; init(coder:), awakeFromNib(), and viewDidLoad() are still the methods to use. You can think of a storyboard as a collection of nibs with additional information about the transitions and relationships between them. But the views and view controllers inside the storyboard are still encoded and decoded in the same way.

The Game Picker Screen

Tapping the Game row in the Add Player screen should open a new screen that lets the user pick a game from a list. That means you’ll be adding yet another table view controller, although this time you’re going to push it on the navigation stack rather than show it modally.

Drag a new Table View Controller into the storyboard. Select the Game table view cell in the Add Player screen (be sure to select the entire cell, not one of the labels) and ctrl-drag to the new Table View Controller to create a segue between them. Make this a Push segue (under Selection Segue in the popup, not Accessory Action) and give it the identifier PickGame from the Attribute Inspector for the segue.

Double-click the navigation bar and name this new scene Choose Game. Set the Style of the prototype cell to Basic, and give it the reuse identifier GameCell. That’s all you need to do for the design of this screen:


Add a new Swift file to the project, using the Cocoa Touch Class template and name it GamePickerViewController, subclass of UITableViewController. Go back to your new Choose a Game scene in the storyboard and set its Custom Class to GamePickerViewController.

Now let’s give this new screen some data to display. In GamePickerViewController.swift, add a games property to the top and override the viewDidLoad function so that the beginning of the class looks like this:

var games:[String]!
override func viewDidLoad() {
  games = ["Angry Birds",
           "Russian Roulette",
           "Spin the Bottle",
           "Texas Hold'em Poker",

You just added a new String dictionary called games and populated it with some hardcoded values in viewDidLoad().

Now replace the data source methods from the template with:

override func numberOfSectionsInTableView(tableView: UITableView) -> Int {
  return 1
override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
  return games.count
override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
  let cell = tableView.dequeueReusableCellWithIdentifier("GameCell", forIndexPath: indexPath) as UITableViewCell
  cell.textLabel?.text = games[indexPath.row]
  return cell

Standard stuff here – you’re just setting up the data source to use the games array and placing the string values in the cell’s textLabel.

That should do it as far as the data source is concerned. Run the app and tap the Game row. The new Choose Game screen will slide into view. Tapping the rows won’t do anything yet, but because this screen is presented on the navigation stack, you can always press the back button to return to the Add Player screen.


This is pretty cool, huh? You didn’t have to write any code to invoke this new screen. You just ctrl-dragged from the static table view cell to the new scene and that was it. The only code you wrote was to populate the contents of the tableView, which is typically something more dynamic rather than a hardcoded list.

Of course, this new screen isn’t very useful if it doesn’t send any data back, so you’ll have to add a new unwind segue for that.

At the top of the GamePickerViewController class, add properties to hold the name and the index of the currently selected game:

var selectedGame:String? = nil
var selectedGameIndex:Int? = nil

Next, change cellForRowAtIndexPath: to:

override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
  let cell = tableView.dequeueReusableCellWithIdentifier("GameCell", forIndexPath: indexPath) as UITableViewCell
  cell.textLabel?.text = games[indexPath.row]
  if indexPath.row == selectedGameIndex {
    cell.accessoryType = .Checkmark
  } else {
    cell.accessoryType = .None
  return cell

This sets a checkmark on the cell that contains the name of the currently selected game. Small gestures such as these will be appreciated by the users of the app.

Now add the tableview(tableview:didSelectRowAtIndexPath:) method:

override func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
  tableView.deselectRowAtIndexPath(indexPath, animated: true)
  //Other row is selected - need to deselect it
  if let index = selectedGameIndex {
    let cell = tableView.cellForRowAtIndexPath(NSIndexPath(forRow: index, inSection: 0))
    cell?.accessoryType = .None
  selectedGameIndex = indexPath.row
  selectedGame = games[indexPath.row]
  //update the checkmark for the current row
  let cell = tableView.cellForRowAtIndexPath(indexPath)
  cell?.accessoryType = .Checkmark

First this deselects the row after it was tapped. That makes it fade from the gray highlight color back to the regular white. Then it removes the checkmark from the cell that was previously selected, and puts it on the row that was just tapped.

Run the app now to test that this works. Tap the name of a game and its row will get a checkmark. Tap the name of another game and the checkmark moves along with it.


The screen ought to close as soon as you tap a row but that doesn’t happen yet because you haven’t actually hooked up an unwind segue. Sounds like a great next step!

In PlayerDetailsViewController.swift, at the top of the class, add a property to hold the selected game so that you can store it in the Player object later. Give it a default of “Chess” so you always have a game selected for new players.

var game:String = "Chess"

In the same file, change viewDidLoad() to display the name of the game in the static table cell:

override func viewDidLoad() {
  detailLabel.text = game

Add the unwind segue method:

@IBAction func selectedGame(segue:UIStoryboardSegue) {
  let gamePickerViewController = segue.sourceViewController as GamePickerViewController
  if let selectedGame = gamePickerViewController.selectedGame {
    detailLabel.text = selectedGame
    game = selectedGame

This code will get executed once the user selects a game from the Choose Game Scene. This method updates both the label on screen and the game property based on the game selected. It also pops the GamePickerViewController off the navigation controller’s stack.

In Main.storyboard, ctrl-drag from the tableview cell to the Exit as you did before, and choose selectedGame: from the popup list:


Give the unwind segue the name “SaveSelectedGame”.

Run the app to check it out so far. Create a new player, select the player’s game row and choose a game.


Unfortunately, the unwind segue method is performed before the tableView(_:didSelectRowAtIndexPath:) method, so that the selectedGameIndex is not updated in time. Fortunately, you can override prepareForSegue(_:sender:) and complete that operation before the unwind happens.

In GamePickerViewController, add the prepareForSegue(segue:) method:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
  if segue.identifier == "SaveSelectedGame" {
    let cell = sender as UITableViewCell
    let indexPath = tableView.indexPathForCell(cell)
    selectedGameIndex = indexPath?.row
    if let index = selectedGameIndex {
      selectedGame = games[index]

The sender parameter of prepareForSegue(_:sender:) is the object that initiated the segue, which in this case was the game cell that was selected. So you can use that cell’s indexPath to locate the selected game in the games array then set selectedGame so it is available in the unwind segue.

Now when you run the app and select the game, it will update the player’s game details!


Next, you need to change the PlayerDetailsViewController’s prepareForSegue method to return the selected game, rather than the hardcoded “Chess”. This way, when you complete adding a new player, their actual game will be displayed on the Players scene.

In PlayerDetailsViewController.swift, change prepareForSegue(_:sender:) to this:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
  if segue.identifier == "SavePlayerDetail" {
    player = Player(name: nameTextField.text, game:game, rating: 1)

When you complete the Add Player screen and press done, the list of players will now update with the correct game.

One more thing – when you choose a game, return to the Add Player screen, then try to choose a game again, the game you chose before should have a checkmark by it. The solution is to pass the selected game stored in PlayerDetailsViewController over to the GamePickerViewController when you segue.

Still in PlayerDetailsViewController.swift, add this to the end of that prepareForSegue(segue:,sender:) method:

if segue.identifier == "PickGame" {
  let gamePickerViewController = segue.destinationViewController as GamePickerViewController
  gamePickerViewController.selectedGame = game

Note that you now have two if statements checking segue.identifier. SavePlayerDetail is the unwind segue going back to the Players list, and PickGame is the push segue going forwards to the Game Picker screen. The code you added will set the selectedGame on the GamePickerViewController just before that view is loaded.

Now open GamePickerViewController.swift and add the following lines to the bottom of viewDidLoad():

if let game = selectedGame {
  selectedGameIndex = find(games, game)!

This takes the selectedGame you passed in from the PlayerDetailsViewController and translates it to an index that will be used to place a checkmark on that game. The find() will search the games array for a String matching selectedGame and will set the selectedGameIndex to the index where the match was found. You’ll use that index to set a checkmark in the table view cell.

Awesome. You now have a functioning Choose Game screen!


Where To Go From Here?

Here is the final Ratings iOS 8 example project with all of the code from the above tutorial.

Congratulations, you now know the basics of using the Storyboard Editor, and can create apps with multiple view controllers transitioning between each other with segues! Editing multiple view controllers and their connections to each other in one place makes it easy to visualize your app as a whole.

You’ve also seen how easy it is to customize table views and table view cells. Static cells also make it easy to set up an interface without implementing all the data source methods.

If you want to learn more about Storyboards, check out our book iOS 8 by Tutorials, where you’ll find the latest on universal storyboards.

If you have any questions or comments on this tutorial or on storyboards in general, please join the forum discussion below!

Storyboards Tutorial in Swift: Part 2 is a post from: Ray Wenderlich

The post Storyboards Tutorial in Swift: Part 2 appeared first on Ray Wenderlich.



Write a comment