Interface Builder is definitely not a must have. In many cases, it just gets in the way. You can easily override loadView and create your views by hand. In fact, for most of the good stuff, you have to do this.
> In fact, for most of the good stuff, you have to do this.
IB's biggest benefit is we can have our artists skin apps and check in the XIB - no programmer needed. This is very important once you start creating platform type apps. Skinning can be a very time consuming process; IB makes it more manageable.
To clarify what milkshakes is saying, IB stops being useful when you are doing custom animations (e.g. moving subviews around - something that is very common if you have a custom animation). Usually, IB will beat a developer coding CGRect type code from scratch (unless they are using Opacity - a great tool that generates code and is very programmer friendly). A custom UIView will probably win the performance race but lose in the productivity/maintenance marathon.
Once you start getting into custom rounded table cells, custom table headers that act as row 0 of the table cell, empty placeholder cells, CoreData, and table/cell animations - you are entering the dark side...
Using IB for UITableViewCells doesn't have a significant performance penalty now because if you are doing custom cells - the client is probably willing to sacrifice 60fps scrolling - to get their custom table gradients/cell backgrounds (otherwise the cells would be opaque).
I find that I used to do most of my work without nibs and do it in loadView. In recent releases I've been using xibs for a lot of the base layout and doing the rest in viewDidLoad. 99% of the time you can create most of your interface in IB and save yourself a bunch of time and make it more maintainable.
