There is the usefulness of exploring both approaches.
In addition to the historical value of the xib approach, xib also provides modularity. Perhaps you have a code library or want to share useful widgets that you made. Using the xib approach will facilitate sharing and reuse.
The xib approach also gives you more flexibility in terms of your own code. For example, in iOS 5 there was a bug with support for UITableView and Accessibility / VoiceOver, which would lead to the return of -dequeueReusableCellWithIdentifier: nil , although it was registered otherwise (see this blog post for more information). To dynamically load tabular cells from xib, error handling is provided.
While the support for tables and table sockets in Storyboards is awesome and provides support for what most people need to do in a table, sometimes you have to color outside the lines, you may need many different cells, and dynamic loading from xibs may be your solution.
One of the great advantages of storyboards is the ability to view the entire flow of the application’s GUI. Zoom out and you'll see how everything connects and flows. With xibs, while modularity is good, it’s harder to foresee how everything connects and flows together. This can be a useful feature for you, or if you have a large team that you want to share with, so that others can see how the application flows.
It’s important in both approaches, and it’s good to know both so that you can choose the best tool for your task.
Update 2014-10-06 . As I wrote above, I was involved in more projects. Some with xib, some of which can use storyboards.
Storyboards have matured a lot (we are now on Xcode 6), and there are a lot of good ones. I really like how much more can be done in the storyboard, which is a bit more complicated in the xib approach. A few examples:
When working with a UITableView or UICollectionView you can work with prototype cells directly in the storyboard. A lot of nice and easy setup, most of the heavy lifting can be in the storyboard, less code. This is pretty good. Trying to do this in the xib approach is certainly not a force, but there is much more work to make this happen.
Another is how nice you can go between a UIViewController with regular transitions, and then come back with a roundabout. Everything is right there, in the storyboard, with a minimal code. It is just convenient.
But one thing that still kills storyboards for me is trying to use them in a collaborative environment. It's just not going to merge well. And in some respects, this is even if you work in a team of> 1 person. If you use version control yourself, use a good branching and unifying model for your personal workflow, maybe there will come a time when some changes will need to be made in an industry that needs to be transferred to another branch, and that’s a pain. For me, this is what kills storyboards.
As time and work evolve, what I find for myself are storyboards that are great for prototyping. The ability to quickly find things is a huge advantage to storyboards. There is a lot of speed to use. But speed is expensive. When it comes to writing "real" code for a project, I will just stick with xib because, although it may be more, it is a more flexible route that just works better in larger teams or over time.
Update 2015-04-07 Another update because the projects of the past months forced me to use storyboards that provided more information.
First, some things will determine this or that approach. For example, apparently, when working with size classes in xibs that did not exist, they did the same thing in the storyboard, there were errors in edge cases. So if mistakes hit you, it can force your hand anyway. Another is to remember that storyboards usually work at the UIViewController level, so if you need to do something like loading a UIView or a UICollectionViewCell , it will probably be better to serve xib.
Secondly, and I do not know why this did not happen to me at first, but there is nothing that would require you to use a unique storyboard for your entire project! I think the nature of the storyboard allows people to stretch so, but we must remember that nothing is obliged (that I know).
What I found works well - this is usually the approach to each “grouping of views” for a storyboard. That is, often your ViewControllers tend to be isolated and end as 1 for the storyboard (or xib). But you may have a situation where you have two closely related ViewControllers, and it makes sense to put them in the same storyboard, especially because then you can easily connect them between them, for example segues.
The main advantage of multiple storyboards? Teamwork. Thus, Fred can work on his storyboard, and Wilma can work on her storyboard, and there are no strong worries about the problems of merging or coordinating work! Using multiple storyboards (and typically 1 ViewController for storyboards) has been a huge help in using storyboards on a multi-user development team.
It's pretty obvious, Apple wants us to prefer storyboards, and I hug them more these days. Using multiple storyboards, but using xib if necessary works quite well.
Update 2015-09-21 Now that Apple has released Xcode 7 , there is even more reason to accept the storyboard as Apple is working to fix the flaws.
The most important improvement is the storyboard links, which allow you to create a link to another storyboard in one storyboard. It's dead easy to do, and now you can have cross-storyboards (both input and output). I have used this several times already in a new project, and it's just a joy.
Another improvement is that you can create standalone UIView classes in a storyboard. However, at the time of this writing, I had mixed results. Simple cases work fine, but some of the more “complex” things didn't work. For example, I had a UIViewController with a UITableView inside it. Since it was a simple table with 5 static cells, I simply created an instance of 5 UITableViewCell as part of the ViewController in the storyboard. It seemed to work, but then, at run time, nothing would actually load and appear; moved the UITableViewCell to xib and it worked. I am not sure that I am doing something wrong or that it could be, therefore YMMV. But still, even if there are only a few quirks, over time I’m sure that Apple will solve them, and then another barrier against the storyboard will fall. I would say that if you need such support, you should try it and see how it goes for you. There are great prospects.
More and more, storyboards are being formed to be excellent.