Why I DO use Interface Builder – A rebuttal

If you are not familiar with this post on why an accomplished Developer does not use Interface Builder, I suggest you read it before reading this post.

I’d like to weigh in on the subject as some of the points shouldn’t – in my view – carry as much weight as maybe he would like them to in that post.  It’s not my intention to start a flame war, but I do have a vested interest in there being programmers who use Interface Builder, and ultimately I think that those who are against it just aren’t yet used to it or have understood what a powerful tool it can be.

Choosing Explicit over Implicit

Choosing to be explicit is my number one reason to do things in code instead … they can see right away where everything is and not have to wonder if this file has a NIB.

If you keep your project folders organized such that a folder has a .h/.m/.xib for your object then this is really a non-issue.

I have spent countless hours searching for the source of a bug only to discover it’s some checkbox in one of the half dozen inspectors in Interface Builder. If it was in code, it’s simple to glance at the view code and see the source of the problem much quicker.

If you like writing a lot of boring code to set properties that you can do in a second (and change later just as easily) then do it.  This is really a matter of style.  Interface Builder is just a part of a toolchain.  I also am a very visual person, so I have a better overview of what’s happening with a NIB.  Most of the time you are dealing with 2 inspectors.  The “I can see it all in code” argument only really applies if you already know what the default properties are supposed to be; so again, you had a learning curve with that.

Tight Coupling

It is much harder to use Interface Builder for reusable views….

I don’t really understand the meaning of this.  I’m starting to suspect that it’s just a matter of experience.  Perhaps part of you just doesn’t want to embrace it?  As an iOS coder, I ‘grew up’ with it, so can’t understand why people don’t want to use it.  (If you want to know how to easily create reusable instances of a UIView from a NIB)

Not to mention, if you use lots of custom views, your NIBs will just be a bunch of invisible boxes. So now you have this tight coupling that is even harder to work with if you were to just lay it out in code.

Did you know about this?  There are a lot of runtime attributes for your custom classes you can set up in IB.  Also, it’s a tool to build view hierarchies.  I don’t know what this argument really is.  I really don’t understand how using IB is any tighter coupling than in code, because it’s a code generation tool.  In fact, getting your programmers to use it could guarantee that they adhere to a Model-View-Controller pattern precisely because they are prevented from writing too much view code beyond keeping their views vapid and vain; IB helps ensure that.

Have you ever sat staring at some code wondering why it’s not working, only to realize you didn’t connect the outlet or action? I hate that.

I don’t know what to say here.  Programmer error?  Rookie mistake?  I’ve been there too at some point.  It’s just a learning curve.  Don’t you hate it when an app crashes and you don’t know how to debug it?  I hate that too.  😉  It should just work like I imagined it.  I will concede that there have been times where I have forgotten to set the delegate, but now I know that this is a source of error once I notice the methods not being called.  I guess one can chalk it up to experience.

Working With Others

Have you ever had a merge conflict in a NIB. It’s the worst…. if it gets automatically merged wrong, you might not notice until runtime. With code, you can read the diff and understand what’s happening.

This is where I definitely concede with you, but this is in my experience not a big deal.  How many developers does it really take to position objects on a screen?  I’ve never been on a project where a developer has said “hey dude, are you done with the NIB file yet?”  (Storyboards not included.)

It’s Part of Xcode

Xcode is not the most stable piece of software in the world. The text editing part works pretty well. Every time I get a crash while editing a NIB, I grumble to myself and wish it was code even more.  The less I have to use Xcode for more than anything except a text editor with completion and a compiler, the happier I am.

Two things; it sounds like you just don’t WANT to like Interface Builder, and two, you’re not one of those VIM guys, are you? 🙂  Anyway, if you don’t like Xcode, you might try AppCode if you’re not using it already.

Location, Location, Location

Layout code is not hard. Trying to work with auto-layout in Interface Builder is maddening … it’s so simple to just override layoutSubviews and do your thing.

True, and true.  Let’s not forget that time is of the essence, so spending time writing lines of code that can otherwise be set with a mouse-click is a task for people working jobs with big budgets.  For the rest of us, anything that will speed up the amount we can get done (well!) is appreciated.

You can simply reuse your code instead of create this tight coupling.

I still don’t understand how you think there’s tight coupling going on.  But anyway, with IB I set the rough position and the auto-resize properties, then do the rest in layoutSubviews as well.  Screw Autolayout.  I don’t know anyone using it, or who has a real use-case for it.

Bottom Line

Interface Builder itself is not bad.

Agreed.

It does encourage bad practices…

I completely disagree, and still haven’t found where you’ve made your argument for this, sorry!

…prevents reusability (making working with others more difficult)…

How?  I just don’t see your argument here.  It gets compiled into code.  A chunk of code with an interface (outlets and actions).

…and slows your workflow.

If this were true, why would it exist?

Personally, I avoid using Interface Builder (including storyboards) as much as possible. All of the projects I’ve worked on since 2009 haven’t had NIBs unless it was out of my control.

Storyboards are a slightly different topic that I’ll just leave alone.  I don’t use them either because I actually want to write controller code, and I think Storyboards take too much of that away, but feel free someone on the interwebs to dispute that.

I think you should save yourself some time, learn a few things, and start moving to code. We are programmers after all.

