iOS 15 introduces a new way for you to conveniently update content displayed in existing cells in UICollectionView and UITableView: reconfigure.
When and why should you use reconfigure? How is it different from reloading an item or row?
Let’s dive in with a quick thread.
You can think of reconfigure as a lighter-weight version of reload.
Reload: replaces the existing cell with a new cell.
Reconfigure: allows you to directly update the existing cell.
Because reconfigure doesn’t request/create a new cell, it’s significantly more efficient!
How does reconfigure work?
For each item/row you reconfigure:
- If there’s no existing cell, it’s a no-op!
- Otherwise, the collection/table view calls your cell provider again, but with special behavior to return the *existing* cell when you dequeue one for that index path.
This means it will re-run your normal cell configuration code (in your cell registration, diffable cell provider, or data source cellForItemAt/cellForRowAt implementation) using the existing cell.
So your existing cell configuration code can now update cells later, too!
After cells are reconfigured, they’re always self-sized again, so any changes to the content which affect cell sizing will be automatically taken into account, and the cell resized as necessary.
When reconfiguring a cell, inside your cell provider you must dequeue the same type of cell (i.e. use the same registration or reuse identifier) to get the existing cell back, and must return that same cell back to the collection/table view.
Therefore, if you need to actually change the cell type, you can’t use reconfigure — that’s a case where you want to continue to reload the item/row instead.
But generally speaking, you should always prefer reconfigure whenever possible, as it’s less invasive and more efficient.
One particularly important reason to prefer reconfigure is because it will preserve existing prepared cells — cached cells which were either prefetched, or already displayed and are waiting to become visible again. Reload will discard those cells, which wastes valuable work.
You can learn more about reconfigure, and see how it works with new cell prefetching, in the “Make blazing fast lists and collection views” video: developer.apple.com/videos/play/ww…
For starters, there’s well over a decade of implementation behind these properties and the different cell styles, with layers upon layers of complexity to preserve binary compatibility with all the apps using them. (Old apps in the App Store need to keep working without updates!)
Unfortunately, because these built-in cell textLabel/imageView properties expose the entire API surface of UILabel/UIImageView, that means apps are doing all sorts of unexpected things to these views that weren’t intended to be supported (but aren’t explicitly disallowed, either)