I'm coming around to the point of view that storyboards cause more problems than they solve but throwing out xibs entirely seems a little extreme. Are they really doing all their layout in code?
There are a lot of pros and cons of both. I used to spend a not insignificant amount of time trying to moderate debates between iOS engineers who favoured one approach versus the other.
Doing all your layout in code isn't inherently bad, and there are lot of Apple written apps that do this (conversely, some of the newer iOS built-in apps do use NIBs). The main problem that I've found with layout entirely in code is that whilst it's fine for you, the sole developer, once you bring in more people onto the project you can have problems with getting people up to speed on what exactly is going on where.
Of course, the solution to this is to enforce strict coding standards over how to layout the views themselves in code, which Google clearly do. And as the article points out, resolving merge conflicts in code is somewhat more enjoyable than in nibs.
That said, just as programatic layout isn't inherently bad, neither is leveraging interface builder strategically. Here's a good example: iPhoto on iPad has a completely custom interface that's mainly laid out programatically, but certain key elements are actually composited together in IB. For example, the brushes that slide up when touching up photos are being brought in from NIBs, but animated and manipulated in code. Using the nib file to load in the images reduces the code without sacrificing understanding (or at least, that's Apple's argument. There's a fantastic WWDC 2012 session that covers how the iPhoto UI is put together in more detail).
The TLDR; - the only risk of programatic layout that I see if developers going 'off piste' and laying out in a non standard way. With the right coding standards you should be fine.
To me that implies that one essentially makes the other redundant but I prefer to see them as two powerful tools in my box that each have their uses. I've always thought the people that insist on doing everything in xibs were a little weird but going too far the other way doesn't make sense to me either.
Do you happen to know the session name or number?
- easier version control and code merging
- you don't need Interface Builder to review the layout code
- code is easier to search, e.g. for the use of certain controls (Xcode doesn't support searching XIB files)
- code can be parameterized (you can e.g. use global constants for font sizes, colors and margins)
- layouts that follows certain rules (fixed heights and margins etc) are sometimes easier to build with code, especially when the number of visible controls is variable or some controls are only optionally displayed
- you can easily refactor aspects of the layout into reusable components (i.e. functions or classes)
Of course there will always be cases in iOS apps where layout in code makes more sense though.
Just looking through my open projects right now, all of my ViewControllers have a buildUI method right under ViewDidLoad.
I haven't made many more iOS apps after that, so I can't really say that with lots of experience, but still. As long as you're mindful of how you structure your code, it's not extremely difficult to maintain.
http://www.reddit.com/r/programming/comments/15jjfi/why_i_do...