Table view or collection view: which do you choose for new code?
Predict first
Which do you reach for first in a new screen with a sectioned list, swipe actions and diffable updates?
// A: UITableView with reloadData
// B: a collection view with a list layout and a diffable data source
// C: a custom scroll view
- A
- B
- C
Mental model. A table is a good, familiar kitchen table. A collection view with a list layout is the same table with a modular system underneath that can also become a counter or a buffet.
For new screens, prefer a collection view with a list configuration (UICollectionLayoutListConfiguration). It gives you the table look (separators, swipe actions, grouped and inset styles, headers, footers, disclosure and reordering) and the modern machinery: compositional layout, diffable data source, content and background configurations, and cell registrations. A grid, a carousel, a mix of both or anything non-linear is a collection view anyway, and one framework to learn is cheaper than two.
A UITableView is still fine, and you must be able to maintain it: the codebase probably uses it, it is simple for a single plain list, it has mature built-in features (row editing, index titles, sections with sticky headers), and tests and examples are everywhere. The deciding questions: do you need anything beyond a vertical list, do you want diffable updates and the new cell configuration APIs, and what does the existing code base use? Do not rewrite a working table just to switch. Both can host SwiftUI cells through UIHostingConfiguration in modern SDKs.
It gives the list look and the modern data and cell APIs in one framework, with room to grow beyond a list.
| UITableView | Collection view with a list layout | |
|---|---|---|
| Layout | a single vertical list | a list now, any layout later |
| Updates | batch updates or a diffable data source | diffable data source, the standard |
| Cell content | custom cells or content configuration | content and background configurations |
| Index titles | built in | not built in |
| New code | acceptable for a simple list | recommended |
Common traps
- Rewriting a stable table for fashion. The gain is rarely worth the risk without a feature need.
- Mixing both in one screen without reason. Pick one container per scrolling area.
They might follow up with
- Does a list layout support swipe actions? Yes, through
leadingSwipeActionsConfigurationProviderand its trailing twin. - Where does a table still win? Index titles on the side, and some long-standing editing behaviours, plus minimal code for a simple list.
Related questions
- 7.6.1 How does a UITableView get its rows, and why do batch updates crash when the data and the update disagree?
- 7.5.1 How does compositional layout describe a collection view, and how do you read its output?
- 7.9.1 How do you put SwiftUI inside a UIKit app, and what do you need to watch for?
← How does a UITableView get its rows, and why do batch updates crash…