The second one is not as difficult to understand, but there’s one thing which should be explained.

This tool absolutely doesn’t make sense with fixed row height of the UITableView, but if your context requires dynamic height of cells for some reason, you may get choppy scrolling very easily.

As we know, UITableView is just child of UIScrollView, which enables user to interact with areas whose real size is bigger then visible. Any UIScrollView instance uses such things as contentSize, contentOffset and many others for displaying correct rect to user.

But what is wrong at UITableView? As has been explained, UITableView doesn’t hold all cell instances simultaneously. Instead, only required cells are shown to user.

So, how does UITableView knows about its contentSize? It just calculates this value by summing all cell heights.

The tableView: heightForRowAtIndexPath: method of the delegate of UITableView is called for each cell (even if it isn’t displayed!), so you should return height values very fast.

Most people make huge mistakes by laying out initialized instance of cell with bound data to fetch their height after this. You should not use this way for calculating height of cell if you want to improve scrolling performance, ‘cause all this things are incredibly slow and 60 FPS which are standard for iOS devices will be dropped to 15–20, and your scrolling becomes laggy even with low speed.

How to calculate further cell height if we don’t have an instance of this cell? It is example of cell code, which using class method for returning height based on passed width and data for displaying (it’s adapter of cell):