Why I Don’t Use Interface Builder

iphoneBlog

For iOS development, I don’t use Interface Builder. I haven’t willfully used a NIB (when I say NIB, I mean Interface Builder file, not the specific format) since iOS 2.0. In the past, I’ve worked with a few folks that really liked using Interface Builder. This is an argument I’ve had over and over.

Instead of mindlessly arguing on one side or the other of this, here’s my “go-to” points when I’m trying to win someone over.

Choosing Explicit over Implicit

Choosing to be explicit is my number one reason to do things in code instead. If someone new to the team opens up a view or view controller, they can see right away where everything is and not have to wonder if this file has a NIB.

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.

Tight Coupling

It is much harder to use Interface Builder for reusable views. I constantly create little views and reuse them all over the place. That’s kind of the point of working in an object-oriented environment. If you use Interface Builder and have outlets and forget to connect the outlet in the second place you use it, you crash at runtime. This is terrible. This introduces a whole new class of bugs.

Now we have this thing that crashes simply because we’re using Interface Builder instead of using code. If it was the exact same thing in code, it wouldn’t crash. Even worse, the compiler can check this for you.

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.

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.

Working With Others

Have you ever had a merge conflict in a NIB. It’s the worst. (Granted the XIB format has helped, but it’s just awful instead of impossible now.) If you’re working in a large application with several developers, you will waste an enormous amount of time dealing with this issue.

The worst part is if it gets automatically merged wrong, you might not notice until runtime. With code, you can read the diff and understand what’s happening. NIBs (in either format) are not human readable. This also makes looking at the history of a file useless. If it was code, it’s just Objective-C. We’re good at that.

It’s Part of Xcode

This used to be more of an issue, but I think it’s still worth mentioning. To put it lightly, 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.

Location, Location, Location

Layout code is not hard. Auto-layout is a bit more code than traditional layout, but it’s still not bad. Trying to work with auto-layout in Interface Builder is maddening. Setting outlets to control built-in constraints is just silliness.

It’s so simple to just override layoutSubviews and do your thing. Personally, I find this much easier to work with than auto-layout for most things.

I think this is a lot of people’s biggest fear is working with layouts in code. Once you get the hang of it, it’s so simple. Making your app universal becomes much more trivial than making separate NIBs for iPhone and iPad. You can simply reuse your code instead of create this tight coupling.

Bottom Line

Interface Builder itself is not bad. It does encourage bad practices, prevents reusability (making working with others more difficult), and slows your workflow. 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.

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

Free Workshops

Watch one of our expert, full-length teaching videos. Choose from either HTML, CSS or Wordpress.

Start learning

Sam Soffes

Sam Soffes is an iOS and Ruby Developer. He is the co-creator of Roon and the VP of Engineering at Seesaw. Follow him on Twitter: @soffes.

Comments

