I like to think of Nibs like classes. A lot of times I'll have a certain design I want reused throughout the app, and this works perfectly. For instance, in an app I'm working on now, I have a few different views that have scroll-views inside of them, with each object of the scroll-view being a view itself. In the last of the chain of views, I use a nib because there's a solid amount of data there, and visually designing it in IB is easier to iterate and make it look exactly like I want it to. I have a .m/.h attached to the view (just a subclassed UIView) with a custom init method, returning what is basically a custom object (that happens to be that .xib). It's super efficient to make changes and keep things looking good when the data or the feature-set needs to change.
The end product, what my nib is for, has 12 labels, three UIView border bars (1px thick), two UIViews just for a differing background color in a couple spots, and a UIImage. Now you're right, I could set all those in code, alloc all those labels and adjust their sizes and positions relative to the ones that came before and all of that jazz, and that's all fine and dandy. Until I realize that my design needs tweaking. So, instead of selecting all elements on the nib and pressing up twice for a two pixel shift, I'm sitting there editing 20 different things in a CGRect call... way more work.
So instead of doing it all in code, the way I went about was creating a subclass of UIView with a .xib file attached to it. The .xib has everything where I want it visually and it's connected to the header via properties of everything that needs to be dynamic. Then I made a custom init method that just takes in my object and returns a UIView object that is the totality of that nib loaded with the data I need it to be.
All in all, instead of bloat, every time I need to return an instance of that custom subclass I effectively call something like this:
