Storyboards VS. the Old Xib Way

Storyboards vs. the old XIB way

There are things you can do with a storyboard that you can't do with a nib. A storyboard lets you create segues between view controllers, and it lets you design table view cells in-place.

There are things you can do with a nib that you can't do with a storyboard. In a nib, you can create references to the File's Owner placeholder. You can create multiple top-level views, edit them, and create connections between them. See this answer for an example of why you'd want to do that. You can add external object placeholders (a rarely-used feature).

Storyboards have the drawback that they collect a bunch of different, loosely-related objects into one big file. If you're working on a project with several developers, you are much more likely to run into merge conflicts if you're using a storyboard than if you're using xib files.

You should definitely learn about nibs at some point. Whether you want to start with them or start with a storyboard is probably not too important. Just find some tutorials you like and work through them with whichever type of file (nib or storyboard) they use.

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

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.

When to use Storyboard and when to use XIBs

I have used XIBs extensively and completed two projects using Storyboards. My learnings are:

• Storyboards are nice for apps with a small to medium number of screens and relatively straightforward navigation between views.
• If you have lots of views and lots of cross-navigation between them the Storyboard view gets confusing and too much work to keep clean.
• For a large project with multiple developers I would not use Storyboards because you have a single file for your UI and cannot easily work in parallel.
• It might be worth for large apps to split up into multiple storyboard files but I have not tried that. This answer shows how to do segues between storyboards.
• You still need XIBs: In both of my Storyboard projects I had to use XIBs for custom table cells.

I think Storyboards are a step in the right direction for UI implementation and hope Apple will extend them in future iOS versions. They need to resolve the "single file" issue though, otherwise they won't be attractive for larger projects.

If I start a small size app and can afford iOS5 only compatibility, I would use Storyboards. For all other cases I stick to XIBs.

Problems going from Storyboard to XIB?

Code, storyboard and xibs are all different ways of creating views and layouts.

There is no rule that says you can only use one of them in a project.

In most of my projects I use a combination of all three.

Storyboards give a quick and easy way to create "flow" in the app. I tend to use one storyboard per "workflow" inside the app.

Xibs I tend to use for views that are common in multiple places within the app. In a storyboard I'd have to define them multiple times. Using xibs is a bit like refactoring interface builder files.

I then fall back to using code when necessary. Sometimes it isn't possible to do what I want with interface builder.

To say that you are only going to use xibs is purely denying yourself access to the other tools. Learn when to use each and how to use them together.

Should I use XIB or Storyboards at all?

You could do it all in code if you really wanted to. However the reason to use .NIB and storyboards is that it is often faster. I personally use a combination of the two. When I am doing something which is easy to do in a storyboard, I use the storyboard. If I need to add something which changes dynamically I often do it programmatically. I think by avoiding using Storyboards and NIB files you end up having to reinvent the wheel and, for me at least, probably take much longer to finish a program then just learning how to use the best tool for any given situation.

Which is more efficient way? StoryBoard or XIB?

It is not to tell which one is the best. because which one is good to tell based on team requirement.

If you are a single developer, it is good to use storyboard because it consumes less time. If the team consists of many developers, use xib, otherwise, it is not easy to merge the modules/tasks.

xcode-using-storyboards-and-xibs-versus-creating-views-programmatically

Using XIBs

Advantages:

• You can quickly put together a UI

• Straight-forward implementation for small apps with a minimal number of screens

• You can have separate XIBs for different localizations (ie. languages or countries)

• Great at laying out elements and visually spotting misalignments. It’s easy to make a slight adjustment to the layout

Disadvantages:

• It’s difficult to merge conflicts when working in a team environment (hard to diff, merge and read)

• Highly dynamic views are impossible to describe as a XIB

• Performance wise, it’s slower than creating views through code because the xib needs to be read from the disk and analysed/parsed

• XIBs lack customizations that you can do in code such as Quartz stuff (drop shadows, round corners)

