Provide height estimates for your table view’s headers, footers, and rows to ensure that scrolling accurately reflects the size of your content.
Whenever possible, table views use height estimates for cells, headers, and footers to improve performance and scrolling behavior. Before a table view appears onscreen, it must compute the height of its content view, because it needs that information to configure scrolling-related parameters. If you don't provide estimated heights for items, the table view must compute the actual height of items up front, which can be expensive.
The table view provides default height estimates for table view items based on the standard header, footer, and row styles. If your table's items are significantly shorter or taller than the default values, you can supply custom estimates by assigning values to your table's
estimated properties. If the height of individual items varies, provide custom estimates using the following methods of your delegate object:
When estimating the heights of headers, footers, and rows, speed is more important than precision. The table view asks for estimates for every item in your table, so do not perform long-running operations in your delegate methods. Instead, generate estimates that are close enough to be useful for scrolling. The table view replaces your estimates with the actual item heights as those items appear onscreen.
The example code below computes the estimated height for table rows of different heights. The cell for the first row always uses a custom style that includes multiple rows of text. All other rows use the Basic style provided by the table view.
When the table view uses height estimates, it actively manages the
content properties inherited from its scroll view. Do not attempt to read or modify these properties directly. Their values are meaningful only to