Remind iOS: Should you use Interface Builder?

Currently we use Interface Builder for a lot of iOS UI development at Remind and we are now thinking about moving away from it and building our views entirely programmatically. I think Interface Builder can be a great tool for small dedicated iOS teams or solo developers so in this article I will talk about why we are thinking about doing this.

Remind has four dedicated iOS engineers with three other people who occasionally commit to the iOS code base. At different times during the year we also hire interns some of whom work full time on the iOS app. At any one time we might have upto nine people committing changes to the iOS code base.

In the last few months Remind also switched over to using cross functional teams to develop product. In this world its very common for front end engineers to make contributions to backend code and vice versa.

Interface Builder comes with two major drawbacks for cross functional teams; the inability to easily review UI related changes and the inability to work in parallel on UI features (resolve merge conflicts).

As far as I can see the only way to easily review changes made using Interface Builder, barring getting really good a reading raw XIB files, is to manually checkout and review each pull request. Doing this is of course incredibly tedious, time consuming and not something I suspect most people have the discipline to do consistantly.

In a world where their is a dedicated iOS team of experts with each component having a single owner this would not be much of a problem. In the world of cross functional teams where people simultaneously commit code to iOS/Android/WWW and not everyone is a domain expert this becomes an issue. It becomes an issue because not everyone is familiar with the idiomatic way to do things using Interface Builder. This leads to inconsistent XIB files that are cumbersome to work with because its hard to enforce a coding standard due to the difficulty of UI review.

Currently Remind has three cross functional teams, imagine a world with six or seven all working together on different aspects of the iOS code base. In this world it is inevitable that we are going to have people working together in parallel on the same UI code, either on new feature work or on bug fixing. This scenario is quite likely and poses a challenge.

Right now we are in the process of looking at using a third party library to solve this issue. In a future article I will discuss which one we decided to go with and how we went about making this decision.