Confused about why autolayout doesn't seem to grow subviews to match constraints

You declare :

In this layout, noSidewaysView has the following constraints:

• Trailing, Leading, Bottom, and Top to Superview with constant = 0 for all four
• Equal Width to Superview
• Height Equals 500 @ 250
• Height ≥ 500 ( @ 1000 )

Some constraints seem redundant, notably

Equal Width to Superview

Because it has 0 distance to superview in all 4 directions, so width and heigth are equal to its superview.

It is normal that you get 156 always : The priority for the constrains will be applied in order to resolve a conflict between two different constraints. But if both can be staisfied, they will be, so = 156.

You have to play with Content Compression resistance priority (set vertical to 751 I think)

See : h ttps://stackoverflow.com/questions/15850417/cocoa-autolayout-content-hugging-vs-content-compression-resistance-priority/16281229#16281229

Re: the equal width; you'd think that, but no. It doesn't work that way.

With all of those constraints: https://software.quixoticraindrop.com/images/xcodeIB/full.png

With only the width = superview removed: https://software.quixoticraindrop.com/images/xcodeIB/not%20equal.png

I got the original concept from an early autolayout tutorial, if I can dig the link from my history I'll post it (for context).

That did occur to me, that height = 156 would always be satisfiable which was why I made it such a low priority; It seems to me that if the height ≥ 156 with a higher priority, it should take over, but that doesn't seem to be the way it works. Same with the height =/≥ 500 on Text View 2's superview. I removed the text view 2's height =, leaving only the height ≥ constraint, without change (also, without complaint from autolayout; however, trying to remove both that height = and the height = for the noSidewaysView does result in an autolayout complaint, ). Modifying both the vertical hugging (to 249, then to 251) and vertical content compression (to 749, then 751) one at a time, first on the noSidewaysView and then on Text View 2, had no effect. Also, putting the height = 500@250 and height ≥ 500 (@1000) on the Scroll View does not fix the "Need constraints for Y or height" error, it only disappears when its subview, noSidewaysView, has a height constraint.

This was the tutorial I was using for reference on the scrollview in autolayout: https://spin.atomicobject.com/2014/03/05/uiscrollview-autolayout-ios/

Also, it doesn't change anything to move those height constraints to the Scroll view (aside from the still-extant height error that adding those constraints doesn't resolve). That is, by putting the height = and/or ≥ size constraint on the Scroll View instead of noSidewaysView, it has no effect on whether or not Text View 2 grows its bottom to stay pinned to the view.

Re: the equal width; you'd think that, but no. It doesn't work that way.

With all of those constraints: (images are in the "Currently under moderation" comment, which has been in that status for several hours)

With only the width = superview removed: (images are in the "Currently under moderation" comment, which has been in that status for several hours)

I got the original concept from an early autolayout tutorial, if I can dig the link from my history I'll post it (for context).

That did occur to me, that height = 156 would always be satisfiable which was why I made it such a low priority; It seems to me that if the height ≥ 156 with a higher priority, it should take over, but that doesn't seem to be the way it works. Same with the height =/≥ 500 on Text View 2's superview. I removed the text view 2's height =, leaving only the height ≥ constraint, without change (also, without complaint from autolayout; however, trying to remove both that height = and the height = for the noSidewaysView does result in an autolayout complaint, ). Modifying both the vertical hugging (to 249, then to 251) and vertical content compression (to 749, then 751) one at a time, first on the noSidewaysView and then on Text View 2, had no effect. Also, putting the height = 500@250 and height ≥ 500 (@1000) on the Scroll View does not fix the "Need constraints for Y or height" error, it only disappears when its subview, noSidewaysView, has a height constraint.

==== above here, is copy/pasted from a reply I posted earlier which is still "Under moderation"

While I am waiting for somebody to moderate my reply with the links in them, I figured I'd at least see if the text of my reply helps.

Basically, without the Equal Widths constraint, the noSidewaysView will not stretch to fill the visible width of the super. I tried it and it doesn't work. Also, it doesn't work with only Equal Widths, both Trailing/Leading to superview constant = 0 and the equal widths are necessary for the elements inside to fill the space.

So, I've tried setting the hugging & resistance each, both up and down, on the bottom Text View, and I removed the height = 156 constraint (but kept the height >= 156 constraint) on Text View 2. In order to resolve ambiguous height on that scene, I needed to make sure one of either the Scroll View or the noSidewaysView had an explicit height constraint. I tried each of them with a height = 500 individually, with no difference between them.

The bottom of Text View 2 will not stay on the bottom of the view, period. I turned the priority on the top = Text View 1 bottom, then removed it completely, and that didn't help (I would think that if it saw a constriant to keep the bottom to the superview with a higher priority than the top, that it would take precedence, but that doesn't seem to be the case).

So it appears that there are no autolayout options that will allow the bottom of Text View 2 to stay aligned with the bottom of its superview. The only way for this to maybe work appears to be to calculate the size of the bounds of the phone's view area and then set the size of the views at runtime. That, however, seems to be what autolayout is supposed to prevent, is exactly that.

I'd love to post a picture that shows what's going on, but images can't be posted directly and putting URLs in the comments apparently requires a moderation that borders on impossible to get (it's been 98 hours).

You can put URL. just replace https by h ttps