Storyboard vs XIB in iOS Application Development UI/UX Management in Large Projects

Published Nov 21, 2017Last updated Apr 19, 2018
Storyboard vs XIB in iOS Application Development UI/UX Management in Large Projects

I'm Benjamin Chris, and I've been developing iOS and Android apps since 2011. I wanna write about my experience with UI processing in iOS app development on XCode.

I have used XIB files for UI configuration since 2013 and both Storyboard and XIB files for UI configuration from 2013 to 2014.

While using XIB files and Storyboard files in XCode, I learned the advantages and disadvanges for each method and finally arrived at the best method for UI management in 2015. Let me explain all of these experiences here.

As you know, Storyboard consists of several ViewControllers, whereas XIB files can consist of only one page. On the Storyboard file, we can configure the flow between pages directly by using segues.

Once Storyboard launched by Apple, many developers liked it and tried to use it. Storyboard is especially very good for managing dynamic cells for table view (I've used UITableViewCell based page configuration in full UI content configuration often). Many developers changed their method of configuration from XIB-based to Storyboard based methods.

But Storyboard has its own disadvantage. It contains many pages, so XCode was too slow when you opened Storyboard and performed any actions.

It was even too slow just opening Storyboard files. For example, very large projects consisting of around 40+ pages, view controllers, and main.storyboard with all of these pages in it took almost seven to nine seconds to open in my XCode. This was not productive and drove me crazy.

XIB files were easy to load but required so many codes to create even simple push/pop for navigation or child view controllers for tab view controller. Also, they cannot contain and manage dynamic tableview cells.

Considering all of these factors, I have found a method of management for Storyboard based projects.

The project will have "scenarios" per feature and each scenario will include one storyboard. Each storyboard will include only a few controllers so we can avoid loading/procesing problems.

For example, in my above cover image (it was the screenshot of my app development), you can see several UI storyboard files.

Each storyboard will process all pages per feature. "friend.storyboard" represents scenarios for friend features and contains the friend list page, add friend page, select friend page, etc. Like this, we can split the total project into several features based scenarios and can manage them.

Of course, we can make connection between pages in two different scenarios. For example, we might need to open user profile pages in profile scenarios from friend list pages in the friend scenario.

Don't worry. Here is code to load the specific page for the Storyboard file.

UIStoryboard storyboardWithName:@"storyboard file name" bundle: nil] instantiateViewControllerWithIdentifier: @"controller id"

I could successfully manage all Storyboard files without XCode speed issues by using this structure in my large scale projects.

Thank you for reading my post. Actually I think this is not a great solution or a great point for developers, but I just wanted to share my experiences in my previous development.

If this can provide a bit of help to other iOS app developers, I will be happy.


Discover and read more posts from Benjamin Chris
get started