We've been using UITableView since the release of iOS 2. This class has already become the essential part of literally every iOS application. Currently, we are trying not to apply it in anymore in our projects, in favor of UICollectionView that conveys much more flexibility. It's already well known that UITableView class has become obsolete, and even Apple admits it. It's poorly customizable and has a variety of issues related to auto-resizing cells, autolayout, etc. In this article, I'll try to cover most of the problems you might encounter when working with a usual table view and how collection view can be used to resolve them.

API Downsides

Since UITableView class was created before the emergence of blocks in Objective-C, we have a lot of quite inconvenient syntax constructions. For example, if we want to reload a section, we need to place invocation of the corresponding method between beginUpdates()/endUpdates() functions:

tableView.beginUpdates()

tableView.reloadSections(IndexSet(integer: sectionIndex), with: UITableViewRowAnimation.none) tableView.endUpdates()

This is not good, because you could easily forget to call one of the functions, which would result in the layout getting messed up.As for UICollectionView, it provides a much better option for section updates using a performBatchUpdates method that accepts a block as a parameter.

So, the section reloading would be written like this:

collectionView.performBatchUpdates({

collectionView.reloadSections(IndexSet(integer: sectionIndex)) }, completion: nil)

UITableViewCell issues

The first problem is linked to an unclear behavior of standard cells.

UITableViewCell class provides a style property with which you can specify whether cells would have subtitle or imageView; however, the properties designated for accessing whatever subtitle or imageView are available permanently. This means that you can easily change the text of a subtitle without setting up the corresponding style. It's hard to find a mistake in such a case, because Xcode won't throw any exception.

This lead us to the next issue. UITableViewCell is overloaded with redundant functionality.

Most iOS projects utilize highly customized table view cells that may appear quite complicated in terms of conceiving the view hierarchy. Such a complex structure can be achieved only by subclassing UITableViewCell class. The main point is that this class provides default API that cannot be removed, anyhow. I'm talking about textLabel, imageView and other properties that are predefined in this class. Thus, if you want to have a custom table view cell, you'll have to bring these default API around all the way. Sometimes it could be quite confusing, since you have a palette of additional properties inside your cell. The most trivial thing you may come across is name conflicts.

Autolayout

Autoresized cells have quite uncertain behavior. You may have multiline labels inside cells, and it can result in unexpected results when you have several views inside a cell, with sizes to be calculated at runtime.

Another annoying issue that often appears is a UIViewAlertForUnsatisfiableConstraints message emerging in console. This usually happens if you're not very careful when laying out subviews of the cell. For example, you may not account for space needed for the table view to accommodate separators between cells. This might happen when you set constraints in a way that restricts the height of the cell.

Size classes

The last thing to mention is the inability of table view to change its layout for different size classes. We can have a table view that may look perfect on an iPhone SE screen, but would appear quite odd on an iPad. The thing is that a great deal of free room will not be utilized if, for example, you have a text label inside cells with a font size that is appropriate for iPhone. That same content would not be perceived as well on an iPad. Letters would seem really minuscule, relating to the free space left untouched. Collection view allows us to reconstruct a layout in a way that we'd have several columns so that the whole screen would be moderately covered, giving us more flexibility.

Unflexible layout

Since software requirements are continually evolving, you need to keep your code and view hierarchy as versatile as possible to be ready for any modifications. Sometimes, these changes may affect table views. For example, a customer has decided to represent UI items in the grid form instead of stacking items vertically. Or he might become willing to support iPads and, as I described in the paragraph above, the usual table view layout may not be appropriate for the iPad screen size. Therefore, developers, who were not so broadminded initially and already laid out UI components using table views, would be discouraged because they'd have to either replace table views with collection views that would entail a complete rewriting of the UI logic, or find some faster and messier path such as creating table view cells that would have several columns. This last option is not reliable, since any successive UI changes, such as adding new columns, will lead to altering the inner structure of the cell that may be quite annoying and time consuming. In contrast, if dealing with collection views, in a growing number of columns in a grid, the only thing you'd have to do is to recalculate the appropriate size for the cells so that you could fit in more of them in one row.

Conclusion

If talking about other advantages of the UICollectionView class, they go far beyond what I've been currently talking about. One of the most powerful features is its ability to subclass the UICollectionViewFlowLayout class. This opportunity allows us to construct almost any possible layout of cells you could imagine. At Applikey, we've designed our own several custom collection view layouts that would be a great alternative to the standard ones:

VegaScroll mimics standard UITableVIew layout by applying cool elastic scroll effects and illusions of cells stacking on top of the view. GravitySlider is a completely non-linear layout for switching views. PandoraPlayer is a music player with a song switcher based on a collection view with a customized layout.

So, being reinforced with such a powerful tool as collection view gives you almost unlimited flexibility while developing, in comparison to table view. Despite all of the advantages of UICollectionView, it also has some downsides when looking a bit closer, though that's beyond the scope of this article. We'll be discussing them later on.

The innovation we'd be glad to see is already built-in the UITableView-like layout for UICollectionView, or may be some set of the most popular non-standard layouts so that we wouldn't have to implement them ourselves.