> 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).
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).