In this episode, we take a close look at another important concept of Auto Layout, intrinsic content size. We first take a moment to discover what intrinsic content size is. Later in the episode, we also touch upon content hugging and content compression resistance, two concepts that drive user interfaces created with Auto Layout.

Intrinsic Content Size

What is intrinsic content size? While it's fine to add explicit constraints to size a view, some views already know what size they should be, and that's a good thing. Let's take a label as an example. You can fix the size of a label and that is sometimes exactly what you want. Most of the times, however, you want the label's size to change depending on the contents of the label, the text that it is displaying. Fortunately, labels already know what their size should be. That's the intrinsic content size of the label.

Intrinsic content size is a dynamic property, calculated at runtime, and that's what makes it such a powerful concept. If the font of a label changes, for example, the intrinsic content size of the label also changes. The same is true for changes of the label's text property or when the user increases the font size systemwide in the accessibility settings of the operating system.

More Implicit Constraints

How does intrinsic content size work? In an earlier episode of this series, we talked about implicit and explicit constraints. Auto Layout translates the intrinsic content size of the view to implicit constraints for each dimension. This is another example of implicit constraints and why it's important that you know about them.

An example works best to illustrate how the intrinsic content size of a view plays its role. I've created a new project in Xcode. Let's add a label to the view controller scene and set the label's text to Auto Layout Fundamentals. Pin the top edge of the label to the top edge of the safe area layout guide and center the label in the superview. Even though we only added two constraints, one constraint per dimension, Interface Builder doesn't show us any errors or warnings. How is that possible?

The Auto Layout engine inspects the label's intrinsic content size and adds implicit constraints for the width and the height of the label. Even though the rule of two constraints per view per dimension seems to be violated, it isn't thanks to the label's intrinsic content size.

Not every view has an intrinsic content size. A vanilla UIView instance, for example, doesn't have an intrinsic content size, which means you need to add four explicit constraints to describe its size and position in the user interface.

Content Hugging

Let's make the user interface more interesting by adding two labels. Remove the current label and add two new labels to the view controller scene. Make sure the trailing edge of the left label is spaced 8 points from the leading edge of the right label. We can immediately see that Auto Layout doesn't like this. Let's take a look at the error message. It says something about content hugging and content compression resistance. What is that about?

The intrinsic content size of a label is equal to the size of the label's text and a subtle margin. In the user interface we're creating, we forced the labels to be wider than their intrinsic content size. The layout engine can only fix the user interface by stretching one of the labels beyond their intrinsic content size. The obvious question is, "Which label should the layout engine stretch?" To answer that question, the layout engine inspects the horizontal content hugging priority of each label. Let me explain how that works.

Every view has a content hugging priority for each dimension. It defines how eager a view is to grow beyond its intrinsic content size. These priorities are taken into account when the layout engine inspects the constraints of the user interface. At runtime, the content hugging priorities are translated into constraints, which makes the job of the layout engine a lot easier.

Select the left label and open the Size Inspector on the right. At the bottom, you can see the Content Hugging Priority section, one for the horizontal dimension and one for the vertical dimension. The default value for labels is 251. Take a look at the user interface if we lower the horizontal content hugging priority to 250.

That looks much better. Because we lowered the content hugging priority of the left label, the left label is now more willing to grow horizontally in size than the right label. To satisfy the layout, the layout engine stretches the left label. The size of the right label is equal to that of its intrinsic content size which is determined by its contents.

Content Compression

Below the content hugging priorities, you can see the label's content compression resistance priorities. These values determine how easy it is to compress the label if it needs to shrink. To see how this works, we need to add more text to the labels than they can fit. The result is a lot of red and a few Auto Layout errors.

The layout engine is having a problem. It needs to shrink one of the labels. One of the labels needs to be less wide than its intrinsic content size. At the moment, both labels have identical content compression resistance priorities and that is causing the error. The layout engine can't make a decision.

Select the left label and set its horizontal content compression resistance to 749. That does the trick. Everything looks fine again. By lowering the horizontal content compression resistance of the left label, the layout engine has decided to decrease the width of the left label to make sure the right label can show its contents.

Intrinsic content size, content hugging, and content compression resistance are important concepts and they're fundamental if your goal is to understand the ins and outs of Auto Layout. Make sure you understand these concepts before moving on to the next episode.