There's generally two kinds of iOS apps/devs and once you work out what bracket you fall into, choosing between IB and code is easy.
If you're making fairly standard apps that substitute largely for websites - eg, login screens, some data in lists, couple forms - then you will probably want to go with IB storyboards. For these types of apps, development speed is most essential and future changes are mostly just tweaking the UI a bit as a large part of the functionality of the app is just pulling data from web services or doing standard calculations and displaying the result. Storyboards will let you get a nice looking and fairly simple UI done very fast and allow for rapid UI changes.
However, if you are going to have 3+ devs working on your app because it's actually the basis for a business or is very complicated, storyboards cause a lot of merge problems. They're far harder to create automated test code for. Refactoring your app becomes an exercise in tracking down IBOutlets. The couple days you saved at the start with easy layout and transitions get eclipsed by the amount of time you spend fighting IB later for changes. Also, if you use code review tools and have a heavy peer review culture then storyboards are a particularly bad fit.
Honestly I believe most apps fit into the first option and storyboards are the way to go. 95%+ of the apps on the Apple Store are definitely in the first category, and there usually isn't a need to over engineer them.
It's important to distinguish between NIBs (or XIBs, if you prefer) and storyboards.
NIBs can be used in even extremely complex and large applications to make tasks easier. For example, iPhoto on iPad uses NIBs to load in UI interface assets as it's more convenient than doing it in code - and this is an app with a large development team and a significant codebase (there's an interesting WWDC 2012 video available on iPhoto's iOS architecture, which is where I got this piece of trivia from).
One of the problems with storyboards - versus NIBs - is that it can become difficult to work at scale. Not scale in terms of team members (although that can be a problem), but scale in terms of the size of your app's UI. A iPad app with a a dozen different screens of content can become very hard to navigate.
Where storyboards are useful is allowing those new to the platform to get up to speed on concepts such as custom table view cells, collection views, auto layout and the like without having to get bogged down in the large amount of code this would normally require. They're definitely not for everyone.
Sadly, NIBs have a bit of a bad reputation with some developers. I suspect this is mainly for historical reasons - as of Xcode 5 the XML schema has been significantly simplified making code review and source control much easier, and NIBs have significant advantages for newer technologies such as auto layout.
One way ive found to handle scale in storyb
oards (in both terms of scale) is RBStoryboardLink which allows you to separate an app into multiple storyboards and use placeholders to jump into another one.
We recently converted our project from IB to doing everything programmatically and could not be happier with the result.
As the app has evolved over time and grown in complexity, we felt we reached a tipping point where using IB was slowing us down more than it was helping. Same for auto-layout.
Part of this was because the app simply has a lot more functionality today than it did three years ago, which means there were a lot more nibs to manage than before. Part of it is because we started developing more custom views that did not map to any existing IB components and thus had to be done by hand anyway. Part of it is because we found we had to switch to drawing certain things programmatically for performance reasons. Either way, I'm quite glad we made the conversion.
That said, I agree that most apps should start with IB and only move onto the more complex stuff once/if the need arises. IB helps a lot out of the gate (and also makes learning the platform a lot easier since you can visually see what you're setting up). Once it gets to be a hindrance, you'll know, and you can then make the decision to switch later on. And if your app goes nowhere, then you'll have wasted less of your time.
I also strongly agree that explicit is better than implicit, and configuring a view programmatically allows you to fully specify what its behavior should be, rather than what it happens to be. When you revisit a nib several months later after originally configuring it, sometimes you forget whether the configuration option you selected in the dropdown was intentional, or was it the default, or was it merely accidentally changed at some point?
1) Storyboards are different in Xcode 5 both constraints as well as the under-the-hood XML. It's much more human readable and cleaner. Easy to merge.
2) You can separate storyboard into logical parts.
a)Signup flow
b) Sign In Flow
c) Tab1 and the rest of the navigationcontroller stack
d) Shared controllers
I second this. If you're in the business to crank out apps for the purpose of a bread and butter bottom line with more than one person working on the project, IB is the way to go. Otherwise, there's a ton of value in doing it by hand.
If you're making fairly standard apps that substitute largely for websites - eg, login screens, some data in lists, couple forms - then you will probably want to go with IB storyboards. For these types of apps, development speed is most essential and future changes are mostly just tweaking the UI a bit as a large part of the functionality of the app is just pulling data from web services or doing standard calculations and displaying the result. Storyboards will let you get a nice looking and fairly simple UI done very fast and allow for rapid UI changes.
However, if you are going to have 3+ devs working on your app because it's actually the basis for a business or is very complicated, storyboards cause a lot of merge problems. They're far harder to create automated test code for. Refactoring your app becomes an exercise in tracking down IBOutlets. The couple days you saved at the start with easy layout and transitions get eclipsed by the amount of time you spend fighting IB later for changes. Also, if you use code review tools and have a heavy peer review culture then storyboards are a particularly bad fit.
Honestly I believe most apps fit into the first option and storyboards are the way to go. 95%+ of the apps on the Apple Store are definitely in the first category, and there usually isn't a need to over engineer them.