What are the benefits of using Storyboards instead of xib files in iOS programming?

What are the main differences between using Storyboards and xib files.

Specifically, what are the advantages or disadvantages of using a Storyboard?

Unfortunately, despite doing quite a bit of research, all I've been able to find on Storyboards are simple tutorials that show you how to set up a Storyboard, instead of concrete information explaining what they are.

A Storyboard is:

• A container for all your Scenes (View Controllers, Nav Controllers, TabBar Controllers, etc)
• A manager of connections and transitions between these scenes (these are called Segues)
• A nice way to manage how different controllers talk to each other
• Storyboards give you a complete look at the flow of your application that you can never get from individual nib files floating around.
• A reducer of all the "clutter" that happens when you have several controllers each with it's own nib file.

I have been using Storyboards for awhile now and the ONLY downside is that you can't target iOS 4 or below. Storyboards only work on devices running iOS 5 or better. Other than that, the benefits are many and the downsides are non-existent IMO.

The best tutorial I have seen is Ray Wenderlich's

Also, if you are a member of the Apple Developer program, check out last years WWDC session on Storyboards (iTunesU), it is awesome.

Another great one (also on iTunesU) is the latest Stanford iOS Application Programming course.

There are not only pro sides of Storyboarding, also cons - just because you asked for input:

• it's not easy to work with SBs in a team, since only one participant can work on the SB at once (because it's one file).

-The following is not true: - if you need to do things SB doesn't offer, it's not quite easy to get SB mixed with programatical created views (well, it is possible though)

The rule of thumb seems to be: the more complex you expect your project to get, the more you'll better not go for SB.

EDIT:

• another disadvantage of SB: working around all the annoying bugs of XCode regarding SB. E.g. having to frequently flush the DerivedData folder because of several inconsistencies. Sometimes storyboard files or the link to them get corrupted. Then you might have the joy to search for the problem. Take a look at this thread to get the idea

EDIT 2 (March 2013): meanwhile Storyboards and Xcode are working much better, and documentation and best practices are wide spread. I think working with storyboard can be recommended for a majority of projects, even if there are still some glitches.

EDIT 3 (Sept 2013): now with the new Xcode 5 format working in teams with SB might get even better, as it seems to become possible to merge SB-code much easier now.

Another EDIT: well, if you have an hour of time, sit back, relax and listen to these guys discussing this topic (Ray Wenderlich & Co)

Edit 2016.1: after a long time being a Storyboard advocate, I had so much hassle with it the last months, that I decided to abandon Storyboards as far as possible. The reason for that is that Apple adds feature like stupid, but doesn't care about the bugs and the flaws. The performance having a lots of auto layout constraints is really bad (while design time), and the error-prone-ness has become huge. Example: even less complex Storyboards tend to get into a 'dirty mode' right after opening a project in Xcode (see git state). Tip: as a beginner you will love Storyboards since you can prototype quickly and get things running without lots of code. As you enter an intermediate state, you'll add more GUI code to your project. Now you start going back and forth between code and SB - and things start working out worse. Sooner or later you'll tend to do most of the GUI stuff in code, because the result is more predictable than having several sources.

#Summary#

