All You Need to Know About the iOS App Lifecycle (Part 2)

As an iOS developer, the iOS app lifecycle is an area you can't skip out on. Knowing how to hook into the individual state changes is just as important. Therefore, let's get familiar with implementing lifecycle hooks in your apps.

Written by 

This is part 2 in this short series on the iOS app lifecycle. In the first part, we looked at the different states as well as hooks for the app lifecycle. In this post, we'll dig deeper and touch upon the mechanics of state changes. This involves taking a close look at UIApplication as well as NotificationCenter which both play a role for notifying you as a developer whenever your app changes state.

To give you an overview of the different interactions between the objects commonly found in most apps, check out the figure below.

You may have seen it from the official iOS documentation. I won't go into details with this one, but what's worth noting is UIApplication and which role it plays in the app.


There is a single shared UIApplication instance in every iOS app. Mostly it delegates behavior to its delegate, AppDelegate. You have probably noticed that the AppDelegate.swift file contains different methods to be implemented. All of these originate from the UIApplication object.

This object is the all-knowing being that notifies us of any state changes in the lifespan of our apps. It does this in two ways:

  1. By calling the delegate methods in AppDelegate.swift which we can implement.
  2. By posting notifications using NotificationCenter which we can listen for.

The first way is fairly straightforward as you might imagine. The file already exists and the methods are just waiting for implementation. The second way, however, requires its own section in this post.

We can access the shared UIApplication in our app by writing the following:

let app = UIApplication.shared

UIApplication also has some useful methods that we can take advantage of. Just to name a few, one method allows you to schedule local notifications inside your app. You can even find a method to ask for more time when your app gets backgrounded. It also provides us with some getter methods such as:

var backgroundTimeRemaining: TimeInterval { get }

This one tells us how much time our app has left in the backgrounded state before it gets suspended. We also have this method:

var applicationState: UIApplication.State { get }

This will let you know of the current state that your app resides in. It is a useful method that may come in handy during debugging.


As previously mentioned, the UIApplication will broadcast a notification, whenever your app's state changes. The NotificationCenter class is the key player involved in this process. Let's look at how you can listen for notifications in your code.

Listening for a notification
Listening for notifications is quite simple. First, we get an instance of NotificationCenter by writing:

let center = NotificationCenter.default

This is the default NotificationCenter. Now, you can register an observer of a given notification. This is done by using the following method:

You provide this method with the following arguments:

  • The unnamed argument observer is the observer object of the notification. This is often self.
  • The argument aSelector is the function that gets executed, whenever the notification is received.
  • The argument aName is the name of the notification for which you register.
  • The argument anObject is the broadcaster object you're interested in receiving notifications from. By providing nil, you listen to anyone broadcasting a notification with the given name.

Let's look at an example of this method in use:

Our selector onNotificationReceived gets called with a notification of type Notification. It encapsulates the data coming across in the broadcast. Using this, we can fetch the property userInfo. This is a dictionary of notification-specific information. In that dictionary is any information that the broadcaster wants us to have. Beforehand, anyone broadcasting notifications will have to let you know of the notification name as well as the keys inside the userInfo dictionary.

Posting a notification
We've seen how simple it is to listen for notifications. Luckily, it is even simpler to post notifications that can be listened for. This is done in two steps. First, we create an instance of Notification. Afterward, we call post on our NotificationCenter object. This method looks like this:

You provide this method with the following arguments:

  • The argument aName is the name of the notification of type Notification.Name.
  • The argument anObject is the sender of the notification. Usually, we'll provide it with self.
  • The argument userInfo is the dictionary that contains the notification data.

An example of this is seen below:

That's it! This should seem fairly straightforward because it is. This is exactly what UIApplication does whenever it notify you of state changes, which we can easily listen for.

Wrapping up

This was part 2 of 2 in this short series of posts about the iOS app lifecycle. We touched upon the mechanics of state changes which involves the UIApplication that uses NotificationCenter to notify whenever a state change happens.

Thanks for reading. Remember to leave a comment and share with your fellow developers.

Share this post


You may also like


Native App vs React Native App – What Should You Choose?

Gone are the days where the only options in mobile app development were native iOS and Android. The choices are broader nowadays, and frameworks have popped up with React Native being the most popular alternative. So what approach should you choose for your next app?


Refactoring iOS Apps – A Pragmatic Guide

While your app and development teams grow larger, the codebase is inevitably going to scream for refactoring – that is, improvements in the design of the existing code. There are no silver bullets to refactoring, but iOS apps tend to get into the same pitfalls. Luckily, the common cases of refactoring can be mitigated by being in line with the following set of practices on improving and maintaining code while speeding up development.


Architecting a Feature Toggle Service for iOS Apps

Feature toggling is essential for keeping your apps flexible in production. Sometimes you want to try ideas fast to see if they stick. Maybe you want to split test two ideas and see what performs the best. Whatever the case may be, the feature toggling service should be highly scalable and not be a bottleneck in your workflow. Here’s how you create a feature toggling service with a clean iOS architecture.