Doing high-performance scrolling is a hard problem. You just can't do it in HTML, at all.

Native code is not a silver bullet. If you're implementing a table view cell, the newbie approach is to just put subviews on the cell for each slice of content. This performs horribly because the graphics card has to composite all the sublayers while you're scrolling.

The faster approach, as he alludes to, is to do everything in one view, using pen operations to move around and blit each section. If you're serious about smooth scrolling, this is what you have to do. Tweetie was famous for its smooth scrolling, for example; it's because Loren Brichter used this approach.

Of course, if you're coming from the web/css world, doing everything with pen operations seems incredibly foreign and backwards. But you get good at it quickly. And it's worth it, UX-wise.

Not necessarily. Especially with Apple adding momentum scrolling to Mobile Safari in iOS 5. I have no problem smoothly scrolling through tables hundreds of rows long.

I would argue that nowadays with the power in the iPhone 4, iPhone 4S, iPad 2 and the new iPad (aka iPad 3) this is a premature optimization. The raw computing power of these devices makes creating a UITableViewCell with basic subviews total useable without affecting scrolling performance. I've worked on almost a dozen iOS apps in the last two years and that is all I do anymore.

Now about diagnosing the problem. 99% of the time the cause of the problem is one of two things:

1) Not reusing UITableViewCells 2) Doing way too much work on the UI thread

UITableView has a method called dequeueReusableCellWithIdentifier: which allows you to get access to a cell in a table view that is no longer being used. This allows you to reuse the cell instead of releasing the memory of that cell and creating a new one.

Memory allocation is expensive and if you had a table with 100 rows you could end up allocating memory for 100 UITableViewCells. Now on the iPhone if you are reusing cells you'd probably only allocate the memory 7-10 times (depending on the height of your rows) and then change little pieces inside it (like the text of the cell or the image that it is displaying). An easy way to see this is to create a demo app that has 1000 rows which are populated with random text, images you include in the bundle. Don't reuse table view cells and scroll up and down as fast as you can. You'll notice the scrolling is choppy. The second you reuse the the table view cells it will "magically" improve.

The second cause is people doing too much work on the UI thread. This is just bad practice and with the advent of Grand Central Dispatch and NSOperation you can simply take a block of code that is eating up a lot of time on the UI thread and pass it into the constructor of a NSBlockOperation and do all the work in the background. Some common examples of this are pulling data from a web service, converting data from a web service into local entities, reading from a local database (i.e. sqlite), sorting collections, etc.

If after solving these two problems your app is still jerky then it is perhaps time to look at adamjernst solution. But in my time I've created some pretty complex UITableViewCells in tables that have hundreds of entries and my scrolling is always butter smooth.

Doing it in HTML and CSS is indeed a lot easier.

If we are talking about UITableView then it only asks you for a row when it is about to be displayed. So in that case you are only loading the image when it is about to become visible.

I have no idea how this is done in HTML and CSS but in iOS it is still extremely easy.

If your image is remote, you'll need to put loading the image on a separate thread, and create a nonblocking http request to fetch the image. The problem is to draw the picture you have to use the main thread, so to make scrolling smoothly become quite a challenge.

1) in my ViewDidLoad I create an array of cells.

2) Then in my cellForRowAtIndexPath, I return the particular cell in my array.

- (UITableViewCell )tableView:(UITableView )tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

NSUInteger row = [indexPath row];

return [cellArray objectAtIndex:row]; }