Programming iOS 4

View Controller Memory Management

Memory management works in a special way for view controllers. Memory is at a premium on a mobile device, and a view is memory-intensive (though a view controller itself will probably not be). A view controller can persist without its view being visible to the user — because a modal view is covering it, or because it is in a tab interface but is not the currently selected view, or because it is in a navigation interface but is not the top view of the stack. In such a situation, if memory is getting short, then even though the view controller itself persists, the runtime may nilify its view, thus releasing the view and its subviews. The view is effectively unloaded.

If a view controller’s view is unloaded, then the next time that view is needed for display or mentioned in code, we’ll go through the whole rigmarole of loading the view again — creating it in code if loadView is overridden, or loading the associated nib. And that’s the whole point of the way a view controller’s view is loaded lazily in the first place. Memory may become tight, but a view controller’s view needn’t occupy memory unless it is actually needed, to appear in the interface.

(This is why it’s generally better not to have the view controller and its view in the same nib file. In that case, the view can’t be unloaded, because there would be no way to load it again. So such a view can’t participate in this aspect of iOS app memory management.)

This comes as a surprise to beginners ...