Really curious to know why you had to reimplement Uikit uiview subclasses instead of just extending them and use ib to position them. Drawrect overriding has always been the recommended approach, and at least you can position buttons and panes and tableviews using ib , simply changing the name of the class in IB...
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.
