In this article, I wanted to document what I discovered in my search for an answer to the question:
Is it an iOS best practice to avoid using Storyboards/XIBs and instead, create your views programmatically ?
As a disclaimer, I personally tend to avoid using storyboards and XIBs simply because I feel that I’m more in control when I create all of the views programmatically. I also ask all of the iOS developers whom I interview and more often than not, they’re of the same thought. We recently had a new member to our iOS team who advocated the use of storyboards and XIBs so it made me revisit this question.
As with any debate, there’s always more than one side to the story. I set out with an open mind, put aside my own opinions and started searching for the facts of both using XIBs versus purely creating your 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 (ie. 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)
Creating Views Programmatically
Advantages:
-It’s easier to merge conflicts and diff lines of code than it is a XIB file
-You can trace through code when debugging and not have to look at Interface Builder
-Performance wise, it’s faster view creation than XIBs
-Creating views through code, gives you more control and free reign
Disadvantages:
-It’s harder to visualize the UI and grasp a mental picture of what it will look like if all your UI creation doesn’t happen in one place in your code
-You can’t visually position elements, making it more time consuming to layout your views
-For a newcomer to your project team, it will take them longer to grasp the app flow and navigation
For you readers, what is your own experience? Share your thoughts and comments below and I’ll update this post!
Shameless plug to my video channel. I’ll be adding new stuff soon!
Further reading:
Interface Builder (XIB) or Code when merging in a team
environment?
Should or should not use nib files ?
When to use Storyboard and when to use XIBs
Thank you for good blog topic! I preferred programmatic iOS app development. I have learning lot of new technical and logical things by using iOS programmatic development way. If you want to be a good iOS app developer you should follow programmatic development.
Trying to learn Cocoa programming and truly understand the principles without the xib hiding things. Where could I go to get code examples that set up a basic Cocoa project WITHOUT a xib/nib? Can’t find any online! What makes things worse is that I am mixing in learning Swift.
Detected this way of programmatic UIs, definitely worth looking at if you want programmatic views: http://codeblog.shape.dk/blog/2013/12/16/live-editing-layout-constants-using-classy/
Thanks for this great post. I just joined the IOS world and I am very happy that you can create views programmatically.
I come from web applications and I got really tired of the fragile and markup based views of web applications. The discussion here is a very old one, domain specific language (here objective-c for views) vs something that is not created to be used for what it is being used (xml markup to describe complex view structures and logic).
For me there is the only true way to do it programmatically:
– you can use extension and handle all your ui elements in one general manner
– you can work in teams perfectly
– you can apply system wide design changes very fast
– you will not worry about localization
– you can easily do TDD
– you can easily overwrite certain parts of your layout beeing great for frameworks setup
– most important, you don’t have a language break between objective-c and xml
If I see the arguments to use the markup and storyboards this is what I think:
– you want easy overview the flow? why don’t you then create and manage UML diagrams for all your other classes, we have been there with model driven software development
– how do you deal with localizations?
– how do you create rich behaviour like view cells and test them separately?
– juniors should have an easy entry, well what are they gonna do with the back end then?
I think storyboard is better, since the installation of iOS 6.0 is up to 94%+, and iOS 7 is coming, XCode5 is optimize the storyboard a lot for team work.
I don’t agree that working with a storyboard in a team is hard. I work with my team on medium size project with only one storyboard file. Storyboards are simple XML files and any good XML merging tool could solve Git conflicts. I once even wrote a simple StoryboardMerge app (it’s on my webpage in a free tools section) so that my team could work faster.
The fact that you had to write a custom app to make the Storyboard merging easier actually shows that it’s hard.
Personally I’ve always preferred to use code so I am in control in every aspect and avoid surprises down the road when a certain feature isn’t supported by either storyboard or xib’s. It’s more future proof in my humble opinion.