Content hugging priority and compression resistance in iOS

Developing user interfaces in Xcode is always interesting, regardless of how long you’ve been playing with it. During UI implementation, we make use of different components, views, and controls such as UILabels, UIViews, and UISwitches, and they have similarities and differences against each other depending on their intended purpose.

While some views such as UIView and UIScrollView without subviews do not necessarily have a size preference for themselves since there is no content for those views to wrap, some views automatically specify a size based on their contents. A UILabel when text assigned to it, for instance, has a width and a height which is calculated based on its attributes; the font, font size, etc.

Here, the left label has its top and leading constraints defined to its super view and the right label has its top and trailing constraints defined to the same super view. Even though each view should define its origin X and Y as well as width and height constraints, here, the auto layout doesn’t indicate any error despite the width and height constraints are not defined. That’s because the label’s intrinsic size defines its height and width based on the text and given font, fulfilling the constraint needs of the label.

Intrinsic content size

Intrinsic content size is the amount of space the view needs for its content to appear in an ideal state.

This article explains how intrinsic content size is applied from interface builder. But incase if the intrinsic content size is calculated by the code, where the interface builder might not be aware of, a placeholder intrinsic size can be applied from the interface builder itself which is only valid during the design time.

However, in this example, if the text of the label exceeds the expected limit, those labels will overlap and in order to prevent overlapping, a horizontal spacing constraint can be added to the label as below.

Now, the auto layout shows an error, it is still not aware of what to do because the constraints that are automatically created for heights and widths of both labels based on the intrinsic content size have the same priority for content compression resistance.

Same content compression resistance priorities in both labels.

With intrinsic content size, the following two constraints are automatically created, and their priorities can be changed as required.

1. Content compression resistance
2. Content hugging

Content compression resistance

The content compression resistance priority stands for how much the view doesn’t want to shrink smaller than the size of its content.

This means a high content compression resistance priority doesn’t shrink than its content size, whereas, a low priority tends to shrink than the size of its content.

In the below image, UILabel on the right has a higher horizontal content compression resistance priority than the UILabel on left, therefore the right label doesn't want to shrink and it takes the advantage of the left label which has a lower horizontal compression resistance priority, consequently, shrinking left label than its content size.

Content hugging

Content hugging priority stands for how much the view doesn’t want to grow larger than the size of its content.

This means a high content hugging priority makes sure that the view sticks to its content size and do not grow larger than its content, whereas, a low content hugging priority is likely to expand the view than it’s content size.

In the below image, the UILabel on the left has a relatively higher horizontal content hugging priority than the UILabel on right, therefore the left label doesn’t want to expand than its content size, consequently, allowing the label on the right to expand and adjust its width regardless of the content size.

Since both content hugging and content compression resistance constraints are applicable on both horizontal and vertical layouts, the auto layout looks for the fulfillment of those constraints and shows constraint errors if there are any conflicts.

Furthermore, despite the fact that views like UILabel have an intrinsic content size for both directions (height and width), some views have intrinsic content size only for a single direction. UIProgressView, for example, has only an intrinsic content height but not width and for such views, automatic constraints get created for one direction.

Since this is a brief explanation, refer following source(s) for further information.

Auto Layout