On the off chance you haven’t bothered to read carefully the 8.3 point release notes, having been busy fixing up your broken Swift code and all, there’s a subtle time bomb lurking therein for next time you get it building again:
When linking against iOS 8.3, any code that relies on layout information (such as the frame) of a UIButton subview when the button is not in the window hierarchy will need to send layoutIfNeeded to the button before retrieving layout information (such as button.titleLabel.frame) to ensure that the layout values are up to date.
For example, if you had something like this:
1234 UIButton *button = [UIButton buttonWithType:UIButtonTypeSystem];// code that sets up the button, but doesn’t yet add it to a windowCGRect titleFrame = button.titleLabel.frame;// code that relies on the correct value for titleFrame<br />
You now need:
12345 UIButton *button = [UIButton buttonWithType:UIButtonTypeSystem];// code that sets up the button, but doesn’t yet add it to a window[button layoutIfNeeded]; // This is also safe pre-iOS 8.3CGRect titleFrame = button.titleLabel.frame;// code that relies on the correct value for titleFrame
Yikes. Not sure if there’s any currently in development, but we’ve certainly used and/or written ourselves many pieces of code of that form that are now problematic. Probably a sound plan to audit all your button-creating code … just in case.
Looks like layout’s got some pretty serious under the hood revisions: for instance this example
If you construct layout constraints manually … pass in nil for the second view, and that contradicts the the attribute being specified, you’ll now get an exception. Previous OS releases appear to have quietly ignored this transgression on your code’s part.
So yep, better give all your layout stuff a good checking under 8.3. It’s the only way to be sure.
Adaptability Changes in iOS 8.3
“IB started respecting the “relative to margin” option for constraints starting in 8.3” may explain your cells looking different.