Nibs/.xib files and Storyboards both are Interface Builder files which are used to visually create user interface for iOS and Mac applications in Xcode (i'll use iOS terminology for classes as this question is tagged iOS but it also applies to Mac programming).

###Differences### Nibs are intended to be used with a single UIView. They can also be connected to a UIViewController subclass by settings the class of File's Owner to any subclass of UIViewController and connection the view outlet (drag to connect using the Connections Inspector in the far right pane of Xcode).

Storyboards are intended to contain the user interface for 1 or more UIViewController. You can build your entire user interface in a single storyboard or separate it into smaller parts.

###Advantages### Storyboards should always be used in favor of .xib files/Nibs (for view controllers). Storyboards have more features and are actively developed by Apple.

Every argument in favor of Nibs rely of the fact that they used individually while storyboards contain many scenes. You can use a single storyboard for each UIViewController just as easily as you can with Nibs (see code samples below). Keep reading for a detailed explanation and code examples.

#Detailed Why are Storboards superior to Nibs?

The answer basically comes down to Apple encouraging the use of Storyboards and putting more development effort into them.

1. Storyboards have zooming capability which Nibs lack. Seriously, you can't zoom at all in Nibs which sucks when designing for bigger screens on a small laptop.
2. Nibs are missing key functionality like:
   • Prototype and dynamic cells for UITableView (more info)
   • The top layout guide property (see comment)
   • There are probably more, please edit or comment if you have something to add to this list
3. You don't need to mess with setting the class of Files Owner.

The basic argument against storyboards is that having all your view controllers in one place leads to merge conflicts, a slow Xcode, slow build times and being a general pain in the butt to maintain. Hence, general advice is to use a Nib for each UIViewController.

But... You can just create storyboard for each UIViewController. A common practice (for me at least) is to hide all the UIViewController initialization in a class method (as no other class needs to know the name of the file where the controller's Nib/Storyboard is located). Lets compare the related code snippets that one might use to create such a method. A single line of code is the entire difference between the two.

##Objective-C##

Storyboard

+ (ViewController *)create
{
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil];
    return [storyboard instantiateInitialViewController];
}

Nib

+ (ViewController *)create
{
    return [super initWithNibName:@"ViewController" bundle:nil];
}

Usage

- (void)showMyViewController
{
    ViewController *vc = [ViewController create];
    [self presentViewController:vc animated:YES completion:nil];
}
   

##Swift##

Storyboard

static func create() -> ViewController {
    let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle())
    return storyboard.instantiateInitialViewController() as! ViewController
}

Nib

static func create() -> ViewController {
    return ViewController(nibName: "ViewController", bundle: nil)
}

Usage

func showMyViewController() {
    let vc = ViewController.create()
    self.presentViewController(vc, animated: true, completion: nil)
}

#Arguments# I'll address all the usual arguments for Nibs; as I mentioned earlier, there are mostly in favor of single files, not as an argument for Nibs over Storyboards

1. Teams and merging

Argument: Having a storyboard with lots of view controllers will cause merge conflicts if you are working on a team with multiple people making changes

Response: A single storyboard causes no more merge conflicts than a single Nib

2. Complexity

Argument: Very complex apps have a lot of scenes in the Storyboard which leads to a giant storyboard that takes forever to load and is barely comprehensible because of it's size.

Response: This is a great point, but you can easily break Storyboards into smaller parts. Storyboard References look like a great feature that can be used to link Storyboards together but they are only available in Xcode 7/iOS 9+. Also, still not a reason to choose individual Nibs over Storyboards.

3. Reuseability

Argument: Creating a Nib for each UIViewController subclass lets you reuse code so you don't have to setup all your constraints and outlets for each scene in your storyboard.

Response: Again, not a reason to choose individual Nibs over individual Storyboards.

There was a nice presentation about Storyboard given at the LiDG meeting a couple of months ago.

Personally, I'd say it's the way to go with a new app. There are some gaps, especially for very complex apps, but the pro's mostly outweigh the cons.

Some more benefits of storyboards:

• Storyboards have better support for tableviews. That is you can use "Dynamic" and "Prototype" cells.
• It is easier to instantiate view controllers using storyboards. You can do stuff like: [se lf.storyboard instantiateViewControllerWithIdentifer:]
• Storyboards support view controller containers, so you can have child view controllers layed out graphically.

Downsides are:

• Storyboards are slow to render in XCode when they contain lots of view controllers

• Autolayout can not be enabled for one view controller in the storyboard.

Be careful, if you use Storyboards your app is not backwards compatible with older OS installations.

