Skip to content. | Skip to navigation

Personal tools

Sections

iOS AppDelegate Timeline

| filed under: ,

The Apple documentation is mostly in text. For those like myself who learn best from visual diagrams rather than words, here is the holy grail of iOS application delegate call sequencing. Or what happens in what order starting from the time your iOS application starts up and ending when your view is ready for user interaction.

For example, if a custom UIViewController object needs to interact with a controlled view's parameters, should it do it during:

  • initWithCoder:
  • awakeFromNib
  • loadView
  • viewDidLoad
  • or viewWillAppear?

The Apple UIViewController documentation offers the following advice for awakeFromNib.

To finish instantiating it (the ViewController), you override its (the ViewControllers) awakeFromNib method.

And the UIKit documentation for awakeFromNib states:

The nib-loading infrastructure sends an awakeFromNib message to each object recreated from a nib archive, but only after all the objects in the archive have been loaded and initialized. When an object receives an awakeFromNib message, it is guaranteed to have all its outlet and action connections already established.

However, we can see from the chart that in the case of a UIViewController, views are not loaded by the time awakeFromNib is called on a UIViewController. They are not fully loaded until the appropriately named viewDidLoad callback.

In addition, while the ViewControllers views are fully loaded when viewDidLoad is called, they are not laid out so you still would not want to use parameters which are dependent on the views layout size. During viewDidLoad, you might set parameters which would effect the view layout but you would wait until viewWillAppear to get and use any final view size parameters.

I believe my chart makes this clear at a glance whereas the standard text documentation would not.

Here is a PDF of the Application Delegate Callbacks Timing Chart.