Auto layout broken in iOS 9.3/Xcode 7.3

iOS 9.3 or Xcode 7.3 seems to break auto layout.


I have 2 container views embedded in a view controller's root view, using auto layout with constraints set up in interface builder. When debugging, I noticed the root view's translatesAutoresizingMaskIntoConstraints is set to true, which causes constraint conflicts later. With interface builder, it should be set false by the system. If I set it to false in viewDidLoad() of the view controller, the system does not layout the views. The container view that should appear has frame (0, 0; 0, 0). No problem in iOS 9.2.1.


Another case: interface builder does not update frames properly when laying out a stack view with only 2 labels inside.

Replies

I do have similar issue. My is pertaining to auto-resizing table view cell.


It seems to always happen when You use UIStackView as the root of the UITableViewCell to do layout. The compiler start complaining,


Unable to simultaneously satisfy constraints.

Probably at least one of the constraints in the following list is one you don't want.

Try this:

(1) look at each constraint and try to figure out which you don't expect;

(2) find the code that added the unwanted constraint or constraints and fix it.

(

"<NSLayoutConstraint:0x7ff5ec4c80f0 V:[UITableViewCellContentView:0x7ff5ec4c77b0(100)]>",

"<NSLayoutConstraint:0x7ff5ec4ca170 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7ff5ec4c77b0(100)]>"

)

Will attempt to recover by breaking constraint

<NSLayoutConstraint:0x7ff5ec4c80f0 V:[UITableViewCellContentView:0x7ff5ec4c77b0(100)]>

I'm having a similar issue regarding stackViews. Within Xcode 7.2, a layout which contained nested stackViews with labels did not throw any layout errors in IB. When opening this same storyboard in 7.3, there are many errors related to missing heights and Y Positions.


Like you stated above, Xcode 7.3 does not update frame positions either.

I have exactly the same issue. I have two stack views nested. No problem in xcode 7.2.1, but when opened in 7.3 I got many weird layout issues I could not fix. Furthermore the nested stack views suddenly were increased way beyond their intrinsic size so they were off screen.


I downgraded to 7.2.1, cannot work with 7.3.

I am seeing the same issue with 7.3. The layouts are fine when I run, so I am ignoring the frame warnings, but would prefer to have this corrected. It makes it much harder to create new layouts.

I filed a bug (25111475) back in early March. It was like this in the 7.3 betas and never got cleared up, unfortunately. Pretty annoying since UIStackView has become a staple of UI development now.

Bump. Verified that the behavior still exists in 7.3.1 production. Updated bug report to reflect.

This seems to be fixed in Xcode 8 beta 1. 🙂


Ticket resolved. Thanks Apple!


-Chris

Similar problems for me. I've given up with stack views and labels in Xcode 7. My guess is it's something to do with intrinsic size of labels. Version 8 seems much better (so far).

Broken again in Xcode 8 beta 3.

Threads like this make me think that not using autolayout is the right choice.

AutoLayout seems pretty good for the most part - it's specifically StackViews that seem to consume vast amounts of time + frustration right now.

I always end up ditching it and resorting to older methods. It feels like we always need to working about 1 year behind.


Stepping back and thinking about the whole idea - visually setting just the right constratins to satisfy a set of equations, without overdetermining or underdetermining the system, in my view it's always going to cause 'issues' as things scale. What is supposed to make life easier can become horribly complex.

The number of times I've had to rip out all the contraints and start again is shocking (maybe it's just me).


I admire the ambition of Apple in what they are trying to do however and I'm sticking with it (at least the parts that are reliable) - I don't want to go back to writing it all in code.

>The number of times I've had to rip out all the contraints and start again is shocking (maybe it's just me).

Yeah that is the nightmare I want to avoid. I don't find writing layout code to be particularly hard, usually. Constraints feels a bit too magical to me. And testing constraints...on 3.5 inch iPhones, iPhone 5, iPhone 6, iPad increases development time and debugging time. By using Autolayout, I feel I'd be introducing a whole new category of potential bugs in my apps.


I also admire the ambition of it, but I don't think we need all that. It's too much. It could be just me too, but I feel like it causes more problems than it solves.


What I think we need is a faster simulator where we could test layout code quickly on different screens (and constraints if you are using autolayout) would help alot.

I here what you say. For simple-moderate layout, AutoLayout is good. Using different layouts / constraints for different Size Classes really helps (rather than trying to make one layout for everything). The compact / regular combinations are initially confusing however - I'm simply not convinced that abstraction has a future (everyone I know simply converts them back to device sizes).


Xcode 8 makes it quicker to switch between and preview different size classes (without the simulator)l, and now some of your layout can be managed with good old springs and struts again (yep, they're back in Xcode 8).

I suspect AutoLayout is going to be hard to avoid, especially if you start getting into adaptive UI.


I was looking at where I can break things down (to simplify layout complexity) by using ViewController containment - that was not a successful execise sadly - what I gained in one sense was lost in another. I may revisit.


If/when StackViews are reliable and simple to use (I thought it was just me), I suggest it would make a huge difference - in theory they cover simple grid, vertical and horizontal layouts without any messing about - which fits is so many designs - I really hope Xcode 8 sorts it out.

Xcode Version 8.2 beta (8C30a) not able to place a Lable on the Stack View.