Peter Steinberger & Michael Ochs:

UITableView is a cornerstone of classical iOS development and one of the oldest classes. It’s used in pretty much all iOS apps and has been around since iPhone OS 2.0. So why would we propose deprecating one of the most used classes?

Simple: UICollectionView. Added in iOS 6 (2012), it’s almost a perfect superset of UITableView, yet it can do so much more.

I have had similar thoughts about getting rid of UITableView ever since I used my first UICollectionView. The list of reasons to stick with table views get smaller every year. Off the top of my head, the main reasons I would choose a table view over a collection view in iOS 10 are:

• Using the system UI for editing: This includes the drag handles on the right of a UITableViewCell along with swipe to delete. Dragging and dropping in a collection view is not hard, but you don’t get that standard UI for free.
• Autosizing cell height: A UICollectionViewCell supports autosizing via Auto Layout the same way that a UITableViewCell does, but I find a table view simpler to work with if I only want the height to be auto sized while the width matches the container (in other words, if it looks like a table).

Both of those problems could be solved with a theoretical UICollectionViewTableLayout.

---

The one big advantage to switching everything to a collection that I did not see mentioned in the linked article is customization. UITableView is a pretty opaque class; it has entry points for customization, but doing something that an Apple framework developer did not anticipate is either impossible or involves weird hacks or workarounds.

UICollectionView, on the other hand, is extremely customizable. By building on top of supplied UICollectionViewLayout subclasses (like UICollectionViewFlowLayout and the theoretical UICollectionViewTableLayout ), you can add customizations while inheriting all of the built in behavior from the superclass.

If this is something that you think Apple should do, it is worth your time to file a radar.