When is the best time to initialize?

You now have some experience with the application lifecycle. Now that we are working with the navigation-based app style, and a data source, it’s time to ask about the best time to initialize your objects.


This post was most recently updated in October 2011.


The “Events” example apps helped us understand the lifecycle of a different kinds of iOS apps. They also provide us with valuable information to help us code our methods wisely.

When is the best time to initialize?

There’s no simple answer. However, there are three or four methods that you could use, in the app delegate, and in the first/root view controller. Selecting one to use will depend on your data source, your goals, and so on.

Typical startup sequence

As you have learned from studying the “Events” example apps, the typical app launch will cause these view controller methods to be called, in the following sequence:

  1. awakeFromNib
  2. viewDidLoad
  3. viewWillAppear:
  4. viewDidAppear


What about the app delegate methods? A couple of them fire after awakeFromNib. Typically, we don’t use those much, because we don’t want to use the app delegate as a data source. That’s not good practice for iOS apps.

Which method do we use? As noted above, it will depend. Below, I have taken excerpts from the class reference documentation for each of these methods. Read them to help you decide what’s best for your app.



Prepares the receiver for service after it has been loaded from an Interface Builder archive, or nib file.

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.

Typically, you implement awakeFromNib for objects that require additional set up that cannot be done at design time.

For example, you might use this method to customize the default configuration of any controls to match user preferences or the values in other controls.

You might also use it to restore individual controls to some previous state of your application.



This method is called after the view controller has loaded its associated views into memory.

This method is most commonly used to perform additional initialization steps on views that are loaded from nib files.



This method is called before the receiver’s view is about to be displayed onscreen and before any animations are configured for showing the view.



This method is called after the receiver’s view was added to a window.





  1. Dennis Christopher
    March 25, 2011 at 2:48 pm

    Hi Peter,

    You state: “Typically, we don’t use those much, because we don’t want to use the app delegate as a data source. That’s not good practice for iOS apps.”

    Why is not good good practice?


    • petermcintyre
      March 28, 2011 at 9:22 am

      Typically, we don’t want to create a specific dependency on the app delegate (as a singleton). It’s OK for the app delegate to initialize the data model. Then, as the Core Data object management and persistence framework usage pattern suggests, we pass on the reference to the data to a controller, to a data-bearing property. This enables the controller to be portable, within the app, or to other apps. To use it elsewhere, you would simply set the data-bearing property, and the controller becomes ready-to-use.

      Hope this is satisfactory.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: