App lifecycle for Windows App SDK desktop apps

This article describes the lifecycle of a Windows App SDK desktop app from launch through termination. Understanding the lifecycle helps you manage state, conserve resources, and deliver a smooth user experience.

Important

Unlike UWP apps, desktop apps (including WinUI 3) are not subject to the UWP process lifecycle management (PLM) model of automatic suspension and termination when backgrounded. They continue running until the user closes them or the process exits. However, a packaged desktop app is still subject to system-wide power and resource policies — for example, Modern Standby can suspend all user-mode processes (including your app) when the device sleeps, and Windows may apply Efficiency Mode (EcoQoS) to throttle CPU priority and quality of service for background or minimized apps. Your app should still handle unexpected shutdowns gracefully (for example, power loss, OS updates, or the user ending the process through Task Manager) and shouldn't assume it always has full-speed CPU access while backgrounded.

Lifecycle overview

A Windows App SDK desktop app has a simpler lifecycle than UWP:

State	Description
Not running	The app process has not started.
Running	The app is active. It may or may not have a visible window.
Closed	The user (or system) ended the process.

Because there is no suspended state, you do not need to handle Suspending or Resuming events the way UWP apps do. Instead, focus on:

• Saving user state when the window closes or the app shuts down.
• Handling activation (launch, file, protocol, or other activation kinds).
• Managing background work efficiently to conserve battery on portable devices.

App launch

When a user starts your app, the Microsoft.UI.Xaml.Application.OnLaunched method runs. Use it to initialize your main window and navigate to your first page.

public partial class App : Microsoft.UI.Xaml.Application
{
    private Microsoft.UI.Xaml.Window? m_window;

    protected override void OnLaunched(Microsoft.UI.Xaml.LaunchActivatedEventArgs args)
    {
        m_window = new MainWindow();
        m_window.Activate();
    }
}

// MainWindow is the window class generated by the WinUI 3 project
// template (MainWindow.xaml / MainWindow.xaml.cs).
public partial class MainWindow : Microsoft.UI.Xaml.Window
{
}

Note

Windows App SDK desktop apps do not receive a PreviousExecutionState value from the system. If you need to restore state after a crash or unexpected termination, implement your own state-persistence mechanism (for example, save state to a local file on a timer or when important actions complete).

App activation

Windows App SDK provides rich activation support through the Microsoft.Windows.AppLifecycle namespace. Your app can be activated by:

• Default launch — The user selects your app icon.
• File activation — The user opens a file type associated with your app.
• Protocol activation — A URI scheme registered to your app is invoked.
• Startup activation — Your app registers to start at user logon.
• Other — Toast notification, share target, and additional activation kinds.

Use AppInstance.GetActivatedEventArgs to determine the activation kind:

using Microsoft.Windows.AppLifecycle;

var activatedArgs = AppInstance.GetCurrent().GetActivatedEventArgs();

switch (activatedArgs.Kind)
{
    case ExtendedActivationKind.File:
        var fileArgs = activatedArgs.Data as
            Windows.ApplicationModel.Activation.IFileActivatedEventArgs;
        // Handle the file
        break;

    case ExtendedActivationKind.Protocol:
        var protocolArgs = activatedArgs.Data as
            Windows.ApplicationModel.Activation.IProtocolActivatedEventArgs;
        // Handle the URI
        break;

    case ExtendedActivationKind.Launch:
    default:
        // Standard launch
        break;
}

Packaged apps register for file and protocol activation through Package.appxmanifest. Unpackaged apps have no manifest, so they register the same activation kinds in code using Microsoft.Windows.AppLifecycle.ActivationRegistrationManager. For a detailed walkthrough of both approaches, see App activation for Windows App SDK.

Running in background and foreground

Desktop apps continue running whether or not they are in the foreground. The system does not stop your threads or reclaim your memory when the user switches to another app. However, you can still respond to visibility changes to optimize resource usage:

• Release expensive GPU or rendering resources when your window is minimized.
• Pause animations or media preview when the window loses focus.
• Reduce timer frequency for background polling.

Microsoft.UI.Xaml.Window doesn't expose a VisibilityChanged event. Instead, use the Window.Activated event to detect when your window gains or loses focus, or use AppWindow.Changed to detect changes to presenter state (such as minimized or restored):

// m_window is the field declared on your App type (see "App launch" above).
Microsoft.UI.Xaml.Window m_window = this;

m_window.Activated += (sender, args) =>
{
    if (args.WindowActivationState == WindowActivationState.Deactivated)
    {
        // Window lost focus — consider reducing work,
        // for example pausing animations or media preview
    }
    else
    {
        // Window is active — resume normal work
    }
};

// To specifically detect minimize/restore, use AppWindow.Changed
var appWindow = m_window.AppWindow;
appWindow.Changed += (sender, args) =>
{
    if (args.DidPresenterChange)
    {
        if (sender.Presenter is OverlappedPresenter presenter &&
            presenter.State == OverlappedPresenterState.Minimized)
        {
            // Window is minimized — pause expensive rendering
        }
        else
        {
            // Window is restored — resume rendering
        }
    }
};

Tip

On battery-powered devices, reducing background work when your app is not visible improves battery life and system responsiveness, even though the system does not enforce suspension.

Saving state

Because desktop apps are not suspended, you control when to save state. Recommended approaches:

• On window close — Handle the Window.Closed event to persist data.
• Periodic save — Use a timer to save state at intervals (for example, every 60 seconds).
• On important actions — Save after the user completes a significant action (for example, finishing an edit).

// m_window is the field declared on your App type (see "App launch" above).
Microsoft.UI.Xaml.Window m_window = this;

m_window.Closed += (sender, args) =>
{
    SaveApplicationState();
};

// Replace with your own logic to persist app state.
void SaveApplicationState() { }

App close and termination

A desktop app terminates when:

• The user closes the last window.
• Your code calls Application.Current.Exit().
• The process is ended externally (Task Manager, system shutdown).

There is no "terminated by the system to free resources" state as in UWP. Your app runs until it explicitly exits.

Note

If your app crashes, it restarts from scratch. Implement periodic state saving to minimize data loss.

Differences from UWP app lifecycle

Behavior	UWP	Windows App SDK (Desktop)
Automatic suspension (PLM)	Yes — after a few seconds in background	No — but the whole device can still enter Modern Standby
System termination to free memory	Yes — suspended apps may be terminated	No
Suspending / Resuming events	Yes	Not applicable
Prelaunch	Yes (opt-in)	No
Background state enforced	Yes	No — but Efficiency Mode (EcoQoS) may throttle backgrounded apps
State restoration after termination	Required for good UX	Optional — implement your own

Related content

• App activation for Windows App SDK
• Manage memory in your desktop app
• Multi-instance apps
• Rich activation in the Windows App SDK
• App instancing in the Windows App SDK