Why does removing these constraints not cause an ambigious layout exception? - ios6

Question

In the XIB file corresponding to the view of a viewcontroller, with Autolayout turned on, I drag out a button and place it at an arbitrary location so that Interface Builder automatically generates vertical and horizontal spacing constraints between the button and its superview (i.e. the VC's view). In the view controller .m file, I create IBOutlets to these two constraints and in the viewDidLoad method, remove them from the VC's view [self.view removeConstraint:self.vConstraint] etc. (And no, I didn't forget to make the outlet connections)
Upon running the app, I expect that Xcode (version 4.5.1, if that matters) would complain about the layout being ambigious but surprisingly (to me), it doesn't.
So how is the button's frame's origin being calculated? The button does appear in its superview at the position it was dropped at in Interface Builder, but I'd like to know precisely what Autolayout is doing in this situation (preferably with a reference to the official documentation).

Answer 1

It seems difficult to find exact documentation or other references on this. A look at Florian Kugler's page on the Advanced Auto Layout Toolbox had some great information. As I thought this was an interesting question I did some digging around.
I set up a test project with a UIButton myButton setup in the Xib and a couple of space constraint outlets:
#property (weak, nonatomic) IBOutlet NSLayoutConstraint *hSpaceConstraint;
#property (weak, nonatomic) IBOutlet NSLayoutConstraint *vSpaceConstraint;
As you stated, removing these constraints in viewDidLoad had no effect. Even outputting [self.myButton hasAmbiguousLayout] immediately after removing the constraints in viewDidLoad shows false.
However, by viewDidAppear, things have changed. myButton is correctly flagged as ambiguous by both hasAmbiguousLayout and also by doing an Auto Layout trace in lldb:
(lldb) po [[UIWindow keyWindow] _autolayoutTrace]
*<UIWindow:0x8a94fe0> - AMBIGUOUS LAYOUT
| *<UIView:0x8c55340>
| | *<UIRoundedRectButton:0x8c54100> - AMBIGUOUS LAYOUT
| | | <UIImageView:0x8c54580>
| | | <UIButtonLabel:0x8c595a0>
(lldb)
At this stage, we can also exercise the ambiguity:
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
[self.myButton exerciseAmbiguityInLayout];
}
Without exercising:
Exercising:
There's nothing on the console either. That surprised me as I'm used to Auto Layout splurging a ton of constraint exceptions at the first sign of trouble.
Investigating that, a quick search here on SO revealed that
"ambiguity can be temporarily tolerated (unlike unsatisfiability,
which immediately raises an exception)"
So that explains the clear console, at least for now.
To conclude then, I believe that by the time viewDidLoad executes, a measure, layout, and display pass has already occurred. Removing the constraints then renders the view ambiguous. Auto Layout then does the common sense thing on a view that it no longer knows how to layout; nothing. The view remains in situ.