How do UITableView and UICollectionView reuse cells?

What's really being asked

The interviewer wants to know if you understand how UIKit avoids memory pressure and maintains sixty frames per second scrolling by recycling view objects instead of allocating one per row. This is the flyweight pattern in practice, and it separates cell configuration from cell creation.

The full answer

First, the reuse mechanism itself. As a user scrolls, cells that move offscreen are not destroyed but are placed into a reuse pool managed by the table or collection view. Second, the role of dequeueReusableCell with identifier. When the view needs a cell for a newly visible index path, it calls this method, which attempts to return an existing cell from the pool that matches the identifier. If none is available, it creates a new instance using the class or nib registered for that identifier. Third, registration. You must register a class or nib for the identifier beforehand, typically in viewDidLoad, so the dequeue method knows how to instantiate fresh cells. Fourth, the performance implication. Reuse keeps the memory footprint flat regardless of data set size, since only a small number of cells equal to the visible rows plus a small buffer are ever alive at once.

The mistakes people make

A major red flag is saying cells are automatically reused without any registration or dequeue call. Another is confusing cell reuse with view controller lifecycle methods like viewWillAppear. Some candidates also believe the reuse pool is unbounded or that cells are never recreated after the initial load, when in fact the pool can be empty during fast scrolling or after memory warnings, triggering fresh allocations. Suggesting that you should manually create cells with init instead of dequeue is also a serious mistake.

What usually comes next

The interviewer may ask what happens if you forget to register a cell, which results in a crash at runtime. They might ask about the difference between the two dequeue methods, one requiring an index path and the other returning an optional, and when to use each. You could also be asked how to handle multiple cell types, which simply means using different reuse identifiers, or how to reset cell state before reuse, which is done in prepareForReuse.

A concrete example

Imagine a table view showing ten thousand photos. Without reuse, instantiating ten thousand image views would exhaust memory and cause jetsam termination. With reuse, only about fifteen cells exist at any time. In cellForRowAt, you dequeue a cell with identifier PhotoCell, configure its image view and label for the current index path, and return it. When the user scrolls down, the top cell slides offscreen and enters the pool, then dequeueReusableCell hands it back for the newly visible bottom row, and you overwrite the old image and text.