When it comes to iOS development the back bone of most of your apps will be UIViewControllers. These UIViewControllers come with services and features that make iOS app possible. This includes being able to switch between UIViewControllers and managing the sizes of your views, handling children sub views and many other things. In fact, it would be difficult to really have an iOS app without utilizing some derivation of UIViewController. That include UICollectionViewController, UITableVIewContorller, UINavigationController, UITabViewController. Majority of the apps in the app store utilize these derivations of UIViewController.

Why?

UIVIewControllers, as already mentioned, come prepackaged with a lot of functionality that make iOS development enjoyable and fun. Diving deeper, UIViewControllers allow you to create hierarchies of views by imbedding UIViewControllers within UIViewControllers while having one UIViewController as the root of the hierarchy. Thus they also allow you the flexibility of creating a general container UIViewController to fully customize the flow of your application, and be able to reuse components to make your life easier as a developer. Moreover, not to mention all the auto layout features such as, size classes, adjusting content universally for all iOS devices and their various orientations, which makes creating UI a lot easier.

UIViewController are also utilize to handle interactions between views and data models (look up MVC Design Pattern)

To utilize full utility of these UICollectionViews and their derivatives it is important to understand their life cycles.

The Birth/Infancy:

Typically, UIViewControllers are instantiated from storyboards unless you implement them programmatically or you ask iOS to give you a UIViewController (the camera UIViewController for example)

Childhood:

After the UIViewController is instantiated, if the UIVIewController has been called by means of a segue, then the UIVIewController undergoes preparation which is done programmatically by the object or class that has called the UIViewController. Regardless of whether the UIViewController was segued into, then there is outlet setting where all components in your UI get connected to you UIViewController

Adolescence:

Once your UIViewController has undergone instantiation, preparation and set up (Birth and Childhood), it is then time for you UIViewController to go mature and go through changes. During this face, as your UIViewController tries to understand itself and develop (mentally and physically) and learn to express itself, it will disappear and reappear (be on screen and off screan) and possibly have changes in its geometry and views(frame changes, addition of views, animations, sounds, etc.)

Integrity and Despair:

Moreover, if your UIVewController has not been mentored for self-reliance and self-control (i.e need of too much memory that impacts performance), there is still hope, via methods that will allow you to further enhance the nurturing of your UIViewController.

Excuse my attempts of stepping-outside my comfort zone and trying to be entertaining. Let’s get to business and create more neural connections in that brain of yours by learning the life cycle of UIViewControllers and continue our journey of becoming competent iOS developers.

Overview

Instantiated (from storyboard usually)

awakeFromNib

            this method gets called if your UIViewController comes out of a story board and happens before any of your UIViewControllers outlets and actions happen, thus avoid putting any initializing code here that modifies outlets or actions. You can technically do initialization here, but it is not good practice since your outlets are not set up yet. This would be a good location to do any delegation.

  • segue preparation happens
    • If your UIViewController (Destination View Controller) gets called via a segue from another UIViewController (Source View Controller), then under the hood, before the segueing into the Destination View Controller, the Destination View Controller gets prepared for segue and this is where any of its properties gets set or any data transfer (dependency injection) to it happens before appearing on the screen.

viewDidLoad

At this point you are guaranteed that all of your outlets and actions have been set. This method gets called once in the entire life cycle of your UIViewController; thus, this is the perfect spot to put any code that requires to run once. Also, this is a good spot for any initialization. However, this is not a good place to mess with the dimensions (Frames) of your UIViewController or any of its sub views because at this point your UIViewController does not know what device it is on.

viewWillAppear and viewDidAppear

Unlike viewDidLoad, these methods get rapidly called as your UIViewController come on and off screen. Good thing to know is that when your UIVIewController goes off screen it also leaves from the heap(memory)

viewWillAppear

this method gets called when your UIViewController is about to come on the screen. This is a good spot to load up any data from your model objects. At this point your UIViewController knows what device it is on, and thus technically you could adjust your user interface’s geometry (Frames and bounds) here but there are other life cycle methods where this is more appropriate

viewDidAppear

this method gets called once your UIViewController has appeared on on the screen. Although viewWillAppear gets called right before your UIViewController appears on screen, it does not guarantee that your UIViewContrller actually comes up on the screen. Because of this, it is your safest bet to use viewDidAppear to start any animations or music in your app or utilize the GPS this is also a good place to do any time-consuming operations like doing network calls.

viewWillDissapear

At this point your UIViewController is still on screen, but is it is soon to go off screen. This is a good location to undo that changes that you did in your viewWillAppear

viewDidDisapear

At this point your UIViewController is actually off screen. This is a good place to do any clean up. This is also a good place to do any saving of states.

didReceiveMemoryWarning

This function is rarely called, and it is called when your app utilizes too much memory.

Note: if you know your app is going to be memory intensive perform operations that require a lot of time, your UI should account for this by providing animations or ques that let your user now that your app is gathering/loading data.

AutoRotation

Most of your UIVewiControllers Layout, any frame, or bounds changes happen with auto layout, and when your UIViewController undergoes autorotation viewWillLayoutSubviews and viewDidLayoutSubviews gets called. If you want to partake in the animation when your UIViewController undergoes autorotation you can utilize the viewWillTransition function.

viewWillLayoutSubViews(… then autolayout happens, then …) viewDidLayoutSubviews

these are good functions in which to participate in the layout changes of you app. Be aware that these functions get called multiple times throughout the life cycle of your UIViewController, for example after animations that modify the layout of your UIViewControlller. Thus, this is not a good place to put code that is not effective or efficient in getting called repeatedly.

There it is! The life cycle of a UIViewController

Resources:

Stanford – Developing iOS 11 Apps with Swift – 9. View Controller Lifecycle and Scroll View