• Harder to debug (i.e. if you forget to make a connection in Interface Builder or make a wrong connection)

Storyboards

Advantages:

• Storyboards are nice for apps with a small to medium amount of screens and the requirements for navigation is relatively straightforward between views

• You can mock up the flow of an application without writing much, if any, code

Disadvantages:

• Storyboards are not compatible with pre-iOS 5 so it makes supporting iOS 4.3 impossible

• It’s hard to work in parallel in a team environment because everyone’s modifying the same file

• Along the same lines, merging conflicted storyboards in GIT will be a pain

• People have experienced bugs in Xcode with the usage of storyboards (eg. having to frequently flush the DerivedData folder because of inconsistencies)

Xib Vs Storyboard, how to update

Is this what you're looking for?

(UIStoryboard *)storyboardWithName:(NSString *)name bundle:(NSBundle *)storyboardBundleOrNil

Storyboards vs. doing it in code

I'm going to split your question into two: NIBs, and storyboards.

As far as NIBs are concerned, source control issues can be painful but manageable, mainly because you've typically got one NIB file per view controller. You could imagine a situation where you have two developers working on two different sections of your NIB powered app without any merging issues. Storyboards are different, since you have one single file that describes most - if not all - of the UI of your application. Clearly there is a far greater potential for conflict issues there.

NIBs can be extremely useful and time saving, if used correctly. Here's an example: the iPhoto App on iPad has a very complex UI. The vast majority of that UI is laid out programatically. However, the app also uses NIBs to load in graphical elements which are then laid out in code. This is how the brush panel works - all the brushes are created in a NIB. This means that Apple don't have to have dozens of identical image/image view alloc/init pieces of code. All the creation can happen in a NIB (this was discussed in some detail in a WWDC 2012 session on the iPhoto UI - it's well worth tracking down).

So NIBs - sometimes good, can save you a lot of time, and whilst there are merge issues they can in many cases be easily managed and handled.

Then we come to storyboards. Storyboards are interesting. On the one hand, they are extremely helpful and useful for straightforward apps and developers new to the platform. I've just converted a UINavigationController based app from NIBs to storyboards and found some significant time savings (particularly around table views, since with storyboards you can take advantage of prototype cells).

However, if you're working on a large scale project with several developers I'm not convinced storyboards are that beneficial. There are, as you say, big issues with merge conflicts, and unlike NIBs it's not easy to resolve them since that single storyboard file controls all of your app UI.

Here's what I'd suggest (and feel free to ignore me!) - if you're currently developing apps and doing your layout/UI entirely in code consider whether NIBs might save you time. They may well not - they're not for everybody - but it's well worth at least considering. You may be surprised at how many large apps actually use NIBs (iPhoto, as I mentioned, but also many built-in apps provided by Apple, as well as many popular third party apps by large teams). I probably wouldn't consider storyboards unless you were a sole developer working on an app with fairly straightforward navigation. That's not to do down storyboards in any way - I love using them - it's just they're not really suitable for collaboration.

Somebody posted this comment in reply to your question - I wanted to discuss it:

There is nothing you can do in storyboard and can't do in code. Objects, gesture recognizers, segues, even constraints - are all available for you to build programmatically

This is technically true, but in reality there are things in storyboards/NIBs that are much easier than code. A good example of this is auto layout. Whilst you can certainly manage your auto layout contraints entirely in code, the harsh reality is that the ASCII auto layout representation is much harder to work with than the visual representation you get in IB. This is especially true on XCode 5, where there are massive improvements to auto layout in IB (I can't detail it too much as it's still under NDA, but Apple publically talk a bit about the changes here).

Can I replace all xib with storyboard

After some research and study I found that there is no such functionality in xib which cannot be replaced with storyboard. Thanks to @DonMag for comments and clue.

The only issue I was facing is to design uitableview cell, but prototype cell design can be used easily from storyboard. Here are some example how to use it.

---

Related Topics