A small cheat sheet on the UIViewController lifecycle - which methods are called, and in what order, during different transitions between UIViewControllers.
Controller A Pushes to Controller B
Call order during the transition:
- initWithCoder:
- When a storyboard is used, this method is called instead of init or initWithNibName:bundle:
- awakeFromNib
- willMoveToParentViewController:
- prefersStatusBarHidden
- preferredStatusBarUpdateAnimation
- loadView
- loadView assigns all outlets (IBOutlets) to the corresponding @property.
- prepareForSegue:sender:
- viewDidLoad
- All outlets are already connected, but the views have not been rendered yet
- extendedLayoutIncludesOpaqueBars
- edgesForExtendedLayout
- viewWillAppear:
- extendedLayoutIncludesOpaqueBars
- edgesForExtendedLayout
- updateViewConstraints
- viewWillLayoutSubviews
- viewDidLayoutSubviews
- Animation
- viewDidAppear:
- didMoveToParentViewController:
- updateViewConstraints
- viewWillLayoutSubviews
- viewDidLayoutSubviews
Some of the methods are called more than once. Layout is called twice - before and after the animation.
Controller B Pushes to Controller C
During the transition:
- prepareForSegue:sender:
- viewWillDisappear:
- updateViewConstraints
- Animation
- viewDidDisappear:
Controller C Pops to Controller B
When returning from C to B, this happens:
- prefersStatusBarHidden
- preferredStatusBarUpdateAnimation
- extendedLayoutIncludesOpaqueBars
- edgesForExtendedLayout
- viewWillAppear:
- extendedLayoutIncludesOpaqueBars
- edgesForExtendedLayout
- updateViewConstraints
- viewWillLayoutSubviews
- viewDidLayoutSubviews
- Animation
- viewDidAppear:
- updateViewConstraints
- viewWillLayoutSubviews
- viewDidLayoutSubviews
Controller B Pops to Controller A
Leaving B for good:
- willMoveToParentViewController:
- The argument for this call is nil, which means that scene B will be removed from the hierarchy.
- viewWillDisappear:
- updateViewConstraints
- viewDidDisappear:
- Animation
- didMoveToParentViewController:
- The argument is also nil
- dealloc