The Case for Deprecating UITableView →
Peter Steinberger & Michael Ochs:
UITableViewis 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?
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
UITableViewCellalong 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
UICollectionViewCellsupports autosizing via Auto Layout the same way that a
UITableViewCelldoes, 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
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.