iOS Application life cycle UIKit Part 1
Active <-> Inactive <-> Background <-> Suspended -> Not running
Part 1 — AppDelegate
We are going to read about:
- 5 states of the iOS application life cycle
- The related methods in app delegate
What is the application life cycle?
An iOS application goes through a couple of states during its life cycle. The app can be active and respond to the user’s needs, chilling in the background, or closed by the user or the OS.
Knowing about these different app states and how our app behaves in each one is super important for providing a great experience for our users and making sure our app is reliable and efficient.
When an app changes its state it sends a notification and we can implement custom functionality for different states within their relative functions.
Note that from iOS 13, the responsibilities of AppDelegate have been split between AppDelegate and SceneDelegate.
The Application life cycle
There are five different states that an app can go through:
- Not running
- Inactive
- Active
- Background
- Suspended
Not running
As the name implies the app is not running and we can not process anything from our app in this state.
Inactive
The app is running in the foreground, but not receiving events. An iOS app can be placed into an inactive state, for example, when a call or SMS message is received. The user is not actively engaged with our app currently. Probably, the app is changing states.
This state can happen in a couple of other scenarios too, for example when we run a not-running app, it first comes to this state and from this state goes to the active state.
Active
The app is running in the foreground, and receiving events. Transitional state. And the user is actively using our app.
Background
The app is running in the background, and executing code. The user is now using other apps but our app is being held alive in the background and can receive events and execute code. In this state, we should do short tasks and return the control back to the OS.
When the app is about to be suspended, then also transitions into this state for a small amount of time. In this state, the app remains in the background and executes the code.
Suspended
The app is in the background, but no code is being executed. The app is still in memory but it is freezed and the OS probably going to remove our app in the near future and the app going to be in the not running state.
The full life cycle from birth to death -> App Delegate — Based
When a user taps on your app icon, the app starts to change state. First, the app delegate gets a call to the application:willFinishLaunchingWithOptions method, which moves the app from a non-running state to an inactive state. Once the app is in the inactive state, the app delegate will get a call to the application:didFinishLaunchingWithOptions method. This gives the app a chance to make any final tweaks before the interface is displayed.
If your app isn’t designed to launch in the background, the operating system will activate it and change the state from inactive to active. At this point, the app delegate will get a call to the applicationDidBecomeActive method, which means your app is ready to go and waiting for the user to interact with it.
Delegate methods
When we run an iOS application in XCode, the main entry point of the application is UIApplicationDelegate, which is a protocol that the application must implement to get notified of several user events like app launch, the app goes into the background, the app goes to the foreground, push notifications, etc.
The UIApplicationDelegate contains certain app lifecycle methods that are notified when the app starts running. The UIApplicationDelegate methods are given below.
application:willFinishLaunchingWithOptions
This method is our app’s first chance to execute code at launch time. This method gets called when the app is about to finish launching, but before it’s actually displayed on the screen. It gives us a chance to do any additional setup or configuration that we need to before the app is fully up and running.
application:didFinishLaunchingWithOptions
This method allows us to perform any final initialization before our app is displayed to the user. This is like the starting gun for an app, and it gives us a chance to set up any initial state that we need to.
These two states (application:willFinishLaunchingWithOptions, application:didFinishLaunchingWithOptions) are responsible for :
- setting up the app
- showing the initial view, ie Login view if the user hasn’t been logged in already, or the ‘Main’ view if auto-login is supported.
- registering for Apple Push Notifications
- registering launch shortcuts
- other one-time-per-app-lifetime actions
applicationDidBecomeActive
The app has entered the foreground app. Use this method for any last-minute preparation. This is like our app getting hyped up and ready to go, and it gets called when the app moves from an inactive state to an active state, like when the user switches back to our app from another one.
applicationWillResignActive
The app is transitioning away from being the foreground app. This is like the “hold on a sec” moment for an app, and it gets called when the app is about to move from an active state to an inactive state, like when a phone call comes in or the user switches to another app.
This state is responsible for:
- pause any timers that were running (ie pause the game)
- throttle down OpenGL frames
- prepare the app for taking a screenshot for the multi-task menu: if the app shows sensitive or secure data, it may be good to blur that content or just show a single-colored view with the app logo in the center
applicationDidEnterBackground
The app runs in the background and may be suspended at any time. This is like our app taking a nap, and it gets called when the user switches to another app or the home screen. According to Apple’s UIApplicationDelegate Protocol Reference, the app has approximately five seconds to perform tasks and return. If the method does not return within five seconds, the application is terminated.
This state is responsible for:
- saving any persistent data that should be saved
- saving enough information about the app state so that it can be restored at a later point, in case it gets killed by iOS
- We may want to pause timers when this state is entered (instead of pausing them when entering the Inactive (Resign Active) state). This depends on what the app’s timers actually do and should UI be updated while the app is in the inactive state
applicationWillEnterForeground
The app moves out of the background and back into the foreground, but it is not yet active. This is like our app getting woken up from a nap, and it gets called when the user switches back to our app from another one.
applicationWillTerminate
The app is being terminated. This method is not called if our app is suspended. This method gets called when the app is about to be terminated, either by the user or by the system. This is our last chance to do any cleanup or save any data before the app goes away.
Interruptions
On occasion, the iOS app will need to respond to interruptions. An alert-based interruption such as a phone call causes the app to move into an inactive state. The app delegate will receive an applicationWillResignActive method call, allowing the app an opportunity to prepare for a temporarily inactive state. If the user chooses to ignore the interruption, or the interrupting process has terminated, the app will move back into the active state. While making the transition from inactive to active, the app delegate will receive an applicationDidBecomeActive method call.
Switching to the background
The iOS devices make it simple to quickly switch from app to app; when a user switches to a different app, the current app moves to the background. The app can be in one of two states: background or suspended. In either case and before switching to the background, the app delegate receives an applicationWillResignActive method call, followed by an applicationDidEnterBackground message. If in a suspended state, the app sleeps. A background state — meaning that the app is allowed to continue executing code — requires the app to monitor and handle events. Developers need to be aware that the operating system may terminate the app at any time.
App Programming Guide
What to do when our app is launched
The application:willFinishLaunchingWithOptions: and application:didFinishLaunchingWithOptions: methods should always be as lightweight as possible to reduce our app’s launch time. The app should launch in less than 5 seconds. If not, the system kills itself.
What to do when our app Is Interrupted temporarily
Save data and any relevant state information. Stop timers and other periodic tasks such as movie playing. Stop any running metadata queries. Enter into a pause state if the app is a game. However, we may still do light networking.
What to do when our app enters the background
When our applicationDidEnterBackground: method returns, the system takes a picture of our app’s user interface and uses the resulting image for transition animations.
If any views in our interface contain sensitive information, we should hide or modify those views before the applicationDidEnterBackground: method returns.
Free up memory as needed. Release any cached data that we do not need and do any simple cleanup that might reduce our app’s memory footprint.
Apps with large memory footprints are the first to be terminated by the system, so release image resources, data caches, and any other objects that we no longer need.
Our app delegate’s applicationDidEnterBackground method has approximately 5 seconds to finish any tasks and return. In practice, this method should return as quickly as possible.
If the method does not return before time runs out, our app is killed and purged from memory.
