"That may be what it says on paper, but I'm 90% sure I've seen IBOutlets be nil by the time the app controller / window controller has its -awakeFromNib called"
I'd be very surprised if that were true — it would be quite a serious bug. What you probably saw was the case that does happen, where one object's awakeFromNib method calls into another object that got loaded from the same nib, whose awakeFromNib hasn't run yet, and so which has instance variables that are still nil.
What makes these awake-ordering dependencies even nastier is that the order in which objects are awoken will change from one launch to the next. The nib code is traversing a dictionary, meaning that the ordering depends on the exact hash values of the objects, and most view/controller objects don't provide custom has codes, which means the hash is simply the object pointer ... which is very likely to be different every time the app launches. I have definitely been bitten by that.
(This, by the way, is a close relative of the C++ problem of ordering dependencies in static object constructors.)
by Jens Alfke — Oct 14
I'd be very surprised if that were true — it would be quite a serious bug. What you probably saw was the case that does happen, where one object's awakeFromNib method calls into another object that got loaded from the same nib, whose awakeFromNib hasn't run yet, and so which has instance variables that are still nil.
What makes these awake-ordering dependencies even nastier is that the order in which objects are awoken will change from one launch to the next. The nib code is traversing a dictionary, meaning that the ordering depends on the exact hash values of the objects, and most view/controller objects don't provide custom has codes, which means the hash is simply the object pointer ... which is very likely to be different every time the app launches. I have definitely been bitten by that.
(This, by the way, is a close relative of the C++ problem of ordering dependencies in static object constructors.)