Why do constraints fail to position properly on iPadPro inside a UIScrollView?

I have a view controller which contains a scroll view. In this scrollview (among other subviews) are some UIButtons which do not obey their constrains on iPad Pro 10.5 and 12.9 devices and simulators.


In this screenshot taken in XCode - which shows the subviews of the view in question - you can see the selected button (I have tried this by replacing my custom button with a plain UIView and saw the exact same results) - it has a trailing constraint on it which is set to 43px and a top constraint, 19px.


The trailing constraint works fine on iPad air/9.7Pro/2/etc. - but on the 10.5 and 12.9 iPads the button refuses to obey the trailing constraint, and instead the button's trailing edge is 213px from the trailing edge of its superview. Why?


I've already verified that the superview (UIScrollView) is the full width of its superview - it has an equal width and equal height constraint to its parent view.


Also note - I see the same **** thing in IB when I select iPad Prop 10.5 or 12.9 mode - since when are constraints only valid for iPad 9.7? Is there some hidden iPad Pro safe area I don't see? Also note - there are zero warnings in IB about constraints, and zero runtime constraint conflicts in the console.



PS. The yellow regions are for privacy to hide sensitive data shwoing price info for an unreleased version.

Replies

Have you tried "Vary for Traits" for the 10.5 & 12.9? Double check what might seem to be the trailing to superview constraint isn't being influenced by another control and not the intended superview but now to think of it, if the superview is a uiscrollview the only thing will cause this behaviour is if the scrollview is not edge to edge with its superview or the content size is not the same dimensions of the scroll view & confirm the ui scroll view is constrained edge to edge with its superview ...

I've confirmed the scrollView is edge to edge with its superview.


I think you may be right about the problem being scrollView content size.

I solved the problem by using a "scaffold" - two hidden views, one the full width and one the full length of the scrollview's superview. This forced the content size to the full height and width of the scrollivew and now the buttons align properly.


The same result could have been acheived by using a container view inside the scrollview, pegged to the width and height of the scrollview's parent. And then everythign else in that container subview. I happen to dislike this scheme, so I never use it. But, in this case, if I had used it from the start, I would have not ran into this problem and saved time. At this point, it was easier to add 2 new hidden subviews to prop open the content size, moving all those subviews into a new superview breaks constraints, etc.