[danilocampos]

As long as the beginners are drifting by, lemme say this:

Every nib you use is a boatload of code you don't have to maintain. Use nibs. Can they solve every problem? Goodness no. But they're a great way to get the basics of your views laid out. They give you an easy way to preview the behavior of your view when layout changes.

And they're very forgiving when you change your mind. Changing text alignment? One click. Want to change the balance or padding of some elements? Nudge them around with a real time preview until you're happy. Mess with different color combinations in your UI to your heart's contentment.

Doing all your view layout in code gets damn tedious when you have to compile and run each time to check your results.

Every now and then some crackpot will come along and tell you never to use nibs. Ignore them. Use nibs when they make sense for your workflow. End sermon.

[mmariani]

Another reason to seriously consider using nibs instead of hand coding UIs is Auto Layout. It is way easier to deal with that API in IB. Of course you can in code too. But every new API has its problems. Most commonly, they're a pain to deal with due to unexpected behaviors and incomplete documentation.

You all have been warned! ;)

[fphilipe]

Auto Layout is pretty much the only reason nowadays I'd use nibs at all. Unfortunately, they are iOS6 only. If you want to support the previous major version you'll have to wait until iOS7 before you can really use that.

[sandofsky]

In all the teams I've worked on, designers have worked out pixel positions and text alignment by the time I see the mocks. I don't find much value in realtime feedback.

Nibs are handy if you're sticking to stock UI and stock behavior. Programmatic layout takes longer to setup the boilerplate, but once it's in place, I find it about as easy to work in code as nibs. With complex designs, I find it significantly easier to work programmatically.

[danilocampos]

> In all the teams I've worked on, designers have worked out pixel positions and text alignment by the time I see the mocks. I don't find much value in realtime feedback.

Very few beginner iOS developers will have a design team at their beck and call.

[kalms]

But some of us are both ;)

[danilocampos]

Quite so! As a beast of just such a color, I love nibs. Huge timesaver, especially when configuring custom buttons with different image and label alignments.

[jimbokun]

And what do you think of NIBs, from the perspective of each of those two hats you are wearing?

[kalms]

Being fairly new to this, and doing a large amount of experimenting, I enjoy being able to quickly mockup a (sort of) working prototype, without having to type too much code. During the learning process, you just want an interface, and not much else.

I guess it comes down to workflow, and that's always a personal thing.

[gurkendoktor]

Storyboards are especially great if the app is not a hundred percent mocked out. I have seen many mocks that described the app's CI very well, but have been a complete mess as far as the modal/tab/navigation flow is concerned. In the last app, it took a few storyboard iterations before everything was logical and these iterations would have much more painful in code.

[cageface]

Bingo! WYSIWYG is for the designer. Developers need powerful declarative tools that support modular development, reuse, internationalization, flexible layouts, and work well with version control.

[ihaveajob]

True. But for a beginner iOS programmer (the intended audience of this write up), it makes absolute sense to use nibs as much as possible. I know it helped me a lot.

[mikec3k]

I find that nibs are more difficult to maintain than creating views in code. You'll spend a lot of time trying to figure out where something is set since you can't do a global search & replace on nibs. If you avoid magic numbers, it's easier to change positions in code without lots of fiddling around.

Since I used Cocos2d (which doesn't use nibs) in one of my games, I was able to update it very easily for the iPhone 5 (despite using some magic numbers) by simply using a multiplier based on the screen size.

[makmanalp]

These used to be binary and so they'd not play well with version control. Is this fixed?

[reidmain]

They are XML now but they are so volatile that merging is still a pain in the ass.

[e28eta]

But storyboards read and merge very nicely, in my experience.

With two caveats: - the classes section will sometimes be removed by IB. Ignore it - the last section, inferred something (priority? segues? metrics?) with 5-6 entries, can cause the storyboard to be unopenable. So, when merging, if there are changes to that section in both versions, just delete the contents of the section.