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.
So how do you reconfigure?

Using diffable data source:

NSDiffableDataSourceSnapshot.reconfigureItems(_:)
developer.apple.com/documentation/…

If not using diffable:

UICollectionView.reconfigureItems(at:)
developer.apple.com/documentation/…

UITableView.reconfigureRows(at:)
developer.apple.com/documentation/…
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…

as well as see an example of it being put to use in the associated sample code:
developer.apple.com/documentation/…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Tyler Fox

Tyler Fox Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @smileyborg

16 Oct 20
It’s a good question. There are a number of reasons why these properties are marked as “to be deprecated” in a future release.

Here’s a short thread to explain some of those.
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)
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(