[iOS] — Content Compression Resistance Priority
Before going to Content Compression Resistance Priority, it is essential to understand a term called intrinsic content size.
So, what the is intrinsic content size? It is simple. It refers to the amount of space the view needs for its content to appear in an ideal state. That means how big a view should be based on what it displays.
Example: For UILabel, the intrinsic content size is the size of the text that it displays. The same goes for UIButton.
Content Compression Resistance Priority: Sets the priority with which a view resists being made smaller than its intrinsic size. — Apple docs (https://developer.apple.com/documentation/uikit/uiview/1622526-setcontentcompressionresistancep)
The above statement means that the more the content compression resistance priority, the more it will resist to growing smaller (resist to being compressed) than its content intrinsic size. Always remember that priority is a relative term. So, when there is a deadlock between two views, one should have more content compression resistance priority than the other.
Let us understand this with an example. Note that I am using Xcode Version 14.0.1 and iPhone 14 Pro as the simulator for the following example.
I have inserted two labels (Yellow label & Green label) and made them vertically centre on the view controller. For the yellow label, I have given a leading constraint of 32 px from the safe area leading, and for the green label, I have given a trailing constraint of 32 from the safe area trailing.
Pretty Smooth? Let us do the confusing thing (confusing for the Auto Layout 😜). If you check, the current space between the Yellow label and the Green label is 36.67 px (maybe different in your case if you haven’t proceeded with the same configurations as me). Let us create a new constraint that makes the space between these two labels 60 px (i.e., more than the current space)
We will notice Auto Layout throws an error. If we look into the error, we will see that Auto Layout asks us to change the Content Compression Resistance priority of any one label.
Let us first run our application without going deep into the error to see what happens.
The Yellow label gets compressed to satisfy the constraint of 60 px space between both labels. Auto Layout needed clarification about which label(s) to trim to meet the 60 px constraint, hence throwing the initial error. At runtime, it randomly compressed the width of the Yellow label to break the deadlock (it may be the Green label in your case).
So, here Content Compression Resistance Priority comes into play. If we go into the size inspector tabs of both labels, we will see that both labels’ horizontal content compression resistance priority is set to 750 (the default value). This means both labels have similar content compression resistance priority. One label should have a higher priority constraint than the other to break the tie.
Now, let us change the content compression resistance priority of the Yellow label to 751 and see what happens next.
We see that the Auto Layout error has been resolved and the Green label has compressed, and the Yellow label stays to its intrinsic content size because now it has higher content compression resistance priority than the Green label. As mentioned earlier, the one view with higher horizontal content compression resistance priority will not shrink beyond its intrinsic content size.
Now try changing the content compression resistance priority of the Green label to 752 and see what happens next 🤔.
If you found this article helpful, kindly share this story, follow me on medium and give applaud 👏. Thank You!
