Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Auto layout: Interface builder or code?
- Thread starter grandM
- Start date
- Sort by reaction score
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.
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.
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.
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.
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.
Last edited:
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.
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'
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'
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.
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.
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.