Activity vs UIViewController Lifecycle

I’ve had the opportunity to work on Android for a while now building a career on it. In 2017, I got the privilege to dive head on into the iOS waters when I built an MVP app for my previous company. Back then, I learnt by trying to map the concepts one-to-one: AppCompatActivity to UIViewController, XML layouts to StoryBoard/Nib Files etc. Luckily, the company hired a full-time iOS dev who shaped the app in accordance to iOS platform guidelines and industry standards. I retreated to do minor bug fixes and code reviews as I watched and learnt iOS development from the pros.

Image for post
Image for post
Photo by NordWood Themes on Unsplash

I recently (one week ago 🙈) resolved to keep up with iOS development alongside Android and what a better way to learn than to build an app idea I’ve been having on my mind. In the process, I came across a view controller lifecycle-related challenge which I cover in another article. That led me to this discussion between Activity and ViewController lifecycle callbacks.



One of the biggest assumptions I made was that Activity lifecycle callbacks map to ViewController callbacks. Let’s look why this isn’t necessarily the case as we look beyond the basics.

Activity/UIViewController Lifecycle


An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window …

But let us go with a clearer explanation presented elsewhere in their documentation:

An activity is the entry point for interacting with the user. It represents a single screen with a user interface.

You use an instance of the activity to place your UI but we are more interested in its lifecycle (and related callbacks).

Activity lifecycle
Activity lifecycle
Activity lifecycle (source

From the image above, we can count 7 lifecycle callbacks methods exposed by the activity to hook up your logic. There are other supporting callbacks, for instance, methods to save the activity state in a bundle. All these are in response to the activity’s lifecycle itself. For an instance, when the activity is going away (e.g the app is backgrounded), a series of callbacks in the activity, starting with onPause(), are invoked in response. One may expect a corresponding behavior in the ViewController but let’s have a look at it.


An object that manages a view hierarchy for your UIKit app.

From the documentation, we can see that one of the main responsibilities of the view controller is to manage a view (for which it maintains a reference using the view property). In the view controller, you can override view callbacks e.g. viewDidAppear(), viewWillDisappear() etc. Check out the state transition diagram and corresponding literature here. These callbacks are in relation to the view that the UIViewController is managing and not the UIViewController itself.

Nevertheless, in regards to detecting when the UIViewController is going away, the best bet is to still rely on the view*() callbacks e.g. viewDidDisappear() is invoked after a view controller has been dismissed by the presenting controller. NB: child view controllers have lifecycle methods e.g. willMove(), didMove() etc in which you can use in your app. Also, WatchKit has methods awake(), *Activate() and *Appear() that hook up well with the WKInterfaceController’s lifecycle events.

viewDidLoad(), therefore, is technically not the corresponding equal for onCreate() even though both are called in the initial stages of their parents’ lifecycles. The former is called after the controller’s view is loaded into memory and the latter is invoked when the activity is starting. Clearly, these two can’t just be mapped one-to-one!


Written by

Software Engineer |

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store