New iOS Developers Shouldn’t Use Interface Builder

When I first started learning Objective-C and the iOS SDK 2.x a few years ago, one thing that I constantly struggled to get my head around was Interface Builder.  More specifically, why should I use it and how it could possibly benefit my iOS development – given that I could code a UI programmatically, and know exactly how it all worked? A colleague of mine even wrote a blog entry that mirrored my exact feelings towards Interface Builder back then.

Well over the past 6-12 months my attitude towards Interface Builder has changed. There are two reasons for this. Firstly, it’s now nicely integrated into XCode 4. Prior to that, who wanted to have 2 different apps running (XCode and Interface Builder) with popup windows spamming your desktop? That was a deal-breaker for me. Secondly, I’m now a more experienced developer. After using Interface Builder on a couple of projects, I am confident to say I am now more efficient as a developer when using Interface Builder. However, that wasn’t always the case, which leads me to my key message here:

If you’re new to iOS development, don’t touch Interface Builder until you are capable of building UIs programatically.

This isn’t the opinion of some crusty old dude proclaiming young whippersnappers must pay their dues. It’s the conclusion drawn by somebody who has always wanted to maximize their own productivity – both as a novice and a more experienced developer.

In the Beginning…

I think part of my initial frustration with Interface Builder was my lack of knowledge towards the iOS SDK when starting out. Sure, Interface Builder would let me drop a UITableView onto my view, but how the heck did I populate it with data? What the hell were all these blue lines I could drag around? Interface Builder was meant to be this awesome UI builder, but I had no idea how it worked.

Instead of learning Objective-C, iOS SDK and Interface Builder, new iOS developers should only focus on the first two.  Interface Builder will make plenty of sense down the track.

This is probably why almost all of Apple’s sample code never contains Interface Builder files.  For a new developer it’s just too much voodoo – just don’t have the knowledge of what you can do with Interface Builder.

It’s my opinion that new iOS developers should code their UI’s from scratch. Ignore Interface Builder; place it out of your mind; it should be dead to you for now. Focus on learning the SDK. For example, find out how a UITableView gets its data via a UITableViewDataSource, and how you can perform actions with a UITableViewDelegate.

Learn how to build UIs from the ground-up

I honestly feel that you learn so much more from coding all your UI’s from scratch when learning iOS development.  You can easily see where your UITableViewDelegate is, because it’s there in your code; you assigned it textually, not via some magical blue line. You will learn more of the SDK in a shorter time, and you will really get exposure to what each component is capable of.

Furthermore, Apple’s sample code by will be easier to follow and you will not lose endless nights trying to figure out why, for example, you can’t select a table row – when it’s likely you just missed connecting the blue line in Interface Builder to a delegate.

It’s easier in code if, for example, you haven’t assigned a delegate (you won’t be able to see it because it won’t be there) – rather than trawling through IB property sheets to figure out what you haven’t hooked up correctly.

Interface Builder is awesome, once you understand what you can do with it

I am not an Interface Builder hater – if anything, I am a convert.  For years I preached that Interface Builder was a waste of time; that I could do everything that Interface Builder allowed me to do – and more – if I programmatically create my UI.

But as I grew more experience, something changed. It was a case of ‘I was blind, but now I can see’.

I stopped seeing Interface Builder as this magical tool that was supposed to do anything I wanted. I began to see it as a tool that would help me setup my views quickly. It’s particularly handy for configuring auto-resizing. But it is only with experience that I can appreciate the benefits of using Interface Builder.

I now write less code and visually lay out my views and their associated delegates/references, all from within IB.  I can do this confidently because if any problems arise – such as a delegate not being associated correctly – I have seen it many times before and know where in Interface Builder I need to look to see where I have gone wrong.

Interface builder will be a great tool for you to use – just give yourself time to learn the SDK first

Those new to iOS development wrongly assume that Interface Builder can do everything they think they want to do, yet they haven’t had enough exposure to the SDK.

You will get a lot more out of Interface Builder once your iOS SDK knowledge is at-least at an intermediate level. Until then, leave Interface Builder alone – it will only cause you heartache.

This entry was posted in iPhone, Mac, Mobile. Bookmark the permalink.

