UWP Application Lifecycle

Analogy categoryAnalogies

Because UWP devices, especially phones, tablets, and even multitasking desktops, have limited RAM and battery, Windows manages a UWP app's process lifecycle far more aggressively than a classic Win32 desktop app: instead of running indefinitely in the background once launched, a UWP app can be suspended (frozen in memory, no CPU time, but state intact) within seconds of losing foreground focus, and later silently terminated to reclaim memory if the OS needs it for something else. Understanding the lifecycle states, NotRunning, Activating, Running, Suspended, and effectively Terminated, and their associated events is essential because failing to save state in the roughly 5-second Suspending window is one of the most common causes of UWP apps losing user data.

🏏

Cricket analogy: Like a bowler being given a strict over limit before the captain must bring on a change, a UWP app is given only a brief Suspending window, roughly 5 seconds, before Windows freezes it whether or not it finished saving state.

From NotRunning to Running: Launch, Activation, and Prelaunch

A UWP app starts in the NotRunning state; when the user taps its tile (or it's activated via a protocol/file association), Windows moves it through Activating and calls OnLaunched, where the ExecutionState property on the LaunchActivatedEventArgs (via e.PreviousExecutionState) tells the app whether the previous session ended in Terminated, ClosedByUser, or another state, letting it decide whether to restore saved navigation and data state. Since Windows 10 version 1607, Windows can also Prelaunch an app in the background (OnLaunched fires with e.PrelaunchActivated equal to true) before the user even taps its tile, based on usage pattern prediction, so the app can warm up its Frame and initial data without the user ever seeing a slow cold start.

🏏

Cricket analogy: Like a team warming up in the nets based on the schedule before they're actually called out to bat, prelaunch activation lets Windows warm up an app's Frame in the background, via e.PrelaunchActivated, before the user actually taps its tile.

Suspending, Resuming, and the SuspendingDeferral

When the app loses foreground focus and Windows decides to reclaim its CPU time, it fires the Suspending event on the Application object; because the handler runs asynchronously and Windows needs a signal for when it's actually safe to freeze the process, the handler must call args.SuspendingOperation.GetDeferral() before doing any async work like writing to a file, and call Complete() on that deferral when finished, or Windows may freeze the process mid-save. If the app is brought back to the foreground while still frozen in memory (never terminated), Windows fires the Resuming event instead of re-running OnLaunched, since the process and its in-memory state were never actually torn down.

🏏

Cricket analogy: Like a captain calling for a drinks break and needing the umpire's explicit signal before play can safely pause, a Suspending handler must call GetDeferral() and get Windows' explicit acknowledgment before it's safe to pause the app mid-save.

csharp

public App()
{
    this.InitializeComponent();
    this.Suspending += OnSuspending;
    this.Resuming += OnResuming;
}

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
    var deferral = e.SuspendingOperation.GetDeferral();
    try
    {
        await SaveApplicationStateAsync();
    }
    finally
    {
        deferral.Complete();
    }
}

private void OnResuming(object sender, object e)
{
    // Process was never terminated; in-memory state is still intact.
    RefreshTimeSensitiveDataIfNeeded();
}

Termination and Restoring State

Crucially, there is no Terminated event: if Windows needs to reclaim memory from a suspended app, it simply ends the process silently with no callback, so the only reliable signal an app gets is the absence of a Resuming event on the next activation and, in OnLaunched, an e.PreviousExecutionState value of ApplicationExecutionState.Terminated. A well-behaved UWP app therefore treats every OnLaunched call as a potential coming-back-from-termination scenario, checking PreviousExecutionState and restoring from whatever state it persisted (commonly via ApplicationData.Current.LocalSettings or a serialized file) during its last Suspending event, rather than assuming Running always continues where the user left off.

🏏

Cricket analogy: Like a rain-abandoned match simply ending with no formal announcement beyond the scoreboard going dark, a UWP app's termination happens silently with no event, leaving PreviousExecutionState as the only after-the-fact clue it happened.

There is no Terminated event in UWP — a suspended app that Windows decides to kill for memory just disappears with no callback. The only way to detect this after the fact is checking ApplicationExecutionState.Terminated on e.PreviousExecutionState inside the next OnLaunched call, which is why every UWP app should persist meaningful state during Suspending, never assume it will get a chance to save on exit.

Lifecycle states: NotRunning, Activating, Running, Suspended, and (silently) Terminated.
OnLaunched receives e.PreviousExecutionState to detect whether the app is resuming after termination.
Prelaunch (e.PrelaunchActivated) lets Windows warm up an app's Frame before the user taps its tile.
The Suspending event must call GetDeferral(), do async save work, then Complete() within roughly 5 seconds.
Resuming (not OnLaunched) fires if a suspended-but-not-terminated app returns to the foreground.
There is no Terminated event — apps must always be ready to restore state on the next OnLaunched.