So, I’m not sure if this helps you with your problem since it sounds like you’re building your layout in IB, but here’s an issue that I just ran into that may help others that google search for “_UITemporaryLayoutWidth”.
My scenario was that I was adding auto layout constraints during init and was accidentally triggering a ‘layoutIfNeeded’ before adding the view to the view hierarchy (modifying a buttons edge insets triggers layout). It looks like the system adds these temporary constraints and (I assume?) removes them after the view is added to the hierarchy. The temp constraints set 0 dimensions (in my case) which can fail if you, for example, set specific constraint constant values in your layout (e.g., you want 16px between these buttons but there’s 0 space in that dimension…)
Update: Investigated a little more and found that the temporary constraint seems to correspond to the frame that you use to initialize the parent view. In my case, the frame I used was size 0x0, so the temp constraint evaluated relative to 0x0 size, thus failing. Verified that if I init with a 5×5 frame then I see the same error with _UITemporaryLayoutWidth(5) constraint. The other thing that I’ve noticed is that the constraint seems to be added and removed during the layout evaluation – if I break right before I trigger the layout and analyze the constraints then I don’t see the temp constraints. I also don’t see the constraints after the error, so I suspect they synthesize the temp constraints, add them, solve then remove them.
Update 2: Ok, maybe this is TMI but this might be of some use to someone. My current thought is that these temp constraints are a peek into how the system handles mixed frame manip and autolayout within a single view hierarchy. In my case, my view had no parent and had no constraints defining its size, but it did have a zero frame which meant the system assumed that’s the size it should use when solving the layout. My thought is that the system synthesizes these temp constraints for views that have their frames set explicitly to solve the rest of the system as it’s traversing the hierarchy.
Update 3: So, I ran into this problem again and wanted to share a little more info. My scenario was that I was trying to essentially measure views that had no parent using the systemLayoutSizeFittingSize: method. Long story short, I had to call layoutIfNeeded on the view before measuring it – this is where I run into the conflict with the temp constraints since the view doesn’t have a superview. The temp constraint constants (the dimensions) do correspond to whatever frame is set on the view without a superview – I think this makes sense (though, setting a frame on a view that you’re going to be using with AutoLayout seems odd…) I was able to get around the temp constraint issue by saying – if the view doesn’t have a superview then add it to a temporary superview; measure; remove it from the temporary superview. Hope this is useful.