A storyboard is basically a device to make your job as a developer easier. It is complied into a series of nib files, so the performance is pretty much equivalent, but it's great as a developer to be able to look at a quick overview of your entire application flow.

I'm starting to transition to using storyboards on new projects, providing I can convince the client to accept iOS 5 as a minimum version. This is purely because I prefer to do it this way, and it takes me less time to accomplish the same tasks.

Your attitude toward Auto Layout may also affect whether you want to use Storyboards. Using xibs you can enabled or disable Auto Layout is on a per .xib basis, allowing for a mix within your application, while Storyboards apply your choice to ALL views they contain.

You see the big picture in one second. Having many NIB files, well, you don't see the big picture. Easier to maintain your programs. Easier to understand others programs... among others.

Advantages:

1. It's very nice to design interfaces

2. You can use StoryBoard Segues to identify navigation/modal relationships in a cool manner.

3. If your app supports multiple devices, it's a good way to organize different views.

4. Prototyping is another added advantage.

5. Prototype UITableViewCell can save time and it reduce the amount of the code too.

6. you can see all the screens of the app at one place by using StoryBoard.

7. You can easily view the relationship among them

8. if you are working on someone's code you can get the better understanding of the flow of the app.

9. You can setup the user interface for iPhone 4 and iPhone 5 by applying the retina form factor from storyboard, without running the app again and again.

10. Clients can see the prototype of the app before start developing it, here storyboard helps you a lot.

Disadvantages:

1. It is only available in iOS 5+

2. StoryBoardSegues are kind of rigid and you may make use of prepareForSegue many times.

3. Like IB, not very friendly with other display engines and toolkits.

4. Makes it hard to share designs for a single view or set of views - you have to send all or nothing.

5. For storyboard you will need a big screen specially in case of iPad.

6. Difficulty while copying views from other apps to storyboard.

7. Problems in storyboard when multiple developers work on the same project by using git repository

copied from some resource

Storyboards have many more problems than benefits. Here's is a list of their problems, copied from iraycd:

• Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLint mostly solves this problem.

• Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.

• Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.

• Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.

• Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.

• Storyboards make you do everything twice: Are you building a universal app that runs both on iPad and on iPhone? When you use storyboards, you will usually have one storyboard for the iPad version and one for the iPhone version. Keeping both in sync requires you to do every UI or app-workflow change in two places. Yay. Update: In iOS 8 and Xcode 6, you can use a single Storyboard for iPhone and iPad.

• Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.

• Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.

• Storyboards are not searchable: A project-wide search in Xcode is not really a project-wide search when you use storyboards. They are not included in the search. So when you remove a custom class from your code or rename it, you will have to manually go through the storyboard or look at its raw XML to make sure it is on par with your code changes. No sir, I don't like it. Update: Storyboards are searchable in Xcode 6.

• Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.

• Storyboards don't let you change the type of special view controllers: You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.

• Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.

• Storyboards don't allow you to add a subview to a UIImageView: Who knows why.

• Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Mazăre for this point!)

• Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)

• It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!

Prior to iOS 7, Storyboards were kind of neat but not a must have. They introduced as many problems as they solved. iOS 7 tilted the balance towards Storyboards.

With iOS 8 and 9 this is not a question anymore: Use storyboards!

The main downside of storyboard is that you're completely dependent on XCode, and you might end up spending hours spinning your wheels on XCode bugs. But XCode has gotten a lot better, and the advantages with Storyboards are now too numerous to ignore. Table view cell prototypes, Size classes, auto layout support and so on.

Some Tips:

• Think of each Storyboard as a container for view controllers that belong together. Don't think of it as a grand layout of your entire application.
• You might need more than one Storyboard
• Segues are really only useful for the most trivial use cases - they're great for that. But in a real world app many transitions will happen from within code. And that's OK.
• Write a category to programmatically instantiate view controllers from the storyboard(s) so all you have to do is let vc=SomeViewController.create(), where the method handles all the details (pull story board, pull view controller out of story board etc).