We are creative people who solve problems, we programmers.  If you were a carpenter, you could saw everything by hand and talk about the purity of your craft, or you could get yourself a fancy woodshop and produce products at a faster speed.  So, your job as a programmer is to build something, and build it well in the quickest amount of time possible.  If you think this is best accomplished without Interface Builder, then that’s your right.  But ultimately all I can say about the “I can’t see what’s happening” and “it slows my workflow” arguments is that you just need to gain some experience with it.  I think it’s a fantastic tool that helps one get an overview of what it’s going to look like at runtime, and saves one having to write a lot of boring code.  You can even drag elements onto your .h/.m files and it will automatically create the outlets for you.  So much LESS typing, allowing you to focus on interesting parts of your application.

If you really are against Interface Builder, then I suggest having a look at DCIntrospect, a very very handy tool that allows you to tweak your view hierarchy (especially frame positioning so you can nudge a view to the left, right, etc until it’s *just right*) at runtime, so at least you don’t have to nudge a frame’s value, compile, run, check, repeat until correct.

Advertisements

6 thoughts on “Why I DO use Interface Builder – A rebuttal

  1. Couldn’t agree more. The other dude’s post reminded me of everything wrong with the ruby community. It’s a shame that noobs will read that pre-madona crap. Better advice is just go and watch the WWDC videos and get your head out of your backside thinking that because you are a l33t programmer/”accomplished developer” (ie egotistic and crappy software engineer) in ruby/php that you now know better than apple.. though I thank the Lord for people such as Sam Soffe, as they guarantee that those of us who make the effort to master our craft get good paid work, and can simply point at their ignorance to justify our well earned rates.

    Well done for standing up to this willful and arrogant ignorance, sir.

    • Hi George, thanks for tuning in. That other dude was indeed Sam Soffes, a guy who has made lots of great stuff for the iOS community and I’m not bashing him at all. So it’s not my intention to stand up, per se. I hope my tone was one of friendly discussion. Just wanted to clear that up in case there was any confusion. At the end of the day I hope we can all remain one big brotherhood. 🙂 I just like tickboxes and I’m a very visual person in terms of learning, explaining, and dating.

      I don’t think Apple would create that stuff if there wasn’t value in it. They’re not exactly a feature creep kind of company. Well, not until recently perhaps. 😉

  2. I just stumbled across Sam’s article and I’m glad someone replied like this.

    On the subject of Storyboards. I think a lot of people take the assumption that they are there to REPLACE ALL THE NIBS! Certainly that’s what it looked like when they first arrived. Define all your view controllers and structure in one place! AWESOME!

    However, over time I have come to find them a lot more useful for defining smaller parts of apps. Like separate workflows or patterns. For instance, I had a storyboard in an app that was my “select and edit a photo” workflow. I would instantiate the storyboard and the initial VC and present it. The storyboard then did everything. Select the photo from a collection view. Edit the photo. etc… Then the workflow was dismissed and that storyboard was gone (until I needed it again).

    Just how view nibs and view controller nibs can be reused storyboard “nibs” (sort of) can be reused too.

    I agree with your main idea though. A true artisan doesn’t only do things “the hard way” but can make use of all the tools at their disposal to help creating their masterpiece.

    I know this post is over a year old now but I’d love to hear if you’ve used storyboards since writing and what you think of them now?

    • Hi Oliver, thanks for your comment. Yes, I use Storyboards a bit more now as I do find them convenient. Not so much of a fan of segue identifiers, because you can’t reference a constant, leading to potential typing mistakes, but the approach is cool, and I like that in Storyboards you can create static content cells, which makes menu creation really fast (if you don’t have to localize).

      I have to admit, there are so many technologies I still have to master as I’ve been tied up with projects for the last 1.5 years and didn’t learn them in that time. So I can’t comment on all the benefits yet because I feel a little behind the times.

  3. Hi Oliver, just doing some housekeeping and saw your comment again. I do use storyboards much more now. I personally like them as it saves a lot of time writing boring code. I admit, I’ve been much of a lone wolf on projects, so I can’t comment on the issues one faces that relate to merging storyboards, but as you point out, with proper architecture, you can break your app down into sub-storyboards.

    The thing about storyboards that I don’t know is Apple strategy or not, it pushes iOS development further into an area of expertise and furthers the gap between platforms. I really can’t talk to Android developers about anything other than to say “Apple makes it pretty easy and not boring”, but when you consider the idea of Storyboards, Auto-layout, NSFetchedResultsControllers, CoreData, and so on, Apple has quite the ecosystem in place.

    Anyway, Apple wouldn’t make these technologies available if they a) didn’t believe they solve the problem for most, b) didn’t develop them to improve their own workflows.

    Now I wish they would stop developing new API’s and just improve and stabilize what they have. I’ve been noticing across the board that Apple products just start doing “weird things” and aren’t as stable and reliable as they used to be.

  4. I also ran across Sam’s article and was aghast. An “accomplished programmer” arguing that a tool that allows you to develop faster is a bad thing?

    Usually when I read things like that I can easily break the arguments down:

    a) they found the tool hard to use so didn’t bother learning it
    b) in order to justify (a) they have to come up with weird reasons
    c) the weird reasons usually are because they are naive (whether accomplished or not)

    I agree with you that his “you can’t reuse code” was more a lack of understanding on his part. I developed a product where I designed the UIController once in IB and reused it five times. Yes, it required me to think for maybe 10 minutes, but I’m not averse to thinking.

    Working with others: if he thinks NIBS are the problem, he really hasn’t worked that much in a collaborative environment.

    However this was the most bizarre sentence: “It does encourage bad practices” – which apparently were so important he never bothered to name a single “bad practice”. He named things he didn’t like, which last I checked, is not a “bad practice”.

    Lastly, there is no way he can generate a proof of concept faster than Interface Builder. I can have one completed before he manages to code up one screen. There is fantasy and there is reality. I’ll stick with reality.

    Good response to a pretty silly piece.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s