[illuminati1911]

"In server-side Swift, you don’t use interface builder, so that reduces most of your crashes to none."

You don't use that in iOS app development either unless you are completely insane or are just beginning iOS development and don't know how to make UI properly.

[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.

[armadsen]

I'm not insane, and was doing Cocoa programming years before iOS existed. To each his own, but I'm not willing to work on codebases that are dogmatic about _not_ using IB. Use IB where it makes sense (most places), do what needs to be done in code in code. Interface Builder was one of the selling points of development on NeXTStep...

[jarjoura]

For the first several releases of OS X, you actually couldn't build a Cocoa application without the corresponding Nibs to go with it. Apple's frameworks didn't expose all the hooks necessary to write your UI entirely in code, nor would you even want to. It's cumbersome to create a cell and then attach that cell to a NSView and then bind it to a NSWindow.

[st3v3r]

Not close to true. If you don't like using IB, that's fine and your choice. But many of us prefer using visual tools to lay out our UIs, so that we can see how it's going to look without having to compile and run the app every time and then navigate to the screen.