UITableViews are the bread and butter of many iOS developers. They’re fast and modular, forming the core experience of many apps. At Yelp, we have more than 75 separate table views, including all of our most important screens. However, as powerful as UITableView can be, it’s not all sunshine and roses. Table views bring in an additional level of complexity, which can quickly get out of hand. Back in 2009, we designed a common architecture for all of our table views to make them easier to use. It was succinct and powerful, aimed at addressing the difficulty of sizing variable-height cells. However, as the team grew from 2 engineers to the 12 we have now, our 6-year old framework started to show its age. It didn’t manage complexity well, and was tricky for new developers to learn. I’ll be talking about what went wrong with the first architecture, and how we built those lessons into a new system. Our new architecture scales easily, from simple table views with only 1 cell class to complex ones with more than 25 unique cell types. It’s a much thinner wrapper over stock UITableViews, making it easier to understand for new developers. And it has encouraged modularity, allowing us to easily create complex views without writing new cells. I’ll also discuss some of the tricks we’ve found along the way, such as using child view controllers inside of cells. Our new framework has worked spectacularly well for us, and has pushed the bounds of what we thought was possible with table views. I’d love to share what we’ve learned.
Get more development news like this
This talk was recorded at AltConf 2015. Watch all the videos!
About the content
This content has been published here with the express permission of the author.