Introduction to Application Lifecycle fundamentals

Introduction

Lately I was working with new developers and interviewing trainee candidates. In the process I have realised that maybe there is a value to write a bit more detailed series of articles about iOS App Lifecycle, AppDelegate, App States (UIApplication.State), UIViewController and UIView.
Generally about these lifecycle components and their connections.
This is a really important area that sometimes confuses newcomers to the mobile world.

Lots of time I see the base of the application wrongly built. By coincidence the app works properly till some new feature is introduced. This can break down the app or just introduce some not wanted side effects. These kinds of issues are mostly introduced by following online basic tutorials, by “copy-paste” them to our code and not thinking about the question, will they cover our use case or maybe need some adaptation of that code.

At every end of this article series I will try to list some real world use cases that I came across and the possible solutions.

If you are working on an existing project there is a high chance that you must support iOS12 or even below. For that reason first let see AppDelegate without SceneDelegate possibilities.

App Launch Sequence

1. The user or the OS launches the app, or the OS Prewarms on iOS15 the app.
2. The OS executes the main() function
3. The main() function calls UIApplicationMain(_:_:_:_:), which creates an instance of UIApplication and of your app delegate. This is like singleton of the app instance.
4. UIKit loads the default storyboard you specify in the apps Info.plist file (apps that don’t use a default storyboard skip this step)
5. UIKit calls the application (_:willFinishLaunchingWithOptions:) method in the app delegate.
6. UIKit performs State Restoration, which results in the execution of additional methods in the app delegate and apps view controllers.
7. UIKit calls your app delegates application (_:didFinishLaunchingWithOptions:) method.

After the launch sequence completes, the system uses the app or scene delegate to display the apps user interface and to manage its life cycle.

“In iOS 15 and later, the system may, depending on device conditions, prewarm your app — launch nonrunning application processes to reduce the amount of time the user waits before the app is usable.” — by Apple

Use case 👉 Solution

If you use Silent Push Notifications and your first screen is instantiated with application (_:didFinishLaunchingWithOptions:), then that screen will be fired every time e.g.: if Silent Push Notification arrives. The screen will not be shown, but screens lifecycle methods will be still triggered. This is sometimes not an issue.

But if you use some kind of Analytics, 👉 then the screen view event could be fired every time, 👉 what can lead to a wrong impression of the number of active user screen views.

This can be manifested by any kind of background processing.
Solution is to move first screen initialisation to applicationDidBecomeActive(_:) or create a temporary screen(e.g.: pre-loader) that will manage just the routing and will have minimal logic.

Outro

Don’t make assumptions about what services and resources are available at startup.
Lots of frameworks did this and now with iOS15 they have issues and probably need big rework.

Now that we know on a high level how the application lifecycle behaves, in the next part we will introduce in more details the AppDelegate and its methods.

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.