Auto layout: Interface builder or code?

Discussion in 'iOS Programming' started by grandM, Feb 4, 2017.

  1. grandM macrumors 65816


    Oct 14, 2013
    Hi guys

    I was wondering why I see this many tutorials popping up about doing auto layout in code. Isn't it better to lay it all out in Interface Builder?

  2. PhoneyDeveloper macrumors 68040


    Sep 2, 2008
    Dunno. It's kind of painful doing it in code. Kind of painful doing it in IB too. I certainly prefer IB when possible though.
  3. KALLT macrumors 601

    Sep 23, 2008
    Not necessarily ‘better’, just easier. Not everyone uses IB and sometimes it may be unavoidable even with IB. I found that I had to rely on code for a project that was still targeting Mountain Lion, where the constraints had to be added/removed/changed manually to provide dynamic resizing behaviour. Stack views, grid views and enabling/disabling of contraints via outlets makes things a lot easier though.
  4. dantastic macrumors 6502a


    Jan 21, 2011
    Autolyout is clunky at the best of times.
    Doing it in code require a ton of code. Like a-lot!
    Doing it in IB is much quicker. But it can hide nasties at the same time. Often very difficult to troubleshoot when it goes wrong - or when working with someone else's file.
    There are always cases where you can only create the layout, or parts thereof, in code as well.
  5. firewood, Feb 6, 2017
    Last edited: Feb 6, 2017

    firewood macrumors 604

    Jul 29, 2003
    Silicon Valley
    If the tutorial is about coding, having to jump out and explain using Interface Builder to someone who hasn't used it before is a big wordy distraction. It's also easier for a first-time Xcode user to make hard-to-debug mistakes pointing-and-clicking in IB, than by cutting and pasting a few paragraphs of source code. Even if the UI layout is trivial or simple.

    The usefulness of IB and Auto-layout really only kicks in with more complicated layouts that one wants to run on multiple iOS device types, which is not typical for a tutorial focused on a simpler task.

    A constraint-based layout engine can also incur serious problems (lags, etc.) with certain types of layouts, so even some major apps at the tops of the App Store charts are moving away from IB auto-layout. A couple companies have open-sourced their alternative layout engines that are much simpler and more deterministic than Apple's constraint solver.
  6. grandM thread starter macrumors 65816


    Oct 14, 2013
    Reading this I'm getting the impression there is no consensus?
  7. firewood macrumors 604

    Jul 29, 2003
    Silicon Valley
    Yup. There are big companies with high rank apps using and not using IB with auto-layout. Same with experienced indie developers. Same with online tutorials. Choose your poison.
  8. dantastic macrumors 6502a


    Jan 21, 2011
    These are all tools in a toolbox. A hammer isn't the best tool for every job.
    There are cases when AutoLayout is great, there are other cases when good old springs and struts are just what you need. Use whatever works best for the job.

    If you want a fast scrolling tableview with complex cell layout nothing beats calculating the frames in code. Just sayin'
  9. kyussmondo macrumors member


    Apr 7, 2010
    Personally, I prefer doing it in code. With the Autolayout Constraints syntax in iOS 9+, it relatively easy and understandable.

    1. The storyboard/interface builder is excellent for creating quick and straightforward screens for a quick demo, but when the project gets larger with multiple people working on the project, then you run into problems with version control conflicts and constraints get quite messy on more complicated views.

    2. The screen size on laptops is too small for storyboards. On larger projects, even with a 27" iMac, it becomes unwieldy.

    3. Your hands spend more time on the keyboard, and you can jump around a project quickly using Cmd+Shift+O. Searching in a large storyboard is not easy.

    4. As it is all text, refactoring is a lot easier (when Xcode gets proper refactoring for Swift). Also, conflicts are easier to manage.

    5. Cell identifiers and storyboard ID strings are the cause for a lot of crashes and can be difficult to debug.

    6. Refactoring IBOutlet's and IBAction's can cause problems and crashes if the links are broken. The selector in Swift has been improved, so it will not compile if the method is invalid.

    If you are going to take the code approach then I highly recommend using MVC from the very start, otherwise the controller gets massive, or consider an MVVM approach.
  10. AxoNeuron macrumors 65816


    Apr 22, 2012
    The Left Coast
    There are cases where programmatically adding auto layout constraints is unavoidable. But if there is any possibility whatsoever of avoiding programmatic auto layout, such as IB, or child sacrifice, I will do that instead.

Share This Page

9 February 4, 2017