iOS Application Launch Sequence

Vikash Anand
Aug 11 · 9 min read

This article talks about all the steps involved in a “Launch of an iOS application”

What happens when an application is launched:

When initialisation is complete, the system uses either your scene delegates(iOS 13 and later) or application delegate(iOS 12 and earlier) to display your UI and manage the life cycle for your app.

The application launch and initialisation sequence

Info.plist — An information property list file is a structured text file that contains essential configurationinformation for a bundled executable. The file itself is typically encoded using the Unicode UTF-8 encoding and the contents are structured using XML. The root XML node is a dictionary, whose contents are a set of keys and values describing different aspects of the bundle. The system uses these keys and values to obtain information about your app and how it is configured. As a result, all bundled executables (plug-ins,frameworks, and apps) are expected to have an information property list file.

For example — Main story board file base name is picked from this file.

Application’s run loopis used by the UIApplication instance to process events such as touches or network events. The run loop is basically an infinite loop that causes UIApplicationMain() to never return.

Note — application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool methods tell you the reason due to which application is launched and you can find that reason in the “launchOptions” parameter.

For example if an application is launched by apple push notification then following code can be used to confirm the same.

@UIApplication — What and why?

Now a days we don’t hava main.swift file and instead we get a Xcode provided @UIApplication attribute in the application delegate file which does the following things

  • Indicates that it’s(file in which this this attribute is specified) the application delegate.
  • Using this attribute is equivalent to calling the UIApplicationMain() function and passing this class’s name as the name of the delegate class.

This is a special attribute that tells the Swift compiler to generate code to launch your application using default settings but if you have a requirement of customising the behaviour of UIApplication then

  • Delete @UIApplicationMain attribute from the appDelegate file.
  • Subclass UIApplication — This allows you to override functionality such as opening URLs.
  • Supply a main.swift file with code at the top level that calls the UIApplicationMain(_:_:_:_:) function.

i.e. — Subclass UIApplication

class MyApplication: UIApplication {}

Call UIApplicationMain() from main.swift

UIApplicationMain(CommandLine.argc,CommandLine.unsafeArgv,NSStringFromClass(MyApplication.self),NSStringFromClass(MyAppDelegate.self)) from the main.swift

When application is launched in Background

For applications that support one of the Background Modes capabilities (Background Fetch, Audio, Voice over IP, Bluetooth Communications, Newsstand downloads, remote notifications, Location Updates), the system launches or resumes the application in the background to handle events associated with those capabilities.

iOS Background Modes option in Xcode(Image source — acd92be0–47c8–43d2-bc70–7b7db441c37a.png)

Application can enter background state from multiple starting points.

  • A suspended application can go to a background state due to a system event.
  • A not running application can be launched into background by the system.
  • A foreground application can go to a background state if another application is launched or user returns to the homescreen.
The background execution sequence (Image source -a668c5de-d033–423e-8aea-6100f72c3378.png)

If your application is not running when an event arrives, the system launches the application and moves it directly to the background, following this sequence:

  • The system launches the application and follows the initialisation sequence described above in “What happens when an application is launched” section.
  • UIKit calls the application delegate’s applicationDidEnterBackground(_:) method or scene delegate’s sceneDidEnterBackground(_ scene: UIScene).
  • UIKit delivers the event that caused the launch.
  • The app’s snapshot is taken.
  • The application may gets suspended again.

If your application is in memory and suspended when an event arrives, the system resumes the application in the background, following this sequence:

When another application is launched or the user returns to the Home screen, the foreground application moves to the background, following this sequence:

Things to consider for a smooth transition to background state

  1. Quiet Your App upon Deactivation — The system deactivates apps for several different reasons. When the user exits the foreground app, the system deactivates that application immediately before moving it to the background. The system also deactivates apps when it needs to interrupt them temporarily — for example, to display system alerts. In the case of a system panel, the system reactivates the application when the user dismisses the panel.During deactivation, UIKit calls one of the following methods of your app:

