Thomas Bandt

Developing iOS Views: Custom Code And XIB

While developing native mobile applications for iOS you generally have two options for creating (reusable) visual elements: writing them by hand or designing them visually with the Xcode Interface Builder.

Published on Monday, February 9, 2015

Previously

For a long time I have been a bit opinionated about that topic, because I never trusted so called 'What You See Is What You Get' editors. Although my first steps in "programming" were some HTML pages built in Netscape Composer and Frontpage Express in the 90s, I quickly learned to write my code by hand. That not only brought me some insights in how things work, I also always felt confident when something broke that I was able to fix it.

Fast-forward some years, back in 2012 when I began my development journey with Xamarin, things seemed clear again: the connection between Monodevelop (the ancestor of Xamarin Studio) and Xcode was unreliable at best. So I decided to do it manually again.

I handcraftet every single UIView in a relatively large application (more than 35 controllers all in all) and learned – again – a lot about how things work. But I also had to work around many difficulties that emerged the more complex the ideas of my graphic designer became. I ended up with a large class called 'ViewUtilities' that helped me to align and arrange views, something that's really annoying when done manually.

And at the end of the day hundreds if not thousands of debug cycles were necessary to check and fix minor layout changes. What a waste of time!

Epiphany

Lately I had the chance to reconsider my options, so I gave Xcode's Interface Builder a second chance. And hey, once I understood how that beast of an IDE works (at last on the surface) it got an really enjoyable experience.

I ended up with a mixture of code for customizing elements dependent on the state and visually created elements, what feels like a good mix. The most important thing: not only all that reapeating and code polluting standard stuff, like which font a label is using etc., can be done trough the designer, but also the whole layout:

Auto Layout is a system that lets you lay out your app’s user interface by creating a mathematical description of the relationships between the elements. You define these relationships in terms of constraints either on individual elements, or between sets of elements. Using Auto Layout, you can create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization.

You could probably do all that stuff in code as well, but even when working with constraints, things remain uncomfortable.

Advantage WYIWYG

  • Layout, meaning to arrange multiple elements. Because of great visual tooling for constraints.
  • Mockups. Drag & Drop can't be beaten by coding in terms of speed.
  • Detailed configuration of UILabel & Co. It's just faster and simpler to set all these properties visually.

Advantage Custom Code

  • Everything dynamic.

Conclusion: It's Not "Either-or"

Creating UIView elements programatically can be a valid strategy, especially when things are highly dynamic so the designer can't be helpful. But for creating "templates" with a complex set of precisely aligned elements, the "visual way" via Interface Builder today seems to be the better option to me.

So if you're in the camp of code enthusiasts as I have been, try something new (old ;)). It's worth to combine these two ways.

PS: If you're using Xamarin, the basic recipe "Using the iOS View XIB Template" may be a good start.

What do you think? Drop me a line and let me know!