Why do you "have to kiss that silky smooth scrolling goodbye" if you setup your UITableViewCells in Interface Builder?
I've used it for all of my apps and the scrolling is just as fast as any of Apple's native apps. Interface Builder just packages up all that initial layout code and then it is executed when the nib when it is unpackaged. After that there is no difference.
Actually there is a difference. If you create a table with a considerable number of cells (say, over 20) that contain a couple of labels and maybe an image when you swipe really fast the scrolling will hang, even if you are using the dequeue mechanism.
The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics.
If you had twenty different UITableViewCells in a nib that had twenty different pictures then I admit the loading of these cells will cause the scrolling to stutter if you do it in cellForRowAtIndexPath:.
However I just finished an application with a UITableViewCell, defined in a nib, that had 3 labels and a image. The labels depend on the data that the row was displaying and the image was the same in every row (it was a custom disclosure image).
One of the table views that that used this cell had 100 rows and it loaded and scrolled without a hitch.
Most of the slowdowns people experience with scrolling is if they have transparent cells and/or they don't load lazy load images on a background thread.
I agree that if you've tried all sorts of optimizations and you are still experiencing slow scrolling then painting the contents manually will probably be faster but it is IMO more work then 99% of people need to do and, like naz said below, there can be accessibility issues.
When Loren Brichter wrote that 3 years ago it was a much bigger deal. The iPhone 3G was extremely underpowered compared to most of the devices people run iOS on today.
If you avoid transparent view backgrounds (just give labels a grey background if your cell has a grey background) and disk reads then you can make fast UITableViewCells without having to resort to drawRect. You should also avoid things like layer.cornerRadius and allocating lots of objects (such as NSNumberFormatters) in cellForRowAtIndexPath.
That said, if you get frame skips after all that then overriding drawRect for the content view is a great way to speed it up. You have to be careful to keep your app accessible though, since the view has no labels for the screen reader to read. And orientation changes can look awkward.
I also don't think it's particularly hard to do the x,y frame setups either. Just start by drawing boxes on a piece of paper. Figure how things interrelate, make the code, tweak the margins.
I agree. It's not the frame setup that sucks when compared to Android. It is the layout containers that Android has.
Setting the origin of a view in iOS vs Android is going to be approximately the same amount of code (whether it be Objective-C or XML) but it is the layout containers that save you from writing all that boilerplate code when the size of the parent views change.
He did make a good point of being able to preview your XML. I would kill for the ability to do that with iOS.
Interface Builder needs to go the way of Expression Blend where you aren't writing plugins that allow you to edit all the properties of a UIView. Interface Builder should scan all the possible properties of a UIView and then allow you to modify them.
I've used it for all of my apps and the scrolling is just as fast as any of Apple's native apps. Interface Builder just packages up all that initial layout code and then it is executed when the nib when it is unpackaged. After that there is no difference.