Developing code for iOS means that you are going to use at least one UIViewController in your app. This is one of the elements of the Model-View-Controller (MVC) design pattern and it is really helpful to understand its lifecycle. There are certain methods that called automatically when the view controller is loaded, presented and hidden. Lets present them one by one:
– init:
This method is responsible to return a newly initialised view controller, either coming from a specific nib file in a bundle or a storyboard (initWithNibName:bundle: or initWithCoder: respectively). When using storyboards you never initialise the view controllers directly, this is implemented when a segue is triggered or programmatically using instantiateViewControllerWithIdentifier: method.
– loadView:
The view controller calls this method when its view property is requested but is currently nil. In this method the view, which the view controller manages, is either created or loaded. You can override this method when you want to create your views programmatically.
– viewDidLoad:
The ViewController is responsible to manage a related view hierarchy. This method is called when this hierarchy is loaded in the memory either coming from the storyboard (or in general a nib file) or created programmatically in the loadView method. However, the bounds for the view are not defined yet. Most of the times this method is overridden in order to perform addition initialisation either related with objects that the controller is going to use and/or with views that loaded from the nib files.
– viewWillAppear:
This method notifies the view controller that its view is about to be added to a view hierarchy. Actually, this is the point where the view controller’s view is about to appear on the screen before any animations are configured. When this event occurs, the view has bounds that are defined but the orientation is not set. Unlike viewDidLoad, viewWillAppear is called the first time the view is displayed as well as when the view is displayed again, so it can be called multiple times during the life of the view controller object.
– viewWillLayoutSubviews:
This method is called to notify the view controller that its view is about to layout its subviews. So for instance when the rotation is changed, the view’s bounds are changed and using this method we can adjust the new positions of its subviews manually. At this point the bounds are finalised. Usually, we override this method when we have disabled autoresizing masks or constraints and we want to update the subviews manually.
– viewDidLayoutSubviews:
This method is called when the view controller’s view has adjusted the position of its subviews after a change in its bounds. So, we can override this method if we want to make any changes to the subviews after they have been set.
– viewDidAppear:
When the view is eventually presented on the screen this method is called. At this point the view controller’s view is part of the view hierarchy. It is a good place to acquire data from external sources like backend services or databases.
– viewWillDisappear:
This event occur when the view controller’s view is about to be removed from the view hierarchy. At this point the view is still in the hierarchy and the animations has not been configured yet. It is the correct place to hide the keyboard, cancel running timers or network requests, revert changes to the orientation or the style of the status bar. Like its counterpart method viewWillAppear:, this method can be called multiple times in the view controller’s lifecycle.
– viewDidDisappear:
This method is called when the view controller’s view has been removed from the view hierarchy. It can be overridden in order to to perform tasks like dismissing or hiding the view. For instance you can stop listening to notifications or monitor the device sensors.
Additional good resources for this subject are Apple’s UIViewController reference manual, matteo’s manferdini article, and several questions and answers in stackOverflow.