35 comments on “Why I Don’t Use Interface Builder

  1. I struggled when I first started iOS programming with using interface builder, I felt more comfortable doing things in code. A lot of the tutorial books out there start you off with interface builder. I find the comparison similar to drag-n-drop interfaces like dreamweaver versus pure hand writing html and css. You seem to get more control over the layout, though it does seem to take longer time.

  2. I’m with ya nearly 100%, but the problem I commonly run into is being forced to deal with frame coordinates manually versus seeing them in visual form in IB. When I forgo interface builder I spend a TON of time tweaking X / Y coordinates to get elements placed appropriate. Have any good tips for tackling this problem?

    • Try XRay Editor (@ mireus.com), it enables you to position your views while running the app in real time. For me its a huge time saver.

    • I usually open up Photoshop (but something like Acron, etc will totally work) to measure stuff from the designs. I often take screenshots of the simulator and measure that as well to avoid guessing.

  3. - Storyboards have helped all my new team members understand the arch of the application much faster, they comment on how much it helps them.

    - When creating a universal application, I create the entire thing for iPhone, then shift click all my scenes and drag them into an iPad Storyboard. ALL the connections, outlets, segues, etc. are brought over and it is incredibly easy to shift stuff around into a split view controllers, popovers, etc. It’s fast and effortless.

    - I built the first version of Calvetica in pure code, not a single xib, because that’s how I was taught in school. It’s clear that Apple encourages the use of IB, so I decided I’d do it how they suggested and buckled down and learned IB and have never looked back. I can build and app in half the time than if I laid it all out in code.

    - IB has led to much much much smaller classes in my projects and that has helped me concentrate and make sure that what code I do have is correct. IB helps me focus on what I need to focus on.

    - MVC is more beautiful when your views are xibs, it helps draw a very distinct and clear line between your views and controllers, which most beginners often blur.

    - Along with that, IB allows you to keep your classes clean, they only have logic, which is what code is for. Location, Location, Location: don’t mix displaying the UI to the user and responding the user’s interactions with that UI in the same class. I don’t, and my classes are small and focused.

    - Again along with that, having your UI CREATION in IB files and your UI REACTION in code is very “explicit”, much more than mixing it all in code. Everything having a place and everything in it’s place is much more explicit than, “It’s all in code…somewhere”

    - I only use IB to build app specific interfaces, so tight coupling is ok and not a bad design practice. But, much like @selector(method:), you must watch your ps and qs and not leave dangling outlets/actions in your IB files.

    - Not sure if I’ve ever used a better all around IDE than XCode, not sure why having IB in it tarnishes IB’s credibility.

    - I’ll concede that if you’re building a very custom app and not using UIKit much, building a UI in code makes a lot more sense. If you’re relying heavily on Apple’s frameworks, you should use IB because they’ve designed IB to help you use their frameworks correctly and quickly.

    - I’m writing a mac app right now with TwUI, so no IB at all and it is not always clear where to put UI building code. layoutSubviews is not always the best solution. Use Xibs and when viewDidLoad or layoutSubviews is called, you’re already all set up, so you won’t run into problems.

    - Prototyping cells in storyboards is awesome and saves a remarkable amount of time and makes it much easier to build very complex table views, something I often do.

    - Auto-layout is a mess in IB, but you shouldn’t use Auto-layout unless it actually provides benefit. If you can get away with using springs and struts, you should, and everyone would agree that setting up springs and struts in IB is much easier than in code. Auto-layout is awesome, but it’s buggy in scrollviews and a chainsaw, only use it when you’ve got complex layout/localization problems.

    - Apple encourages using IB, and in my experience, if you build your apps how Apple suggests, ensuring compatibility when iOS upgrades come is much less painful.

    - Merging Xibs/Storyboards is indeed the damning argument, but with all the awesomeness that IB brings me, I’ll put up with merging, which really only bites us if my team doesn’t communicate and we make very drastic changes to the Storyboard/Xib files.

    • Agree with your points. I think the trade offs with an all code approach clearly outweighs the trade offs of using interface builder. My projects are a combination of storyboards, xibs, and custom view classes. Sticking to just one or the other is a bad choice. It’s knowing when to use the right one.

      • Very well said. Know both methods well and use the one that is most elegant and clean. While I like Sam’s work a lot and think he’s brilliant, I don’t agree that IB should never be used. In fact, I think it should be used more than not.

    • I have to agree. I’m new to Objective-C dev and am open to other ways of doing things, but the Storyboard comes in handy over and over again.

      I recently built a chunk of UI all in code. I felt clever and high-fived myself, then I realized that a single IBOutlet (1 line of code) could replace 12 lines of UI definition. Keeping classes shorter and cleaner is well worth the occasional broken outlet error.

      • I want to give you some solid advice as you are new to Objective-c. DO NOT use IB or storyboards. You say the storyboards come in handy, is this because it allows you to see the flow of the app? If so then the designer of the app should have provided you with a a nice framework of the app showing the flow.

        Just because you can do the same 12 lines in 1 line doesnt mean you should, you wont learn anything or keep up with your programming skills by taking the approach. I was taught to never use IB, to never use 3rd party frameworks/libraries, and to always take small chunks of code and subclass and reuse it. I believe because I was taught and forced to code this way that I actually learned more than if I was allowed to take the easy way out. If I have to make a button all I have to do is call one of the custom init functions and its made, the difference between this easier approach and the IB way is that if I wanted to tweak one small thing I have full control over all the properties of this subclass and can edit it easily.

        I was recently brought on as the lead for a new app and the code was created up until this point in IB and story boards, I have no freaking clue what is going on. It is so much harder to look through a storyboard editor than to look at code that is structured properly. Simply by creating the ui in functions that are called in the init and then laying them out for landscape (checking for iphone5/ipad too) and then destroying them in the dealloc method (or when finished with them) makes more logical sense to me. Anyways thought I would give my experience and opinion on the topic. Also one last thing, everyone is saying it is faster to use IB and less difficult, but I was able to work with one other developer and finish and app that was all hand coded in less than 1.5 months. It wasnt an extremely complex app but some of the interaction and way we did things could have only been done easily with code. So learn the code (even go and read a C book to learn the underlining concepts of Objective-c), code your layouts (not really hard) and manually take care of memory, you will be worth more to a company if you have these skills and be a better programmer.

        • I see so many wrong things with this post. Sadly, you are speaking about your inabilities to adapt rather than the strengths of IB/Storyboards. Anyone new to Obj-C should NOT be disabling ARC. Rather, being new to the language and handling memory manually will actually cause more issues. There’s a reason that C/C++ mindset of dealloc’ing is dying with new languages – garbage collection has come a long ways and unless you absolutely know what your’e doing, you’re actually harming the application.

          The only people who dislike Storyboards and ARC are traditionalists. There’s a reason that XCode introduced Storyboards – they actually ARE much quicker to visualize and put the designs up. You still have all your base code that you have to write, XCode simply just takes care of the initWithFrame() part for you.

          And if you’re telling me that embedding 3 UIViews + UIimages and overlaying them on the same VC is easier to write in code by exact pixel manipulation than Storyboards, then you’re lying. Or being able to read that and know exactly how it will turn out.

          • I don’t see anything wrong with my post. So what you are saying is if a new way of doing something comes out I should use it and if I don’t use it then I am either too stupid or stubborn to do so. That’s quite the statement there, I think the reason the dealloc way is being taken out of languages is because people are getting lazy and programming has a high learning curve and if they make it easier on new programmers they will stick with it longer. ARC isn’t a garbage collection as GC is runtime, this is compile time. You shouldn’t always trust the compiler because I’ve recently worked with ARC enabled and it still messes up, if it does end up leaking or having a retain loop you need to disable it and do it by hand anyways or live with it.

            Using storyboards and IB forces you to have a static layout and is actually more of a pain than if you just did it in code, this gives you more flexibility with whats being made. It’s easier to base your visuals off of a data model as you can loop through what you are given for data and create what you need instead of doing that and deleting what was there in the IB file. Also have you ever tried to do version control with an IB file (really just a huge XML type file), it’s hell, almost as bad as merging conflicts in the project file. I guess I am a traditionalist but that’s not a bad thing, I was taught one way and I believe learning those skills helps you be a better programmer as you can easily go to a new language where you cant rely on helper tools or functions, also it teaches you what’s going on in the background so if you cant do something in IB or something custom you will know how.

            To do that is easier to do in code, yes. I didn’t say quicker because drag&drop is quicker when you get used to it, but that’s not the point. The quicker way isn’t always the best. If I am handed a photoshop file or a single png and asked to make the layout for it in code I am confident that I could do that very easily. I guess it’s easier for me to visualize the outcome when looking at my code than other people.

    • I was going to reply but you already addressed all my points!

      From my point of view IB SHOULD in general be used in every project. It helps implementing MVC, it is lot faster to code, it reduces the code base, it is lot easer for new developers to get into the project and it can help out a lot reusing viewcontrollers (same view controller for every plattform, different IB views that automatically load without a terrible if (IPAD) statement). Projects are much nicer when proper use of IB is done.

      For me, the only valid point to not use it are the merging issues (only to consider if the app team is bigger than 3-4 devs) and the difficulties that global constants such as colors or fonts introduce in it (but there are tricks to get it in IB also).

    • For me Storyboards have been a huge waste of time. Pushing stuff onto a navigation controller or showing modals is one line of code. Depending how you present things, you can’t always go back. So now you have code to go one direction and not the other.

      Personally, I find the visual map of my app really useless. Even for simple apps, it’s usually more complicated than a simple Storyboard.

      Anyway, if you are productive using IB or just Storyboards, have at it. If you’re productive doing it in assembly, have at it. I think trying without IB is a good learning experience, but everyone should do whatever works for them. Personally, I think if you’re using IB or Storyboards, you have the opportunity to be more productive.

      • If you’re only using one solution or the other, then you have the opportunity to be more productive.

        Interface builder isn’t made for dynamic, complex operations….so don’t use it for that. Use it for general layout, flow, and static items. Everything dynamic can/should be done in code. If you spend time with ‘perfecting’ static elements in code (especially with a designer), you’re wasting time….especially if you have a designer that can understand Interface Builder enough to get the basic view elements correct on their own. Most of the problems with Interface Builder come from trying to force it into doing complex things (like reusing views in different places). I’ve seen some really twisted Interface Builder setups where someone tried to do everything in IB. It failed miserably, and was glitchy. On the flipside, I’ve seen UI code written that is so dense and unreadable that spending 30 seconds to do it in Interface Builder would have solved a lot of issues.

        Its best to use each tool for what its best suited for…and Interface Builder is best suited to handle static elements, layouts, and navigation flows, while doing the UI legwork in code.

      • I agree with Brendan in response to your last statement: “If you’re only using one solution or the other, then you have the opportunity to be more productive.”

        You’re clearly of the opinion that IB should never be used. But every time I hear/read someone complain about IB, I think, “How are are using it?” I can’t help but ask that because after extensive experience building *both* code only *and* IB heavy apps, I cannot relate with the complaints against IB. I have complaints about IB, but I’m too consumed by my thoughts of praise and gratitude for it that I just don’t have time to talk it down.

        And to respond to any argument that I, or anyone, is biased toward what they grew up with: I refused to learn IB for the first 2 years of iOS development. When I decided that Apple is probably pushing it for a reason, I buckled down and began the grueling task of learning to use it efficiently. As time went on, I had less and less interest in manually writing objective-c code to build my UI instead of letting IB write xml to build my UI. It’s *all* code, but having the UI building code tucked away in a xib keeps my classes clean and focused.

        It’s an enhancement to MVC. With IB, the view is split into two sub parts, a part that builds the UI (xib) and a part that updates the UI (view class). It’s fast, efficient and clean.

      • Here’s a more broad and beginner(ish) perspective.

        Currently I’m writing my first iphone app and I’m heavily investing time in learning Interface Builder and I dabbled a bit in doing stuff programatically. You could say I am a bit experienced in doing views programmatically since I wrote my own OpenGL application in Java (and my own shaders with bloom effects and all that fun stuff :D ) in a Computer Graphics course. So in a way I did see (most of) both sides.

        I’d argue the following: you can’t really know which technique is better unless you at least make one simple app with each method (i.e. along the lines of one table view, a collection view and a navigation view and some general buttons doing stuff).

        Currently I am experiencing both the drawbacks and the pro’s of using IB. I also experienced some of the described pro’s and drawbacks in my OpenGL projects (I wrote my own objectloader so every object that was defined in vertices could be quickly reused). I did get stupid errors when compiling, but I now also know how to recognise them quite fast. Also, since IB is the most “buggy” part I look there first and since I know which class is complaining I know which view to look in. It’s just an example that there are workarounds and this really is a preference part if anything else (like every Vim and Emacs debate that I saw).

        For me what will be a major factor is the hours put into the project. I know that I am currently on 60 hours of developing my first app. I’d be curious how many hours that will be when I do a similar app programmatically. I have to take into account a bit of a learning effect (because I know protocols and delegates a bit better) and it’s a crude measure, but I think guided by some critical thinking it could be a good enough measure nonetheless.

        So for me the jury is still out.

    • There are some great points in this reply that match up with my own experience and preferences. I like to keep my MVC components separate whenever possible as I’ve had an easy time updating apps where the distinction is clear and a tough time when it’s combined. Sam raises some excellent points in this post and I have written some things in code, but I’ve primarily worked on things that don’t have too many custom views.

      I think the real takeaway if you’re new to app development is to familiarize yourself with both so that you can make your own informed decision. That’s one of the things I love about software development: there are so many different ways to solve problems and I love seeing what people come up with and how they work.

  4. For iOS development, I don’t use Interface Builder. I haven’t willfully used a NIB (when I say NIB, I mean Interface Builder file, not the specific format) since iOS 2.0. In the past, I’ve worked with a few folks that really liked using Interface Builder. This is an argument I’ve had over and over.
    Instead of mindlessly arguing on one side or the other of this, here’s my “go-to” points when I’m trying to win someone over.

    ______________

    sisteme supraveghere video

  5. As a new coder I’m using IB because it’s how I was taught (thanks iTunes U). An added benefit I find with IB is that it helps to keep my app ‘correct’ with regards to the HIG.

  6. IB is about Organizing, not about Replacing. IB is a tool, not a regulation.
    Once you know the limits of IB and developed good programming habits, IB can be extremely useful.

    I saw too much terrible spaghetti codes, which could have been helped by adopting MVC principles and knowing the life cycles of UIViewController & UIView instances.
    As a way to help those developers to learn about the principles, I show them how to complete a project using IB and later replace it using only codes, to help them to realize the limits of XIB files and see how whole structure is preserved, to show the real reason for using IB: Separating codes.

    And once VIEW components are separated from others, I point out patterns or repetition, which are just configurations at loading of the instances.
    Other than iteration, they are not so easy to be solved creatively and quickly, without taking precious seconds, minutes, or hours.
    Also, there are more important tasks for fulfilling the requirements of the app, than tasks for calculating frames for labels.

    Unless you like it (I saw some people who like it), it’s smart or even necessary to use a tool which was developed to avoid working mechanically. Fortunately in Xcode, we have Interface Builder.

    Depending on the characteristic of the projects, the decision to use or not to use IB is totally up to the developers. When they decide not to, I hope it’s fully informed and experienced one, instead of one caused by estranged or uncomfortable feeling toward IB.

  7. I think it’s a bit futile to try to convince people. Everyone has their own path. If you didn’t ‘grow up’ with IB, then yes, it might always seem like a fight. I started developing apps with IB as a part of my toolchain, and so I don’t shake my fist at the sky if something crashes due to IB. Because I know what to look out for, just like experienced coders do when something goes wrong in code.

    I find IB greatly reduces my time to implement UI code. (Especially given ctrl-drag view onto assistant editor’s .m file) I’m also a visual person so I find it easy to take the designs from designers and put it together in IB so I can compare to the .psd. I also like how one can set runtime attributes of custom view classes, so there’s also very little to configure there.

    But I know it’s not for everyone. I know there are drawbacks. One can use it on a basic level and benefit from it, or delve deeper. Creating re-usable views has never been a problem if you create views from NIBs (http://horseshoe7.wordpress.com/2013/04/05/quick-reference-load-a-uiview-created-in-a-nib/)

    For those who just wanna do everything in code, I highly recommend using DCIntrospect, available on github. You can adjust and resize your views in the simulator in real time. It’s really amazing. Or even recently http://www.sparkinspector.com

  8. A rebuttal in support of IB:

    * Choosing Explicit over Implicit:
    If your project always uses IB for views, you know to look for a xib. I always group xib files right along with view controller files so it’s really obvious there is a xib (sample projects often leave xib files under resources, which hides them).

    * Tight Coupling:
    I reuse views all the time. I have a xib, and a custom view class that the xib is based on – thanks to UINib I can easily load the custom view and make use of it everywhere. The key in the xib is to wire all elements to the top level view, not file’s owner (it’s also how you can easily make custom table view cells)

    You also don’t get a crash by not wiring a connection. You get a crash if you have a BAD link, big difference. And it also spits out a really helpful and verbose message which tells you exactly the problem.

    I find coding UI elements to have a worse problem, in that you can easily miss code that sets some aspect of the UI that you notice right away is an option to set in IB. Frankly the tedious setting of things like label attributes is one of the biggest reasons why I mostly use XIB files and try not to do that kind of work in code.

    * Working With Others:
    I’ll grant you that two people making changes to xib files doesn’t work well. But in practice mostly one person is working in a view. This is a WAY huger problem for storyboards, you cannot reasonably expect only one person will ever be working on the UI for every screen in the app.

    * It’s Part of Xcode:
    You wrote “Every time I get a crash while editing a NIB”… but I thought you hadn’t use nib files in years? The comment shows; I have not got a crash editing a xib in quite a long time (storyboards are a different matter).

    * Location, Location, Location:

    Any view you can share between iPad/iPhone can be just as easily created in a xib file as in a custom view. I will agree that auto-layout is easier to define in code, although I don’t think that has to be true… traditional springs/structs auto-resize behavior is vastly easier to understand by reviewing in IB. There’s no need to use auto-layout for all views (well, unless you are using a Storyboard where use of autolayout is a global setting!!!!!!)

  9. While you have a few valid points most of it is clearly due to lack of experience and understanding of IB. I used to do everything in code as well but that is insanely verbose and the chance of introducing memory leaks is MUCH MUCH higher using code. And even though I got to the point where i could setup any interface in code it still takes a lot more time than using IB.

    Then there is the whole issue of not adhering to a proper MVC structure, not utilising the tools that can speed up your work(And make it more robust at the same time), just means that doing it in code is a bad decision unless we are talking about a very very custom layout with some very specific issues.

    Your point about IB/xcode crashing is just invalid in my experience… In the last 3 years I havent had xcode crash a single time due to IB. On the other hand I’ve had Xcode crash when using certain refactoring functions in the editor, I’ve had the editor loose track of syntax highlighting and autocomplete, I’ve experienced the debugger hanging and loosing connection to the device/simulator etc.

    Xcode isn’t perfect but it is, by far, the best IDE I’ve ever used… And i’ve used just about everything from old Borland IDE’s and Interdev all the way up to Visual Studio and Eclipse.

    It’s always good to know how to do the UI both in code and IB, but suggesting that people should do everything in code is definately three steps back and should be avoided. Keep all your layout in IB and only do stuff in code if it really isn’t possible in IB(Reuse can easily be done with IB).

    It will leave you with a lot less issues of memory leaks, much smaller and cleaner classes and a MUCH faster work process(Especially combined with storyboards). But as everything else, it does require you to properly learn to use the tool and commit to it.

    • xcode is better than anything else — from the likes of borland, msft, symantec et al.

      but IB sucks major ass after Xcode 4. dog slow. unusable actually. thanks be to odin that i kept IB 3.2.5.

  10. Do you have a simple app on GitHub that shows how you actually deal with layout, different screen size etc? I’m just curious, and I think it’s easier to show “the light” in code.

  11. I thought IB was incredibly slick when I was starting out. Defining states on actual objects, and then rehydrating at runtime allows for wysiwyg design – so cool. And it helped me to get up to speed in other areas faster.

    Later, I came to agree with all the points Sam outlined in his post. Once I got the hang of things it became more fluent to do it in code – easier to modularize and reuse, easier to layout, easier to merge.

    There was a comment about how Interface Builder promotes separation of concerns. This can be true, but it also can promote huge view controllers, and prevent encapsulating related custom views. Only the UIKit classes have visual queues, so your own custom view types are difficult to use.

    Regarding the comment that IB is the way Apple designed. I think its a great way to get started (and if it works for you – to continue), but I have it on get record that hardly any Apple apps use Interface Builder themselves.