UIViewController Lifecycle

ViewDidLoad: When this method gets called, the view of the view controller has been created and you are sure that all the outlets are in place. It is common to use this method to populate the user interface of the view controller with data before the user sees it.

It is also a good place where to start some background activity where you need to have the user interface in place at the end. A common case are network calls that you need to do only once when the screen is loaded.

If you need to repeat them to update the data in the view controller, viewDidAppear(_:) is more appropriate to do so.

This method is called only once in the lifetime of a view controller, so you use it for things that need to happen only once.

ViewWillAppear - Called right before your view appears, good for hiding/showing fields or any operations that you want to happen every time before the view is visible. Because you might be going back and forth between views, this will be called every time your view is about to appear on the screen.

ViewDidAppear: Called after the view appears — great place to start an animations or the loading of external data from an API.

ViewWillDisappear: Similar to viewWillAppear, this method is called just before the view disappears from the screen. And like viewWillAppear, this method can be called multiple times during the life of the view controller object. It’s called when the user navigates away from the screen.

ViewDidDisappear: After a view controller gets removed from the screen, this method gets called. You usually override this method to stop tasks that are should not run while a view controller is not on screen. For example, you can stop listening to notifications, observing other objects properties, or a network call that is not needed anymore.

deinit: Like every other object, before a view controller is removed from memory, it gets deinitialized. You usually override deinit() to clean resources that the view controller has allocated that are not freed by ARC. You can also stop tasks you did not stop in the previous method because you wanted to keep them in the background.

Note: if a view controller going out of the screen(pushed in navigation stack) does not mean that it will be deallocated afterwards. All the previous view controllers inside navigation stack stay in memory.

A navigation controller releases view controllers only when navigating back up the hierarchy (popping view). For this reason, you have to keep in mind that a view controller that is not on the screen still works normally and receives notifications.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.