Content hugging and compression resistance priorities iOS 25.11.2019

You might know that every view has an intrinsic content size. You also learned that if you do not specify constraints that explicitly determine the width or height, the view will derive its width or height from its intrinsic content size. How does this work?

It does this using implicit constraints derived from its content hugging priorities and its content compression resistance priorities. A view has one of each of these priorities for each axis:

• horizontal content hugging priority
• vertical content hugging priority
• horizontal content compression resistance priority
• vertical content compression resistance priority

Content hugging priorities

The content hugging priority is like a rubber band that is placed around a view. The rubber band makes the view not want to be bigger than its intrinsic content size in that dimension. Each priority is associated with a value from 0 to 1000. A value of 1000 means that a view cannot get bigger than its intrinsic content size on that dimension.

Let’s look at an example with just the horizontal dimension. Say you have two labels next to one another with constraints both between the two views and between each view and its superview.

This works great until the superview becomes wider. At that point, which label should become wider? The first label, the second label, or both? As following figure shows, the interface is currently ambiguous.

This is where the content hugging priority becomes relevant. The view with the higher content hugging priority is the one that does not stretch. You can think about the priority value as the "strength" of the rubber band. The higher the priority value, the stronger the rubber band and the more it wants to hug to its intrinsic content size.

Content compression resistance priorities

The content compression resistance priorities determine how much a view resists getting smaller than its intrinsic content size. Consider the same two labels. What would happen if the superview’s width decreased? One of the labels would need to truncate its text. But which one?

The view with the greater content compression resistance priority is the one that will resist compression and, therefore, not truncate its text.

Labels, by default, have a greater content hugging priority than text fields, the label hugs to its intrinsic content width and the text field stretches. The label and the text field have the same content compression resistance priorities, which would result in an ambiguous layout if the text field’s text was too long. Open the size inspector for the text field and set its Horizontal Content Compression Resistance Priority to 749. This will ensure that the text field’s text will be truncated if necessary, rather than the label.

Useful links

• What is constraint priority and how to use it
• Content Hugging vs Content compression resistance