As any developer knows, it’s critical to give due consideration to your tools, making sure you’re using the most approriate tool for the job at hand. When building interfaces for iOS or OS X there are currently three tools at your disposal: nib files, storyboards and good ol’ vanilla Objective-C. In this article I put nib files head-to-head with storyboards, highlighting the advantages and disadvantages of each.

When to use nibs

Nib files generally represent the visual objects of your application, such as UIView and it’s many subclasses. That’s not to say you can’t have other classes inside of your nibs as well. Views are often accompanied by their controller counterparts; UIViewController and friends. Nibs are incredibly flexible and can be used to store an entire interface, a single custom control, or any variation in-between.

It’s considered bad practice to store unrelated screens, views or controls within the same nib file due to the simple fact that when it’s needed, it’s entire contents are loaded into memory including any resources such as images and sounds. Therefore you should always try and modularise your nibs files, separating out related content into individual nibs, and keeping each one as slim as possible. It’s also recommended that you store repeated user-interface components, such as instances of UITableViewCell in separate nibs. As they’re loaded lazily, it will help keep the time it takes to unarchive them to a minimum, and maintain your apps responsiveness and efficiency.

Favouring Nibs Over Storyboards

Whilst nibs are ideal for storing views, subviews and custom controls, they’re not able to properly represent the relationship between multiple screens of related content. Instead, this must be done in code. This can often increase the complexity of your code, making it harder for others to read and follow. As Kris Gale of Yammer expresses in his discussion of traditional engineering practices these can introduce great cost to your organisation that you must consider. So make sure you’re taking full advantage of the strengths of using nib files, and minimising your exposure to their weaknesses.

The final consideration of using nib files is that of backward compatibility. Nibs are available in all versions of the iOS SDK, past and present, and can therefore be used to ensure your app will run on the version of iOS you’re targeting. It’s worth noting that this is becoming less relevant since iOS often has the highest adoption rates when a new version is released, and storyboards were introduced in iOS 5.

Key Considerations

  • Modularity is key to well designed nib files
  • Use nibs to store views, subviews, custom controls or repeated views
  • There’s no way to represent the relationship between screens of related content
  • Backward compatibility

When to use Storyboards

Storyboards provide a visual representation of an application, showing screens of content and the connections between those screens. A storyboard is composed of a sequence of scenes, each of which represents a view controller and its views. Unlike nib files, storyboards provide a mechanism to transition between screens of related content. In storyboards, a single screen is referred to as a scene. Scenes are transitioned between using segues, which are responsible for preparing and performing the visual transition between two view controllers. Segues also contain information about the view controllers involved in a transition.


As storyboards are used to store scenes, and a scene represents full screen content, storyboards are not the right choice when building custom controls. In this case you should use nib files; you can have both storyboard and nib files in the same project.

Storyboards do not suffer from the same memory implications that nib files do as each scene is loaded when it’s required. So, whilst a storyboard could be made up of several scenes, many of which may include images or other resources, only the current scene is loaded into memory. However, large storyboards aren’t without their pitfalls; the prepareForSegue:sender: method, which is called prior to a segue performing it’s transition, can often become bloated increasing code complexity and reducing maintainability. Because of this, it’s recommended you apply the same logic when designing storyboards as when designing nibs and modularise where possible. Just like with nib files, there is no limit to the number of storyboards a project can have.

Key Considerations

  • Storyboards are best used to represent screens of content and the connections between those screens
  • Give due care and attention to the prepareForSegue:sender: method
  • Modularity is still applicable when designing storyboards
  • Use nib files for custom controls

When to use nibs and storyboards

In this section I’m going to explore some of the decisions that arise when considering the use of nibs or storyboards, using UITableView as our case-study.


Caption 3: Reusable UITableViewCell in a nib

Caption 3: Reusable UITableViewCell in a nib

Caption 3: Reusable UITableViewCell in a nib


When Apple introduced storyboards in iOS 5, they also introduced a much more convenient way to design and populate instances of UITableView. For each instance of UITableViewController there is on a storyboard, you can decide whether the associated UITableView is static or dynamic. Static allows you to design each instance of UITableViewCell your table view requires right from within Interface Builder, without writing a single line of code. Dynamic introduces the concept of prototype cells, which allow you to design one or more cells within Interface Builder that can then be replicated in code, usually within the tableview:cellForRowAtIndexPath: method.

Static and prototype table view cells are great if their design is only applicable to the table view housing them. But what if you have several table views across several scenes all of whom share the same cell design? You can use a nib file! Developers hate duplication right? So it’s a good idea to create a separate nib file containing only an instance of UITableViewCell. When creating cells in this way, you can register them in the UITableViewController’s viewDidLoad method to make them equally as convenient as prototype cells.

- (void)viewDidLoad
    [super viewDidLoad];
    [self.tableView registerNib:[UINib nibWithNibName:@"MyRepeatableTableViewCell" bundle:nil]

So when thinking about nib files and storyboards as you’re designing cells for table views, always consider whether the cell is specific to the current scene or not.

Things to Consider in Practice


You’ve seen how nibs are used to represent views, subview or custom controls and how storyboards are ideal for representing entire scenes and the relationships between them. However, the decision to use either a nib file or a storybord can be influenced by more than just the interface.

Dynamic vs. Static

Every interface you design will have it’s own unique requirements. Content driven applications tend to have a static look and feel used throughout. Other types of application may provide the user with a much richer interface that can be configured to meet with their own personal requirements. Nib files lend themselves to much higher levels of configurability; by modularising the components of an interface, the developer can recombine these in any number of ways in code.


Both nib files and storyboards are not the friendliest of formats when working within a team. Source control merge conflicts are common place and can often lead to corruption. Designing you nibs files in a modular way allows for multiple members of your team to work on different aspects of the same application at the same time and reduce the risk of corruption; this simply isn’t possible with fat nibs. The same approach can be taken for storyboards.


There are often many different ways to achieve the same goal, and that’s as relevant in programming as it is any other discipline. As a developer you will face decisions and have to make choices; some will obviously be better than others. But it’s necessary to try out each option and assess it’s particular strengths and weaknesses in order to broaden your horizon and aid your future decisions.

General Guidlines

  • Decompose your projects into nibs and storyboards
  • Views, subviews and custom controls should be contained within separate nib files
  • Use storyboards when designing full screen content and there are clear relationships between scenes
  • Consider whether the interface needs to be static or dynamic
  • Use separate storyboards to encapsulate reusable sequences of scenes
  • Use separate storyboards for unrelated scenes
  • Table view cells that can be reused across different controllers belong in nib files