iOS App Life Cycle

Bored 🥑
4 min readAug 21, 2017

--

This account is no longer in use. Please checkout my latest articles in iOS Interview Preparation Complete Guide.

iOS Interview Prep Series

iOS Interview Prep 0 — Intro
iOS Interview Prep 1 — Memory management
iOS Interview Prep 2 — Autorelease Pool
iOS Interview Prep 3 — Blocks and Closures
iOS Interview Prep 4 — Event Handling & Responder Chain
iOS Interview Prep 5 — Singletons
iOS Interview Prep 6 — Dependency Injection
iOS Interview Prep 7 — Concurrency Part 1
iOS Interview Prep 7 — Concurrency Part 2
iOS Interview Prep 8 — View and Layout
iOS Interview Prep 9 — App performance
iOS Interview Prep — Testing Strategy
iOS Interview Prep 10 — Unit Test
iOS Interview Prep 11 — Integration Test
iOS Interview Prep 12 — Snapshot Test

During startup, the UIApplicationMain function sets up several key objects and starts the app running. At the heart of every iOS app is the UIApplication object, whose job is to facilitate the interactions between the system and other objects in the app.

The UIApplication object manages the event loop and other high-level app behaviors. It also reports key app transitions and some special events (such as incoming push notifications) to its delegate, which is a custom object you define. Use the UIApplicationobject as is—that is, without subclassing.

The app delegate is the heart of your custom code. This object works in tandem with the UIApplication object to handle app initialization, state transitions, and many high-level app events. This object is also the only one guaranteed to be present in every app, so it is often used to set up the app’s initial data structures.

The Main Run Loop

An app’s main run loop processes all user-related events. The UIApplication object sets up the main run loop at launch time and uses it to process events and handle updates to view-based interfaces. As the name suggests, the main run loop executes on the app’s main thread. This behavior ensures that user-related events are processed serially in the order in which they were received.

Events are queued internally by the app and dispatched one-by-one to the main run loop for execution. The UIApplication object is the first object to receive the event and make the decision about what needs to be done. A touch event is usually dispatched to the main window object, which in turn dispatches it to the view in which the touch occurred.

Execution States for Apps

Not running The app has not been launched or was running but was terminated by the system.

Inactive The app is running in the foreground but is currently not receiving events. (It may be executing other code though.) An app usually stays in this state only briefly as it transitions to a different state.

Active The app is running in the foreground and is receiving events. This is the normal mode for foreground apps.

Background The app is in the background and executing code. Most apps enter this state briefly on their way to being suspended. However, an app that requests extra execution time may remain in this state for a period of time. In addition, an app being launched directly into the background enters this state instead of the inactive state.

Suspended The app is in the background but is not executing code. The system moves apps to this state automatically and does not notify them before doing so. While suspended, an app remains in memory but does not execute any code. When a low-memory condition occurs, the system may purge suspended apps without notice to make more space for the foreground app.

The lunch cycle

Launching an app into the foreground
Launching an app into the background
Moving from the foreground to the background

--

--