didReceiveMemoryWarning

• didReceiveMemoryWarning practices

As you said, the controller's default implementation of didReceiveMemoryWarning releases its view if it is 'safe to do so'. While it's not clear from Apple's documents what 'safe to do so' means, it is generally recognized as it has no superview (thus there is no way that the view is currently visible), and itsloadView method can rebuild the entire view without problems.

The best practice when you override didReceiveMemoryWarning is, not to try releasing any view objects at all. Just release your custom data, if it is no longer necessary. Regarding views, just let the superclass's implementation deal with them.

Sometimes, however, the necessity of the data may depend on the state of your view. In most cases, those custom data is set in viewDidLoad method. In these cases, 'safe to release custom data' means that you know that loadView and viewDidLoad will be invoked before the view controller uses the custom data again.

Therefore, in your didReceiveMemoryWarning, call the superclass implementation first, and if its view is unloaded, then release the custom data because you know that loadView and viewDidLoad will be invoked again for sure. For example,

-(void)didReceiveMemoryWarning {
    /* This is the view controller's method */
    [super didReceiveMemoryWarning];
    if(![self isViewLoaded]){
        /* release your custom data which will be rebuilt in loadView or viewDidLoad */
    }
}

Be careful not to use self.view == nil, because self.view assumes that the view is needed for someone and will immediately load the view again.

• viewDidUnload method

viewDidUnload is called when the view controller unloaded the view due to a memory warning. For example, if you remove the view from the superview and set the view property of the controller tonil, viewDidUnload method will not be invoked. A subtle point is that even if the view of a view controller is already released and set to nil by the time the controller receivesdidReceiveMemoryWarning, so actually there is no view to unload for the controller,viewDidUnload will be invoked if you call the superclass's implementation ofdidReceiveMemoryWarning.

That's why it's not a good practice to manually set the view property of a view controller to nil. If you do, you may better send a viewDidUnload message as well. I guess your understanding ofviewDidUnload is more desirable, but apparently it's not the current behavior.

• Popping view controllers

If you mean 'removing from the superview' by 'popping', it does decrease the retain count of the view, but not necessarily deallocate it.

If you mean popping out from a UINavigationController, it actually decrease the retain count of the view controller itself. If the view controller is not retained by another object, it will be deallocated, desirably with its view. As I explained, viewDidUnload will not be invoked this time.

• Others...

Technically, the retain count may not go down to zero. The object is more likely to be just deallocated without setting the count to zero beforehand.

Just to make sure, the view controller itself is normally not deallocated by default behaviors due to the memory warning.