[adomanico]

Am I missing a joke here?

Interface builder, xibs and storyboards are very useful tools for even extremely large projects. Makes building and maintaining the UI extremely easy.

The idea that because a tool is easy to use is somehow indicative of the skill of the person using the tool, is completely bogus. Interface builder has a lot of advanced features for setting up complicated UI.

You could quite easily argue the opposite for someone who needlessly creates all of their UI in code rather then in interface builder.

[s_dev]

Storyboards are wonderful if you're a lone iOS dev with little need to collaborate and great for prototyping new designs. However on large projects with plenty of git merges between multiple users I think theres a good case for avoiding.

[ropiku]

It's definitely not a good idea to have a single or few storyboards but you can even link storyboards. In my personal opinion splitting into a storyboard per main feature/area is a good balance.

[st3v3r]

I don't. It's not that hard to talk with the other devs on your team to avoid those merge problems.

[cwbrandsma]

I'll chime in, having done IOS apps for many years now...I have fully given up on Interface Builder and Storyboards. I build all my UI in code and find it works MUCH better and I spend much less time fighting with the UI. I used to spend half my time fighting with interface builder to get the layout right. Move one element that something else is constrained too...f' your everything. Oh, and setting up constraints in InterfaceBuilder...don't even. Such an amateur implementation I can't even believe they shipped it. (The code implementation isn't that bad tho)

Then wire up my events, if you refactor anything...boom -- but only at runtime. Because the compiler is wired into the process, so if a method/property doesn't exist in the ViewController that InterfaceBuilder is expecting, the compiler doesn't break, your app does.

Also add in how often Interface Builder crashes XCode.

[dep_b]

Your inability to set up constraints in IB is just that: your inability. I get very complex things done including animations in IB.

The time gained by not having to restart the app every time you tweak the UI is immense.

I generally use storyboards to set up navigation, but depending on the project I'll do the majority in code (lots of similar screens) or do every screen by hand with some common controls in code that render in IB when every screen is really different.

I am no too dogmatic about it, I will touch the subject when interviewing people but I am more interested in a balanced view than rabid hatred for either method.

[illuminati1911]

This.

When I was beginning iOS development I tried to learn it as well as I could because I though that everybody uses them because it's the "Apple way of doing things."

However just like you...when I had to start implementing constraints with it, it was the last time I ever touched that horror.

[epx]

I was rejected in a job interview quite some time ago, probably because I defended encoding UI in code, instead of using Storyboard. Sometimes destiny saves you from trouble.

[jarjoura]

Most big companies (Google, Facebook, Adobe, etc.) have internal UI frameworks that you share amongst 100s of developers and dozens of projects. Your interviewer should not ding you using code to build your UI. If anything, that's a plus as it should help you have a deeper understanding of how UIKit pieces things together.

[illuminati1911]

Am I?

We can start with what the author just said.

1) It saves you from crashes and other crap

2) If you are collaborating with anyone ie. using git you can forget about them anyway unless you wanna face merge hell.

3) Interface builder is difficult to use, is definitely lacking advanced features so you'll end up putting some UI logic in the code anyway => more complexity, more error/mistake prone etc.

I have to say I'm a bit surprised to see this kind of reaction here on HN. I never thought anyone real developer would use them for anything else than just quick prototyping maybe.

[st3v3r]

Anytime you dismiss something as things that "real developers" don't do, you're going to get a huge backlash, and rightfully so.