18 Responses to New iOS Developers Shouldn’t Use Interface Builder

  1. someone says:

    I think one of the problems with IB and beginner programmers is: You’re not sure what you are supposed to do in code, and what you are supposed to do in IB.

    Also, does doing things in code change things in IB automatically and vice versa? I think there is a lack of documentation as to when and where to use it and how it affects your code.

    • Shaun Ervine says:

      Thanks for the reply. Your are right, there really is not enough documentation out there to help new iOS developers understand when and where they should use interface builder.

      I hope this post will highlight that new iOS developers should focus on creating their UIs programmatically and ignore Interface Builder. Once they are confident they can build any UI programatically, then and only then should they begin to explore Interface Builder and and hopefully appreciate what it has to offer.

  2. Pingback: Some great iOS links from the past week. « Pat Zearfoss

  3. Joe D'Andrea says:

    While the title of this post gave me a knee-jerk attack of “Oh no, not another don’t-use-IB-rant” , your key message is well taken. In short, “You have to know the rules before you can break them.” :)

  4. terry says:

    I don’t quite agree with this post. It makes the common mistake that we are all machines that operate and learn the same way. We are not. For you this was a more effective way to learn but for another developer it may make more sense to learn by experimenting with IB and then inspecting the generated code and property sheets afterwards to see how things work. There isn’t a another you or me we are all truly unique. This fact affects how we learn as well.

  5. Michael says:

    As a newbie to iOS programming and a current Uni student in CS, I can definitely see where you’re coming from but have to say it depends on the person like the cmmenter above said.

    Yes it’s very important to learn things from the ground up to truly understand them. In my Uni life so far, I’ve has to implement tons of data structures manually when there are libraries everywhere I could just use, but noe I know how they really work.

    In the same vain with iOS programming, o course it’ll help if you cut out IB middle, but thats going to mean that for a lot of new developers, it’s going o take them a very long time to release an app and ben be scared off iOS programming if thy take it that route.

    Whatever rocks your boat man :)

  6. Shaun Ervine says:

    @terry and @Michael I completely agree with both of you that it is up to the individual to figure out what works best for them. I guess what I have learnt from other iOS dev’s I have worked with is that Interface Builder is one of those things that can either assist or hinder you in your iOS development, especially early on.

    If you can pick up objc, iOS SDK and Interface Builder all in one go then that’s excellent! I just believe that for a majority of devs early on in their iOS development career, that it is probably less of a learning curve if they leave Interface Builder out until they have some iOS fundamentals under their belt.

    Thank you both for for sharing your point of view.

  7. Noury Janse says:

    I totally agree to you, because i’m new to iOS development and can’t understand the code generated with IB.
    Now my question is, where the heck do i find those tuts without IB. Every book has that IB in it. The Dev Guide from Apple is one big mountain of information. I need that information in pieces. Could you help me on that?

    • Joe D'Andrea says:

      One thing you can do (in the meantime) is check out Nib2ObjC. It’s not a 100% pitch perfect view of what’s under the hood of a NIB, but in many cases it’s more than enough insight! https://github.com/akosma/nib2objc

      • Noury Janse says:

        Thanks for your lightspeed fast response :)
        I prefer not to do that. I’m learning this on my university with some other students atm.
        My learning goal is to master Objective-C just by trying hard :). When searching for TableviewController & TabViewController on Google yesterday only found some tuts sing the Interface Builder :(!

      • Joe D'Andrea says:

        Understood, you don’t want to peek behind the curtain. :)

        Keep in mind, learning Objective-C and learning how to make Cocoa/Cocoa-Touch objects bend to your will are separate goals (and both noble!).

        nib2objc does give you additional insight into how you would programmatically build the same objects (albeit with a lot of extra assignments, since nib2objc doesn’t know which are defaults and which are deliberately set from IB). I do not regard it as cheating or a shortcut in the slightest. It really helped me bridge the gap and, yes, discover for myself that the Wizard was just a regular guy after all.

        Erica Sadun’s iOS Developer’s Cookbook (Oct 2011 – 3rd Ed!) may be more up your alley, as it has programmatic examples throughout … but be aware that this can be quite intense. Erica is known for full-contact, no holds barred iOS, and that can make one’s head explode if you’re not in the right frame of mind.

  8. Arik Jones says:

    It’s a very similar effect that Microsoft’s Frontpage and Macromedia’s Dreamweaver had for web designers. Great post!

  9. jim4voipji says:

    the new iOS programming book from Big Nerd Ranch/Aaron Hillegass has you programming 100% in code without IB. Its a good book (not trying to plug it) for a newbie like me who wants to see how to create views in code.

  10. Johan says:

    While I think I may fundamentally agree with you, the “new iOS developers should focus on creating their UIs programmatically [..] and ignore Interface Builder” gives me a bit of a shiver though. Because already there these new developers are failing (like we all did when we started).

    Newcomers, by definition, just don’t know neither the breadth nor depth of the SDK(s) which leads to newbie implementations of, say, creating a custom button/control by means of a UIView with an onClick block (real-world example from newcomers to my team), instead of an UIControl subclass and the responder chain.

    I’m not saying that it’s impossible to screw up things in IB (I still forget to connect outlets some times), just that learning the depth of an SDK must be done sooner rather than later and you don’t learn how to use things if you don’t actually use them.

    Besides, newcomer or not, who wants to waste their time rewriting boring positioning code of CGRects over and over again? ;)

  11. Rich says:

    Hmm…I kind of agree with the sentiment, but not the conclusion.

    I agree, when I first started coding there was a lot of voodoo going on–though, honestly, IB was only part of the problem. The Cocoa framework does so much for us automatically–it’s often hard to understand where these objects are coming from. How they’re being created.

    However, instead of walking away form IB (even if temporarily), I’d rather have new developers take a little time and get to understand how nibs work and what happens when an app launches. You don’t need to get into the deep, eye-bleeding details, but spending a few hours getting comfortable with the basics can help prevent a lot of problems later on.

    So, I’d actually advise new developers to learn how to use IB first, then start working on mastering the SDK.

  12. Don says:

    Sorry guys, I’m not only new to to IOS programming, I have absolutely no programming experience in any language when I started a few months ago. I started out like most newbies. I purchased a book and spent the first month absorbing the material before starting my first project. I used IB for almost the entire project, which I found very intuitive and easy to use. I didn’t realize how complex my project was until I showed it to my friend, an 8 year veteran. Also a disbeliever in IB, couldn’t believe what I’ve accomplished using IB. I’m no genius, there’s a lot of help out there on the internet. I’m sure if I had started out building everything programmatically, I’d just stick to what I know. I guess the way I look at it, is the old wash board is very effective tool for washing clothes, but how many of you are dumping the washing machine to go back to the wash board.

  13. Ben says:

    Hi All,
    I’m an experienced programmer on Windows and Linux, but new to iOS. I find that I am learning Obj-C well enough, but am stuggling with IB. e.g. I set a UIView to have a TopBar, bu tat run time it doesn’t appear.

    Can anyone recommend a good book for understanding how IB actually works? I’ve found that all the books and tutorials I’ve seen so far use trivial examples that don’t give me enough knowledge to debug non-trivial problems.

    IB may provide a lot of “magic’, but the cost is that it hides all the details you need to see when figuring out a problem.

  14. Guillaume says:

    Am also a kind of veteran programmer. I am new to iOs.

    IB happens to be a nightmare. Just don’t get how to get the right connections.
    When learning from sample code (my current approach), there are different methods to implement a MapView. The code you can at least read it. With the NIB file, you can see connections but have no clue how they were set.

    My issue is: I have set a link to a ViewController from the AppDelegate.
    This ViewController has a link to a MKMapView IBOutlet *mapView;

    In the app implementation file the following at least makes it work.
    mapViewController = [GCMapViewController new];
    [window addSubview:mapViewController.view];
    [window makeKeyAndVisible];

    So far so good.
    Now, going to the NIB file and checking it, I don’t know
    1. why this bloody specific NIB is loaded. If there was a second one, how to reference it?
    2. how to access the mapView present in the NIB from the app delegate or the ViewController.

    Some sample code is misleading (e.g. the Region App where the App Delegate directly references
    A few videos on YouTube had been very useful, and it is indeed impressive how fast it is possible to setup some simple funny Apps.

    Guillaume

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