Interface builder is an extremely powerful tool in Xcode. It allows you to develop user interfaces in record time that work on all different screen sizes.
However, it can be difficult for a beginner to learn all the nuances of it, especially if you’re trying to learn to code at the same time. I’ve been through it and have been using the Xcode interface builder for years professionally.
How to use Xcode’s Interface Builder?
In this article, I’ll go over the key concepts to understand in order for you to master the interface builder. I’ll also include some extras for advanced users.
Setting constraints is probably the most important part of using the interface builder. Constraints are the backbone of Apple’s auto layout engine and understanding them can save you a ton of time. They’re extremely powerful and can allow you to build quite complex layouts.
Constraints are rules that define how auto-layout will build your user interface. They typically describe a relationship between two views or elements. They can also provide information on the size, aspect ratio and position of a view. Constraints are the essential building blocks of auto-layout views.
I like to think there are two different kinds of main types of constraints:
Size constraints are simple to understand. You can set the height or width of any view. This includes buttons, tables, images, labels or any other element.
To set a size constraint on a view, select it in the interface builder, then go to the bottom right-hand corner and click the button that says “Add new Constraints”. The icon looks like this:
Add new constraints dialog will popup, allowing you to set the width and height constraints. Simply enter in the value you’d like for either width or height or both and then check the boxes beside it. Example:
Adding width and height constraints Select Add 2 (or 1) constraints when you are finished. Size constraints are the simplest one to implement and understand. They only deal with one element (the currently selected element).
Positional constraints deal with two or more elements and their relationship to each other. This is great when you want to set the spacing between two UI elements or center an element within another one. There are a couple of different ways to achieve this:
Opening the Add New Constraints window will allow you to create constraints with set spacing between an elements nearest neighbor. You can set constraints for the left, top, right and bottom.
To turn on any of these constraints, enter the value desired and then click the faded red margin. It will turn deeper red, letting you know the constraint has been activated.
The downside of using this method is that you don’t get to select the neighbor. Xcode will automatically select the nearest neighboring element for you. This works fine in many cases, but often you’ll want to be explicit and choose the two elements you’re creating a constraint with.
Add new alignment constraint works very similarly to the add new constraint window.
Here you can set different alignment values for the currently selected view.
This is my favorite method and the one I use the most often. Ctrl-drag allows you to set a constraint from one element to another element. To do this, hold ctrl on your keyboard, click the first element, then drag your cursor to the second element. A dialog will popup allowing you to select a constraint you’d like between these two elements.
In the above example, I ctrl-clicked on the image view, then dragged it to the background image. The dialog will pop up like so:
This popup dialog displays constraints you can add. Any constraint with a dot next to it means that it already exists. Let’s go over the ones I use the most often and that I believe are the most important:
The same pop-up dialog will appear and you can do the same thing.
I often use the document outline as its more clear what element I am ctrl-dragging to.
Setting constraints is so difficult! Isn’t there an easier way? Can I just drag my elements onto the screen and let Xcode handle the rest?
Xcode can’t generate all constraints, but it can add missing constraints. If you’ve added a couple of constraints and want Xcode to figure out the rest, you can select the Resolve AutoLayout icon in the bottom right-hand corner.
You have a couple of options, you can Add Missing Constraints, Reset to Suggested Constraints or even just clear all the constraints.
I don’t recommend letting Xcode automatically add constraints typically. Xcode may add constraints you don’t want and it could make it harder to debug later. I recommend understanding how constraints work and adding them yourself.
To edit constraints, simply go into the Size Inspector. You can open this panel by going to View > Inspectors > Show Size Inspector or by using the keyboard shortcut Cmd + Option + 5.
Underneath the Size Inspector, there is a constraints section. Here you can click edit on any of the constraints and change its value.
If you accidentally added a constraint, you can easily delete it. Select the element that has a constraint on it in the document outline. Once you have it, you can open up the size inspector (CMD + Option + 5) and double click on the constraint. The constraint will then be highlighted into the document outline and you’ll be able to delete it by pressing delete on your keyboard.
If you accidentally delete a constraint you can use CMD+Z to undo the change.
Constraint priority tells your application which constraints are more important. If your user interface gets into a position where it can only satisfy one of two constraints, the constraint with higher priority will be enforced and the other constraint will not be applied.
In this sense, constraints are not strict rules, but rules that may be broken to satisfy more other important rules. Understanding this concept is essential to building more complex layouts.
To set constraint priority open up the (CMD + Option + 5) and click edit on the constraint you like to change.
If you click the drop-down menu, Xcode will offer 3 presets. Required (1000), High (750) and Low (250). I recommend you stick to these 3 options. Having too many different priority levels can quickly make your user interface difficult to debug.
Constraint errors can lead to broken user interfaces. This happens when your app cannot satisfy the constraints you’ve set out for it. This could be because of multiple reasons:
Missing constraints occur when the auto-layout engine does not have enough information to build the user interface. You can fix this by adding more constraints. Typically this error shows up in your interface builder in the form of red lines.
If you click the red arrow in the document outline, you’ll see the description of the error.
This should lead to a Missing Constraints error page like so:
Aha! Looks like we need constraints for the width and height of our image card view. Let’s add those in. Once we’ve added those in, you can see the page has been updated.
Now we need to add constraints for its X and Y positions. Let’s do that now.
You can now see there are no more redlines in the interface builder and the red arrow in the document outline is gone.
This is when two constraints contradict each other and the interface builder can’t figure it out. For example, lets say you want something to be height of 100, but you also want it have the height of 300. It can’t be both! This will result in an error (redlines) in your interface builder.
Clicking on the red error will show you the problem.
We can solve this by simply deleting one of the constraints. Click on one of the constraints in the conflicting constraints section, then hit the back button and hit delete on your keyboard. This should get rid of the constraint and fix your conflict!
Misplaced views result in a warning in your interface builder. This is characterized by yellow lines and a yellow warning error on your document outline.
To fix this warning, you can either drag the view back into its proper position or click the Update Frames button in the bottom right corner. I always use the Update Frames button because it saves me a lot of time and its just easier.
Once you click that button, your views will be moved into the correct position and the warning should disappear :).
That’s all for the basics of constraints. These concepts should get you pretty far. I use these tips everyday in the industry.
The next thing you should be familiar with is the Inspector Pane. The inspector pane can be opened up using the keyboard shortcut cmd + option + 0. This opens up the inspector pane on the right hand side of your workspace. Here we have multiple tabs:
The file inspector is not often used in my experience. Target membership is important and having the 3 default checkboxes checked is important.
Target membership is required to be specified in order for your project to build properly. Usually the default value is sufficient.
Use Auto Layout should almost always be checked. Auto Layout is an extremely powerful that allows developers to build user interfaces rapidly.
Use Trait Variants should usually be checked as it allows you define different constraints for different sized screens.
Use Safe Area Layout Guides should usually be checked, it ensures your user interface plays well with newer iPhones that don’t have a home button and have a notch in the top of their screen.
In my experience, you won’t be visiting this tab very often.
The Quick Help Inspector tab provides a summary of the element you currently have selected. When you are just starting out and learning iOS development this could be useful reading. As you become more experienced, you will likely not use this tab a lot.
I don’t frequent this tab very often anymore, as I am familiar with most of the elements. I suspect the case will be similar for most developers over time.
The identity inspector has a lot of different sections. The most used section is the custom class section. Here we can define this element as our own custom built element that we’ve created in code.
The user-defined runtime attributes section is also useful for defining properties of the elements that are not available in the interface builder by default. We can adjust border width, border color and many other attributes not in the interface builder by default. I typically like to add these modifications in code instead of the interface builder.
The user interaction enabled checkbox is important if you want touches and drags to be handled. If this is unchecked, users will not be able to click or otherwise interact with this element.
There are some other options on this tab, but these are the most important ones you might find yourself using often.
The attributes inspector is a frequently used tab. This tab will change based on what element you have selected. If you have an image view selected, it will have properties like how you want it to scale and the name of the image you want it to display.
For elements like labels or text views, it will display options such as font size, color and text wrapping. For a collection view, it could have properties such as spacing between elements.
You’ll be using this tab often to set up the basics of most user interface elements. I use this tab very often professionally. Over time you’ll become comfortable with all the different properties for each UI (user interface) element.
The size inspector is also another important tab you’ll need to understand in order to build great user interfaces.
The most important section of this tab is the constraints section. The constraints are the rules that auto-layout uses to build your UI. Here you can edit them and delete them to your needs.
Two other important sections are content hugging priority and content compression resistance priority. Depending on the values set here, the boundaries of your elements will either hug tightly what they contain or resist compression (shrinking). If you want your views to hug more tightly, increase their hugging priority and if you want your views to stay expanded, increase their compression resistance priority.
The connections inspector is the last tab in the inspector pane, its used to connect your elements into your code.
Here we can see the different referencing outlets that are attached to our Swift code. For certain elements, such as buttons, there are interface builder actions that can also be linked to our code.
The next section will discuss the details of interface builder outlets (IBOutlets) and interface builder actions (IBActions).
IBOutlets are a property that references another object. The reference is archived in the interface builder and is reestablished when the nib is loaded. This allows you to work with your views and subviews inside your Swift code.
All user interface elements can be added as IBOutlet properties to your Swift code by dragging the outlet from the interface builder into your code:
IBActions are similar to IBOutlets, except they are methods that are established when the nib is loaded and are linked to a very specific action.
Inside these actions you can write code that will executed when this action event is sent. For example, the most common one I use is to run code when a button is pressed.
IBActions & IBOutlets are essential to connecting your interface builder work to your code.
One of the biggest benefits of using auto-layout is its ability to build user interfaces for different devices and orientations. The interface builder has some tools built-in to make this process easier.
At the bottom of the interface builder you can see a button that says View As:
This will open up options for previewing your user interface with different screen sizes and orientations to choose from:
By clicking different devices and orientation you can preview your design live in Xcode. This helps you edit your user interface without having to load it into a real device or a simulator.
This an essential part of developing user interfaces in Xcode. It’s important to make sure your app works properly on different devices.
Should I use the interface builder or only code? I recommend using both the interface builder and code to for your app. Most screens can be built incredibly quickly using the interface builder. It’s an extremely powerful tool you should learn as it will save you time. For transitions between screens or adding specific subviews, I recommend using code in order to keep each screen more modular.
Should I use storyboards? I don’t recommend you use storyboards.