I'm a big fan of not using IB because code is easier to read, extract (constants, functions, component-ize), copy & paste, and version control. I also build a UIView class hierarchy so I can stash all my view-related code there instead of putting them in controller classes.
A major reason of using IB is you can position and view their layout visually. But when you build iOS apps that have (1) custom UI components, (2) uses a good amount of animation, or (3) have different enough portrait and landscape views, you can hardly see anything useful when looking at that nib in IB.
NB: re-reading this, I was more responding to Chad's point "Having over 30 screens to program (no Interface Builder here) meant that an overwhelming majority of the time on the app was spent writing interface code." rather than why not extending existing UIKit classes like UIAlertView/UIActionShet which MaxGabriel answered.
Comments
I'm a big fan of not using IB because code is easier to read, extract (constants, functions, component-ize), copy & paste, and version control. I also build a UIView class hierarchy so I can stash all my view-related code there instead of putting them in controller classes.
A major reason of using IB is you can position and view their layout visually. But when you build iOS apps that have (1) custom UI components, (2) uses a good amount of animation, or (3) have different enough portrait and landscape views, you can hardly see anything useful when looking at that nib in IB.
NB: re-reading this, I was more responding to Chad's point "Having over 30 screens to program (no Interface Builder here) meant that an overwhelming majority of the time on the app was spent writing interface code." rather than why not extending existing UIKit classes like UIAlertView/UIActionShet which MaxGabriel answered.