UIApplication State Transitions and Background Rules

Most common use case is when the user taps the app icon and the application starts.
1.) App wakes up
2.) You do some initialisation (Optional, but almost always used)
3.) Create some UI, Screen
4.) Trigger some API calls (Optional, but often used)

While this is happening, app state (UIApplication.State) is changing.

Inactive

The app is running in the foreground but is not receiving events. Transitional state (multitasking UI). The app is either going to or coming from Active state. Like open another app, home button tap, screen turned off by power button, terminate the app by swipe, caller…

Transitions:
1.) Not Running -> Inactive -> Active
2.) Active -> Inactive -> Background
3.) Background -> Inactive -> Active

Active

The app is running in the foreground and currently receiving events. The app is onscreen and running and ready for user interaction.

Background

The app is running in the background.
Can be launched by the system by Push / Local Notification, Time Sensitive Events, Background Processing, Background Fetching…
Can perform some logic. In this state after some time the OS kills the app.
On iOS12 it is around 180s (not officially confirmed by Apple).
On other OS versions it is mostly around 10s in my experience.
It can be extended by beginBackgroundTask(expirationHandler:) or beginBackgroundTask(withName:expirationHandler:).

If you want to know exactly the time, UIApplication.shared.backgroundTimeRemaining can show it.
Keep in mind that with the break point it will still be ticking as this is OS specified time. Also if you see some huge number that means it is “infinite” and termination is not triggered.

Suspended

The app is still in memory. But not executing any code. Battery life is not affected by the app. In case of needing of more memory, the OS can terminate the app.

Not Running

The app was either terminated or just hasn’t been launched. Basic state of iOS application.

If you want to monitor when the app is triggering some lifecycle method from the background. In that case you may want to check if the Push Notification has some custom property that should trigger some fetching, syncing or any process in your app.

Custom Push Notification processing

Apple changed the states within the lifecycle a couple times. Assume with regrets and reverted back. So there are some differences between OS versions and even subversions. I find that iOS13 subversions have the biggest differences.

Use case 👉 Solution

Swizzling is used by many 3rd party frameworks. This technically means they will override some AppDelegate lifecycle methods and call what they have implemented. If you have more 3rd party SDK using swizzling, they could conflict between each other.
Solution could be to have more CustomAppDelegate, like in the example project. Sometimes this resolves the issue but all depends on the 3rd party framework implementations and options.

Outro

Now if you go back to the previous article you can understand the logs better.
My suggestion is to look into the application(_:didFinishLaunchingWithOptions: method, as it is triggered with different states.

If you got to this point, thanks for reading. 🙂 If you like the content please 👏, share, subscribe, buy a coffee it means to me. If you have some suggestions or questions please feel free to comment.