Use deactivation to preserve the user’s data and put your application in a quiet state by pausing all major work; specficially:

  • Save user data to disk and close any open files.
  • Suspend dispatch and operation queues.
  • Don’t schedule any new tasks for execution.
  • Invalidate any active timers.
  • Pause gameplay automatically.

2. Release Resources upon Entering the Background — When your application transitions to the background, release memory and free up any shared resources that your application is holding. For an application transitioning from the foreground to the background, freeing up memory is especially important. The foreground has priority over memory and other system resources, and the system terminates background apps as needed to make those resources available. Even if your application wasn’t in the foreground, perform checks to ensure that it consumes as few resources as possible.

Upon entering the background, UIKit calls one of the following methods of your app:

During a background transition, perform as many of the following tasks as makes sense for your app:

  • Discard any images or media that you read directly from files.
  • Discard any large, in-memory objects that you can recreate or reload from disk.
  • Release access to the camera and other shared hardware resources.
  • Hide sensitive information (such as passwords) in your app’s user interface.
  • Dismiss alerts and other temporary interfaces.
  • Close connections to any shared system databases.
  • Unregister from Bonjour services and close any listening sockets associated with them.

Note — You don’t need to discard named images that you loaded from your app’s asset catalog. Similarly, you don’t need to release objects that adopt the NSDiscardableContent protocol or that you manage using an NSCache object. The system automatically handles the cleanup of those objects.Make sure your application is not holding any shared system resources when it transitions to the background. If it continues accessing resources like the camera or a shared system database after transitioning to the background, the system terminates your application to free up that resource.

3. Prepare Your UI for the App Snapshot — When your application enters the background, UIKit takes a snapshot of your app’s current user interface. The system displays the resulting image in the application switcher. It also displays the image temporarily when bringing your application back to the foreground.Your app’s UI must not contain any sensitive user information, such as passwords or credit card numbers. If your interface contains such information, remove it from your views when entering the background. Also, dismiss alerts, temporary interfaces, and system view controllers that obscure your app’s content. The snapshot represents your app’s interface and should be recognizable to users. When your application returns to the foreground, you can restore data and views as appropriate.

Q&A

Q — When the iPhone restarts, can all these apps start up as well and take up valuable processor time and system resources?

A— Only if they are specifically configured to run in the background, you can check if they’ve been doing that in your iPhone’s Battery settings.

Q — What if I start an app, and then explicitly double tap on the Home button, and then slide the application out (to exit it). Can it or part of it still run in the background now or later?

A — Yes. For example, if Facebook uses location services (as it does), then swiping up to kill the Facebook application will not stop it from using your location in the background, and while it’s using your location, it can perform just about any other task in the background too.

Q-Since WhatsApp, WeChat, Line, and Facebook Messages all notify me of new messages, it looks like they will be running as soon as I restart my iPhone. Are the using my CPU in the background? Also, it seems that even if I turn off App Refresh in Settings, the apps can possibly still run in the background. Is that true?

A- Whatsapp, WeChat, Line, Hangouts, FB Messenger, and other chat apps use the remote notifications capability to check for new messages in the background every once in a while. This is expected behavior and shouldn't drain your battery too much. And indeed, turning off App Refresh for those apps will not have any effect, as the apps use remote notifications and not background fetch to operate in the background.

Source for the above Q&A

Note — You can check what applications are using your battery on app-by-app basis and in that list iOS will specify “background activity” againt the applications that has used battery in the background.

Goto Settings →Battery and scroll-down to check this list.

A word of caution for those who go on a rampage to kill all the apps present in their multitasking interface.

Believe it or not, removing apps from memory using the multitasking interface could actually lead to less battery life in the long run. When you re-open such an app, your phone will have to read its data into RAM from your device’s storage and re-launch the app. This takes longer and uses more power than if you had just let the application suspend peacefully in the background.

Details — https://www.howtogeek.com/204552/no-closing-background-apps-on-your-iphone-or-ipad-wont-make-it-faster/

That’s it for now and i hope you find this helpful. Thanks for reading. 😀😀😀

Resources for this article:

Vikash Anand

Written by

iOS Application Developer.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade