Blah, I went to eat lunch and the forum ate my post. I’ll try and explain it again.
When a XIB file is loaded, all of the archived objects are allocated and instantiated, using alloc/initWithCoder:. Then, all of these objects are sent the message autorelease.
After that, connections are made using setValue:forKey:, a method that every NSObject subclass has. So if an object named foo has an outlet named bar that has been connected to widget, the following code is executed:
[foo setValue:widget forKey:@"bar"];
setValue:forKey: first looks for a setBar: method. If it finds one, it invokes that, passing widget as the argument. If no such method is found, it automatically retains widget and assigns the ivar bar to point at widget. (If there is no ivar bar, an Unknown Key exception is raised. Read up on Key-Value Coding in the documentation for a more detailed explanation.)
Therefore, any object we have an outlet connection to is retained by the view controller. Furthermore, any view object that has a superview is retained by its superview. This means that nameField and friends are owned by two objects: the view controller and the view controller’s view. When a low memory warning occurs, the view is destroyed and all of its subviews are released. Any subview that was not also owned by the view controller is consequently destroyed, but, the ones we have connections to will still exist. These lingering views will never appear on the screen again, because when we reload our view from the XIB file, we will get brand new instances of nameField and friends.
Because a low memory warning means we are running out of memory, and we are never going to use these views again, we release the view controller’s ownership of them in viewDidUnload right away so that they are properly deallocated and we save some memory. We nil the pointers to them out because we NEVER want a pointer to a deallocated object for fear of sending it a message later and crashing.