Small Tip for Debugging Autolayout issues
This is quite a small post and probably not worth writing it but I know that this will come in handy in the future and will totally forget about it.
The other day I was trying to figure out an Autolayout crash on the app I was working on and trying to make head of tails from the console log with stuff like this:
<NSAutoresizingMaskLayoutConstraint:0x175086220 h=-&- v=-&- UIView:0x147533250.height == UIView:0x14760b4a0.height>
Imagine that but with many interacting
UIViews at play; most of the time you can actually figure what’s going on based on the
constant value or if you are well versed you can see the
Matrix from source code a la Neo; but let’s be honest; more times than none you are left wondering which view is which…
accessibilityLabel to the rescue
Looking around how to set debug names for views/constraints I found out that setting the
UIViews will appear in the console log next to the horrible mess that I showed above in this post making things more «human readable».
accessibilityIdentifier we can help us figure out those pesky autolayout crashes.
Storyboards in our projects; like I’ve said before:
…yes, we use storyboards, we are drinking Apple’s “Kool-Aid”…
Which makes it really easy to set that
accessibilityIdentifier directly from
InterfaceBuilder; sadly this time the issue was happening while generating some
UI via code.
This doesn’t make this any less useful; those traits can be set via code as well 🎉
That way at least you can infer something like this:
loginTextView tail constraint of 10 with logoImageView leading logoImageView top constraint of 15 to topLayout
That’s obviously pseudocode but you get the idea; knowing which views are actually interacting with the crash helps figure out why and how to fix them.