Table Views

UITableView is used for displaying data in a one-dimensional table (a set of rows). Each row is an instance of UITableViewCell.

The UITableView is very efficient with large data sets and is highly customizable, so it’s often a good solution for displaying large amounts of data.

There are two styles of table views:

  • Plain – UITableViewStylePlain
  • Grouped – UITableViewStyleGrouped

UITableViewStylePlain   UITableViewStyleGrouped

The cells can also be organized into sections. You can see this in the Settings app, for example.

There are four built-in styles for cells:

  • Basic – UITableViewCellStyleDefault
  • Right Detail – UITableViewCellStyleValue1
  • Left Detail – UITableViewCellStyleValue2
  • Subtitle – UITableViewCellStyleSubtitle

Cells also have an optional accessory view. The built-in types are:

  • Disclosure Indicator – UITableViewCellAccessoryDisclosureIndicator
  • Detail Disclosure – UITableViewCellAccessoryDetailDisclosureButton
  • Checkmark – UITableViewCellAccessoryCheckmark

These are active controls, conventionally used to show extra information on that cell’s data.

Cells also have an optional image view. Notice that the Left Detail – UITableViewCellStyleValue2 cell does not display the image.

You can also build your own custom UITableViewCell, in which you can layout these subviews any way you please, and add more subviews if you need to.

Table view data can be static or dynamic.

Static Data

Static cells are built much like any other UI control we’ve seen so far. You can build them using the Storyboard, completing and referencing with a code counterpart, or strictly in code, by subclassing UITableViewCell.

If you want to use segues, you would need to add one per cell.

Dynamic Data

When switching to a dynamic table, the cell you customize in the Storyboard is not an actual instance, but a prototype for all cells in the list. The actual cell instances will be generated in code. To identify the prototype, you mut fill in its Identifier field. If you need to use multiple prototypes in the same table, you can differentiate them by using different Identifiers.

A dynamic table needs a data source. This is usually the view controller that holds the table view, but it can be any object that conforms to the UITableViewDataSource protocol. This protocol has two required methods:

Cell instantiations tend to not be used for very long. For example, imagine if you’re scrolling to the bottom of a table with 100 rows, you’ll be instantiating 99 cells just to fly through them. In order to deal with this, cell objects are recycled. When a cell goes off-screen, it gets put in a reuse pool. The next time a cell is needed, one will be grabbed from the reuse pool if available. If not, a new cell will be created and added to the reuse pool when it’s done.

Header Source

If you want multiple sections, you must implement numberOfSectionsInTableView:. You can then set a header and footer to each section using tableView:titleForHeaderInSection: and tableView:titleForFooterInSection:.

Table View Delegate

A table view will also tend to have a delegate, to control how the table is displayed (as opposed to what is displayed, which is covered by the data source). The delegate is usually the same object as the data source, and must conform to the UITableViewDelegate protocol.

There are many methods available in the UITableViewDelegate protocol to customize the appearance and behaviour of the table view.


  1. Table View Programming Guide for iOS. Apple, Sep 19 2012.
  2. Paul Hegarty. Lecture 9 Slides. iPad and iPhone Application Development. Stanford, Nov 21 2011.

Comments are closed.