After all this years of iOS development I finally made up my mind: all UI should be done programmatically. And in the next lines I will try to explain you what led me to that.
When I started iOS development I joined a team working on an app where all UI was done in code. The team
decided to go that way mostly because solving merge conflicts for XIB was too much of a pain. It was a big point in my opinion
and so I went along their way of coding.
This by the way turned out to be a big benefit for me as it forced me to understand
UIView work under the hood.
When Apple launched iOS 5, Interface Builder (IB) got a new feature: storyboards. I was really curious to try them out, but after 2 years spent writing UI in code, it turned out to be a bit complicated. Or better, frustrating. I had no clues what I had to do and it was easier to just trash all storyboards and go back to beloved Objective-C rather than fixing the problems I encountered. And so I kept on coding UI, reaching a point where I would almost make fun of other developers using IB. I felt like the fox trying to reach the grape
And so it happened that one day, somewhere between the release of iOS 6 and iOS 7, everyone started blogging about how IB got better and better. That was it: I had to try myself. I put aside all my prejudices about the tool and forced my self to use it.
Frustration came back. But this time determination won. Once I understood how the tool does what it does, I started to like it. And when Apple made XIB (and storyboards) more human readable, the phobia for merge conflicts was also gone. But still at this point, I still had no big preference and I was very flexible.
Right then, I started diving into testing and TDD. I was getting very good feelings by committing code which I knew would have behaved like it had to. Slowly I started to first appreciate reading clean code and then to write it, as often as I could. And so it happened that one day, like Saint Paul on the way to Damascus, I saw the light.
I was reviewing a medium size merge request, with changes in
.swift files and in storyboards. The latter were simple things like changes in the number of lines, text alignment, etc.
Yet reviewing the diff in the storyboard XML felt laborious: I needed to carefully read through the lines
to actually spot the differences. I was extremely tempted to just fly over the storyboard changes because in the end, “what kind of breaking changes my colleague could have made? He’s a good developer, no?”. I resisted the urge to press the ok button and I went reviewing. But imagine with 50 more storyboard changes how big the temptation could have been.
If UI had been made in code, the review process would be quicker and less painful for the reviewer since the change is expressed by just one simpler line of code.
And being perhaps the last check point before code shipping, a review needs the best conditions in order to be efficient. And an efficient code review moment definitely increases code quality.
I chose finally a side. It took some years, but better late than never.