The app lifecycle is the sequence of states a mobile application moves through from launch to termination, together with the system callbacks that tell the app when it changes state. In mobile fundamentals, it describes how the mobile operating system, not the user or the app, ultimately controls when an app runs, pauses, works in the background or is removed from memory.
Understanding the lifecycle is essential because smartphones have limited memory and battery. Android and iOS suspend or terminate apps aggressively to keep the foreground app responsive, so a well-built app must save its state at the right moment and restore it seamlessly when the user returns.
How the app lifecycle works
Every mobile platform defines a small set of execution states and notifies the app through lifecycle callbacks when it moves between them. The app reacts to these events by starting or stopping work, releasing resources and saving data. The general model is similar across platforms, as the following table shows.
| State | What the app can do | Typical trigger |
|---|---|---|
| Not running | Nothing, no process exists | Never launched or terminated by the system |
| Foreground active | Full access to screen, input and resources | User opens or returns to the app |
| Foreground inactive | Visible but not receiving input | Incoming call, system dialog or app switcher |
| Background | Limited, short-lived or declared work only | User switches to another app or locks the screen |
| Suspended or cached | In memory but not executing code | System pauses the app after background time ends |
The most important rule is that a suspended app can be terminated without warning. When memory runs low, the system reclaims it from cached apps, and the app receives no further callback. Any state that was not saved when the app entered the background is lost.
Lifecycle callbacks on Android and iOS
Android organizes the lifecycle around components, primarily activities, each with its own callbacks. iOS organizes it around the application and its scenes, where a scene represents one instance of the app’s user interface. The callbacks below are the ones developers rely on most.
| Moment | Android activity callback | iOS scene callback |
|---|---|---|
| Created | onCreate | scene willConnectTo |
| Becoming visible | onStart | sceneWillEnterForeground |
| Ready for input | onResume | sceneDidBecomeActive |
| Losing focus | onPause | sceneWillResignActive |
| No longer visible | onStop | sceneDidEnterBackground |
| Being destroyed | onDestroy, not guaranteed | sceneDidDisconnect |
Android adds a complication known as configuration changes. Rotating the device, changing the language or resizing a window destroys and recreates the activity by default. Architecture components such as ViewModel keep data across these recreations, while saved instance state survives even process death, when the system kills the whole app process in the background.
Launch types and background execution
How quickly an app appears depends on which lifecycle state it starts from. Platform tools distinguish three launch types, and each one has different performance characteristics.
| Launch type | Starting state | What must happen | Relative speed |
|---|---|---|---|
| Cold start | No process in memory | Create process, initialize app, draw first screen | Slowest |
| Warm start | Process exists, screen destroyed | Recreate the screen from saved state | Medium |
| Hot start | App suspended with screen intact | Bring existing screen to the foreground | Fastest |
Background execution is strictly limited on both platforms. iOS grants a short grace period after an app leaves the foreground and otherwise allows only declared modes such as audio playback, navigation, VoIP or scheduled background tasks. Android restricts background services and steers longer work to WorkManager or foreground services that show a persistent notification.
Both systems also watch the main thread. On Android, an app that blocks input handling for about five seconds triggers an Application Not Responding dialog, and iOS terminates apps that take too long to launch or that freeze the interface for an extended period.
App lifecycle compared with related mobile concepts
The term is sometimes used in a second sense: the product lifecycle of an app, from design and release through updates to retirement. In mobile fundamentals, however, it normally refers to the runtime lifecycle described here. Several neighboring concepts interact with it closely.
| Concept | What it covers | Connection to the app lifecycle |
|---|---|---|
| Mobile operating system | Platform that manages processes and memory | Decides when state transitions happen |
| App permissions | User-granted access to sensitive features | Some access, such as location, differs in background |
| Process lifecycle | Life of the operating system process | Can end while screens appear to still exist |
| Product lifecycle | Development, release, updates and retirement | Different meaning of the same phrase |
Common lifecycle mistakes
Lifecycle bugs are among the most frequent causes of crashes, data loss and battery drain in mobile apps, and they often appear only on real devices under memory pressure.
- Saving data only on destroy or terminate, which the system may never call.
- Keeping sensors, location or network listeners active after the app leaves the foreground.
- Assuming the process survives while the app is in the background.
- Running heavy initialization on the main thread during launch, which slows cold starts.
- Testing only with the app freshly launched, instead of simulating process death and returning.
A reliable approach is to treat every background transition as a possible end of the process: persist important state, stop expensive work and be ready to rebuild the screen from saved data.
In everyday language
A phone runs many apps, but it shows only one or two at a time. The app lifecycle describes what happens to an app when it is not on screen. The phone may pause it, keep it waiting, or close it quietly to free up memory.
A good app behaves like a careful reader who places a bookmark before closing a book. When the user comes back, the app opens at the same place, even if the phone had closed it in the meantime.
Seen in the real world
A banking app lets users fill in a long transfer form. Testers notice that users who switch to a messaging app to copy an account number sometimes return to an empty form. On devices with little memory, the system had terminated the app process in the background.
The development team moves form data into saved instance state on Android and scene state restoration on iOS, and saves drafts whenever the app leaves the foreground. For security, it also hides sensitive balances in the app switcher preview when the app becomes inactive.
After the update, users returning from another app find their form exactly as they left it, and support complaints about lost input stop. The team also adds an automated test that simulates process death on every release.