Why I stopped using XCode’s Interface Builder
Before getting to the point, let me just make a small side-note: I do think Interface Builder is a very powerful and helpful development tool. It allows for developers to quickly and easily start to develop beautiful UI and User Experience without even starting to code anything. Also, it allowed for Designers and Other non-developers to be involved and able to do some of the UI work without much technical knowledge.
Do you have strong reasons for what you’re saying?
I would like to start by explaining the main causes that throughout the years developing for iOS led me to this conclusion.
In the beginning (and I’m talking almost Jurassic iOS mobile development back when I first started developing for iPhones), we were working with 2 OS versions at the same time, migrating from iOS 4.2 to 5.1, the second generation of iPads and the iPhone 4S flagship models were being released. At this point de Drag and Drop kind of UI development available on XCode’s Interface Builder was easy and fast, and very reliable because all the hardware models until then used the same screen ratio and resolution. But hence the iPhone 4S had retina capabilities, but none the less this was just a matter of introducing a new resource/asset size… the “@2x”.
Time passes and more iPhone models and iOS versions are released. Suddenly the iPhone 5 brings a strange new large screen and the screen ratios and resolutions start to suffer from fragmentation (this kind of phenom was present in Android since the beginning of the OS) and unlike Google’s approach to solving the problem with relative layouts and auto-adjusting view sizes, Apple’s absolute View positioning and sizing was outdated and it simply didn’t work anymore.
So the new models and screens started to create a problem that most likely will continue to escalate as more and more models and screen sizes/ratios come out. (Don’t forget, nowadays we have “@3x” assets/resources size and sometimes also the need to introduce some iPhone-6 screen size hacks to make sure the layouts behave correctly on all phone sizes and OS versions)
The release of iOS 6 came with a new way of positioning views that would allow the developers to create apps for all screen sizes without having to create the views by hand, sizing them in code with somewhat complicated formulas to calculate sizes and placement. Apple Introduces AutoLayout, a constraint based layout engine and adapts the Interface Builder’s system to support the new layout system as well as the old absolute positioning model.
This is when things started to become shady to say the least. The way Interface Builder implements the AutoLayout system, is by creating relations between views and assign constraint values that control position, size, placement. All this is done through “ctrl+click and drag” witch is very error prone, because sometimes the action area for the drag and drop is very small and tight, and is very likely to miss the target and create a relation with some other view, causing the layout to break and the app to crash. Also there’s another small detail, sometimes with just one click and drag, you will be applying more than one constraint to the views. I just couldn’t stop wondering about all this is black magic being made behind the scenes.
Another of my main problems while developing for iOS using xib files or Storyboards is version control. The problem here is not that these files can’t be under source control, rather than that, I’m complaining about Xcode as a development tool itself. XCode and Interface Builder are very metadata driven, which means they generate and depend a lot on the metadata created for the project. Each time you touch (even if it is just to see something, read-only purposes) automatically XCode will generate some new metadata and change the file. If you work alone developing the app from top to bottom, this won’t be a problem to you, but if you are a part of a team, this will eventually cause a lot of headaches and a lot of time wasted merging your project’s branches.
So You are saying I should do it all in code?
Well the answer to that is YES and NO… But let me explain:
You can do all the AutoLayout constraining in code, but if you enjoy your sanity I really don’t recommend doing so. I do recommend you to get some insight and learn something about NSAutoLayout Constraints and how they work. Maybe do some little experiments with some simple layout needs and get to know them, how and when to use them.
Looking at the example image above, we can see that this layout is fairly simple and shouldn’t be very hard to create using code. We only want to get to know how things are done and compare the results.
View placement:
Bottom Green View has:
- width of 90% of the screen width -> widthConstraint3
- fixed height of 100pt -> heightConstraint3
- view center matching the horizontal center of the screen -> horizontalConstraint3
- top matching the vertical center of the screen with 10pt offset -> verticalConstraint3
Top Right Red View has:
- width of 40% of the screen width -> widthConstraint
- fixed height of 100pt -> heightConstraint
- right margin matching bottom green view right margin -> horizontalConstraint
- bottom matching the vertical center of the screen with 10pt offset -> verticalConstraint
Top Left Blue View has:
- width of 40% of the screen width -> widthConstraint2
- fixed height of 100pt -> heightConstraint2
- left margin matching bottom green view left margin -> horizontalConstraint2
- bottom matching the vertical center of the screen with 10pt offset -> verticalConstraint2
NSAutoLayout Constraints
As I was saying, it shouldn’t be difficult to get the layout to work, but it sure is painful to look at the code, as well as writing it… (It’s not my brightest code example, but this is only a sample and I tried to keep it as simple as possible)
But wait, I’m not saying you should have all this work, because there are people who already went through the same pain you are experiencing and developed some great tools and libraries to help making it all easier on you. I’ll just refer and give examples of two of them because I have tried and at some point used them myself. Bear in mind that there are probably many more, you’ll have to do some research and decide which one suits you better, regarding your coding style and layout needs. Here’s a small list of some AutoLayout Domain Specific Language (DSL) libraries that Chris Dzombak compiled to help you get started.
I personally have used PureLayout and SnapKit and both do the same just fine! Let’s take the above example and see what we need to do to accomplish the same result.
PureLayout
The PureLayout version doesn’t bring down the number of necessary lines of code very much, but it becomes a little more clear to read and the code seems a little less messy. Now we can see some methods being called that actually express something we can relate to how the view is going to behave in terms of sizing and placement. But we do have a downside with this approach, we have our code separated in two methods. The first will instantiate the views and the latter will do the placing and sizing. As a downside, we did need to add an extra view to help us with positioning the views, but it is only a container to help achieve view relative positioning. Also we can’t forget to bootstrap the layout engine otherwise nothing will happen.
SnapKit
The SnapKit version of the code is probably my favourite. To setup the constraints we access some of the views properties and assign them values either by relation to other views, or absolute values. In any case, the code syntax is very self explanatory and very easy to read. Unlike the PureLayout, we can have code instantiating the views and positioning/sizing them all in the same place, but we will need to bootstrap the layout engine just the same. One of the advantages over PureLayout it is that we won’t need to remember that we have to put the layout code exactly in the “updateViewConstraints” method or in the “layoutSubviews” (in case you are subclassing views with custom behaviour and UI) for things to work.
Summing it up
As you can see from the examples above, you still do all your layout setup through code, but the number of lines written is probably smaller than with the usage of NSAutoLayout Constraints and the readability is much greater using the DSL for Autolayout approach.
As a sidenote, you can also use something called Visual Format Language to layout your views, witch works fine for some of the UI positioning needs, but you can’t have relative sizing and positioning relations between views which makes it less versatile. You will most certainly have to use it along with NSAutoLayout Constraints. Also it has a special format grammar that you will have to master in order to achieve the same results as using just layout constraints.
Creating your UI experience through code is not the easiest job, but with enough practice and experience, you’ll probably be ending up writing your layouts in code faster than clicking and dragging stuff on Interface Builder, and then adjusting the constraints by hand. You’ll have more control over what happens on the device’s screen, manually controlling how views place themselves and adjust to different screen sizes.
You can checkout the full code over at my example repo https://github.com/pmlbrito/AutoLayoutTests and test the example project.
Feel free to comment any doubts and questions you may have.
