.NET MAUI App Lifecycle
Handle application state transitions correctly in .NET MAUI. This skill covers the cross-platform Window lifecycle events, their platform-native mappings, and patterns for preserving state across backgrounding and resume cycles.
When to Use
- Saving or restoring state when the app backgrounds or resumes
- Subscribing to Window lifecycle events (Created, Activated, Deactivated, Stopped, Resumed, Destroying)
- Hooking into platform-native lifecycle callbacks via
ConfigureLifecycleEvents
- Deciding where to place initialization, teardown, or refresh logic
- Understanding the difference between Deactivated and Stopped
When Not to Use
- Page-level navigation events — use Shell navigation guidance instead
- Registering services at startup — use dependency injection guidance instead
- Calling platform-specific APIs outside lifecycle context — use platform invoke guidance instead
Inputs
- The target lifecycle transition (e.g., "save draft when backgrounded", "refresh data on resume")
- Which platforms the developer targets (Android, iOS, Mac Catalyst, Windows)
- Whether the app uses multiple windows (iPad, Mac Catalyst, desktop Windows)
App States
A .NET MAUI app moves through four states:
| State |
Description |
| Not Running |
Process does not exist |
| Running |
Foreground, receiving input |
| Deactivated |
Visible but lost focus (dialog, split-screen, notification shade) |
| Stopped |
Fully backgrounded, UI not visible |
Typical flow: Not Running → Running → Deactivated → Stopped → Running (resumed) or Not Running (terminated).
Window Lifecycle Events
Microsoft.Maui.Controls.Window exposes six cross-platform events:
| Event |
Fires when |
Created |
Native window allocated |
Activated |
Window receives input focus |
Deactivated |
Window loses focus (may still be visible) |
Stopped |
Window is no longer visible |
Resumed |
Window returns to foreground after Stopped |
Destroying |
Native window is being torn down |
Subscribing via CreateWindow
Override CreateWindow in your App class and attach event handlers:
public partial class App : Application
{
protected override Window CreateWindow(IActivationState? activationState)
{
var window = base.CreateWindow(activationState);
window.Created += (s, e) => Debug.WriteLine("Created");
window.Activated += (s, e) => Debug.WriteLine("Activated");
window.Deactivated += (s, e) => Debug.WriteLine("Deactivated");
window.Stopped += (s, e) => Debug.WriteLine("Stopped");
window.Resumed += (s, e) => Debug.WriteLine("Resumed");
window.Destroying += (s, e) => Debug.WriteLine("Destroying");
return window;
}
}
Subscribing via a Custom Window Subclass
Create a Window subclass and override the virtual methods:
public class AppWindow : Window
{
public AppWindow(Page page) : base(page) { }
protected override void OnActivated() { /* refresh UI */ }
protected override void OnStopped() { /* save state */ }
protected override void OnResumed() { /* restore state */ }
protected override void OnDestroying() { /* cleanup */ }
}
Return it from CreateWindow:
protected override Window CreateWindow(IActivationState? activationState)
=> new AppWindow(new AppShell());
Workflow: Save and Restore State on Background
- Identify transient state — draft text, scroll position, form inputs, timer values.
- Save in
OnStopped — use Preferences for small values or file serialization for larger state.
- Restore in
OnResumed — read back saved values and apply to your view model.
- Also save in
OnDestroying on Android — the back button can skip Stopped entirely.
- Keep handlers fast — complete within 1–2 seconds to avoid ANR on Android or watchdog kills on iOS.
protected override void OnStopped()
{
base.OnStopped();
Preferences.Set("draft_text", _viewModel.DraftText);
Preferences.Set("scroll_y", _viewModel.ScrollY);
}
protected override void OnResumed()
{
base.OnResumed();
_viewModel.DraftText = Preferences.Get("draft_text", string.Empty);
_viewModel.ScrollY = Preferences.Get("scroll_y", 0.0);
}
protected override void OnDestroying()
{
base.OnDestroying();
// Android back-button can skip Stopped
Preferences.Set("draft_text", _viewModel.DraftText);
}
Platform Lifecycle Mapping
Android
| Window Event |
Android Callback |
| Created |
OnCreate |
| Activated |
OnResume |
| Deactivated |
OnPause |
| Stopped |
OnStop |
| Resumed |
OnRestart → OnStart → OnResume |
| Destroying |
OnDestroy |
iOS / Mac Catalyst
| Window Event |
UIKit Callback |
AddiOS builder method |
| Created |
WillFinishLaunching / SceneWillConnect |
.WillFinishLaunching() / .SceneWillConnect() |
| Activated |
DidBecomeActive |
.OnActivated() |
| Deactivated |
WillResignActive |
.OnResignActivation() |
| Stopped |
DidEnterBackground |
.DidEnterBackground() |
| Resumed |
WillEnterForeground |
.WillEnterForeground() |
| Destroying |
WillTerminate |
.WillTerminate() |
⚠️ The UIKit selector names and the AddiOS builder method names differ for
activation. There is no .DidBecomeActive() or .WillResignActive() builder
method — use .OnActivated() and .OnResignActivation() or the code will not compile.
Windows (WinUI)
| Window Event |
WinUI Callback |
| Created |
OnLaunched |
| Activated |
Activated (foreground) |
| Deactivated |
Activated (background) |
| Stopped |
VisibilityChanged (false) |
| Resumed |
VisibilityChanged (true) |
| Destroying |
Closed |
Hooking Native Lifecycle Directly
Use ConfigureLifecycleEvents in MauiProgram.cs when you need platform-specific callbacks beyond what Window events provide:
builder.ConfigureLifecycleEvents(events =>
{
#if ANDROID
events.AddAndroid(android => android
.OnCreate((activity, bundle) => Debug.WriteLine("Android OnCreate"))
.OnResume(activity => Debug.WriteLine("Android OnResume"))
.OnPause(activity => Debug.WriteLine("Android OnPause"))
.OnStop(activity => Debug.WriteLine("Android OnStop"))
.OnDestroy(activity => Debug.WriteLine("Android OnDestroy")));
#elif IOS || MACCATALYST
events.AddiOS(ios => ios
.OnActivated(app => Debug.WriteLine("iOS OnActivated"))
.OnResignActivation(app => Debug.WriteLine("iOS OnResignActivation"))
.DidEnterBackground(app => Debug.WriteLine("iOS DidEnterBackground"))
.WillEnterForeground(app => Debug.WriteLine("iOS WillEnterForeground")));
#elif WINDOWS
events.AddWindows(windows => windows
.OnLaunched((app, args) => Debug.WriteLine("Windows OnLaunched"))
.OnActivated((window, args) => Debug.WriteLine("Windows Activated"))
.OnClosed((window, args) => Debug.WriteLine("Windows Closed")));
#endif
});
Common Pitfalls
Resumed does not fire on first launch. The initial sequence is Created → Activated. Use OnActivated for logic that must run on every foreground entry, not OnResumed.
Deactivated ≠ Stopped. A dialog, split-screen, or notification pull-down triggers Deactivated without Stopped. Do not perform heavy saves in OnDeactivated — the app may never actually background.
Android back button skips Stopped. On Android, pressing back may call Destroying directly without Stopped. Place critical save logic in both OnStopped and OnDestroying.
Multi-window apps fire events independently. On iPad, Mac Catalyst, and desktop Windows each Window instance fires its own lifecycle events. Do not assume a single global lifecycle.
Long-running handlers cause kills. Android enforces a ~5 second ANR timeout; iOS has limited background execution time. Keep lifecycle handlers synchronous and fast — use Preferences for quick saves, not database writes.
Do not use legacy Xamarin.Forms lifecycle methods. Application.OnStart(), Application.OnSleep(), and Application.OnResume() exist for backward compatibility but bypass Window-level events. In .NET MAUI, prefer Window lifecycle events (OnActivated, OnStopped, OnResumed, etc.) for correct multi-window behavior.
1---2name: maui-app-lifecycle3description: .NET MAUI app lifecycle guidance — the four app states, cross-platform Window lifecycle events (Created, Activated, Deactivated, Stopped, Resumed, Destroying), platform-specific lifecycle mapping, backgrounding and resume behavior, and state-preservation patterns. USE FOR: "app lifecycle", "window lifecycle events", "save state on background", "resume app", "OnStopped", "OnResumed", "backgrounding", "deactivated event", "ConfigureLifecycleEvents", "platform lifecycle hooks". DO NOT USE FOR: navigation events (use maui-shell-navigation), dependency injection setup (use maui-dependency-injection), platform API invocation (use conditional compilation and partial classes).4license: MIT5---6
7# .NET MAUI App Lifecycle
8
9Handle application state transitions correctly in .NET MAUI. This skill covers the cross-platform Window lifecycle events, their platform-native mappings, and patterns for preserving state across backgrounding and resume cycles.
10
11## When to Use
12
13- Saving or restoring state when the app backgrounds or resumes
14- Subscribing to Window lifecycle events (Created, Activated, Deactivated, Stopped, Resumed, Destroying)
15- Hooking into platform-native lifecycle callbacks via `ConfigureLifecycleEvents`
16- Deciding where to place initialization, teardown, or refresh logic
17- Understanding the difference between Deactivated and Stopped
18
19## When Not to Use
20
21- Page-level navigation events — use Shell navigation guidance instead
22- Registering services at startup — use dependency injection guidance instead
23- Calling platform-specific APIs outside lifecycle context — use platform invoke guidance instead
24
25## Inputs
26
27- The target lifecycle transition (e.g., "save draft when backgrounded", "refresh data on resume")
28- Which platforms the developer targets (Android, iOS, Mac Catalyst, Windows)
29- Whether the app uses multiple windows (iPad, Mac Catalyst, desktop Windows)
30
31## App States
32
33A .NET MAUI app moves through four states:
34
35| State | Description |
36|---|---|
37| **Not Running** | Process does not exist |
38| **Running** | Foreground, receiving input |
39| **Deactivated** | Visible but lost focus (dialog, split-screen, notification shade) |
40| **Stopped** | Fully backgrounded, UI not visible |
41
42Typical flow: Not Running → Running → Deactivated → Stopped → Running (resumed) or Not Running (terminated).
43
44## Window Lifecycle Events
45
46`Microsoft.Maui.Controls.Window` exposes six cross-platform events:
47
48| Event | Fires when |
49|---|---|
50| `Created` | Native window allocated |
51| `Activated` | Window receives input focus |
52| `Deactivated` | Window loses focus (may still be visible) |
53| `Stopped` | Window is no longer visible |
54| `Resumed` | Window returns to foreground after Stopped |
55| `Destroying` | Native window is being torn down |
56
57### Subscribing via CreateWindow
58
59Override `CreateWindow` in your `App` class and attach event handlers:
60
61```csharp
62public partial class App : Application
63{
64 protected override Window CreateWindow(IActivationState? activationState)
65 {
66 var window = base.CreateWindow(activationState);
67
68 window.Created += (s, e) => Debug.WriteLine("Created");
69 window.Activated += (s, e) => Debug.WriteLine("Activated");
70 window.Deactivated += (s, e) => Debug.WriteLine("Deactivated");
71 window.Stopped += (s, e) => Debug.WriteLine("Stopped");
72 window.Resumed += (s, e) => Debug.WriteLine("Resumed");
73 window.Destroying += (s, e) => Debug.WriteLine("Destroying");
74
75 return window;
76 }
77}
78```
79
80### Subscribing via a Custom Window Subclass
81
82Create a `Window` subclass and override the virtual methods:
83
84```csharp
85public class AppWindow : Window
86{
87 public AppWindow(Page page) : base(page) { }
88
89 protected override void OnActivated() { /* refresh UI */ }
90 protected override void OnStopped() { /* save state */ }
91 protected override void OnResumed() { /* restore state */ }
92 protected override void OnDestroying() { /* cleanup */ }
93}
94```
95
96Return it from `CreateWindow`:
97
98```csharp
99protected override Window CreateWindow(IActivationState? activationState)
100 => new AppWindow(new AppShell());
101```
102
103## Workflow: Save and Restore State on Background
104
1051. **Identify transient state** — draft text, scroll position, form inputs, timer values.
1062. **Save in `OnStopped`** — use `Preferences` for small values or file serialization for larger state.
1073. **Restore in `OnResumed`** — read back saved values and apply to your view model.
1084. **Also save in `OnDestroying`** on Android — the back button can skip `Stopped` entirely.
1095. **Keep handlers fast** — complete within 1–2 seconds to avoid ANR on Android or watchdog kills on iOS.
110
111```csharp
112protected override void OnStopped()
113{
114 base.OnStopped();
115 Preferences.Set("draft_text", _viewModel.DraftText);
116 Preferences.Set("scroll_y", _viewModel.ScrollY);
117}
118
119protected override void OnResumed()
120{
121 base.OnResumed();
122 _viewModel.DraftText = Preferences.Get("draft_text", string.Empty);
123 _viewModel.ScrollY = Preferences.Get("scroll_y", 0.0);
124}
125
126protected override void OnDestroying()
127{
128 base.OnDestroying();
129 // Android back-button can skip Stopped
130 Preferences.Set("draft_text", _viewModel.DraftText);
131}
132```
133
134## Platform Lifecycle Mapping
135
136### Android
137
138| Window Event | Android Callback |
139|---|---|
140| Created | `OnCreate` |
141| Activated | `OnResume` |
142| Deactivated | `OnPause` |
143| Stopped | `OnStop` |
144| Resumed | `OnRestart` → `OnStart` → `OnResume` |
145| Destroying | `OnDestroy` |
146
147### iOS / Mac Catalyst
148
149| Window Event | UIKit Callback | `AddiOS` builder method |
150|---|---|---|
151| Created | `WillFinishLaunching` / `SceneWillConnect` | `.WillFinishLaunching()` / `.SceneWillConnect()` |
152| Activated | `DidBecomeActive` | `.OnActivated()` |
153| Deactivated | `WillResignActive` | `.OnResignActivation()` |
154| Stopped | `DidEnterBackground` | `.DidEnterBackground()` |
155| Resumed | `WillEnterForeground` | `.WillEnterForeground()` |
156| Destroying | `WillTerminate` | `.WillTerminate()` |
157
158> ⚠️ The UIKit selector names and the `AddiOS` builder method names differ for
159> activation. There is **no** `.DidBecomeActive()` or `.WillResignActive()` builder
160> method — use `.OnActivated()` and `.OnResignActivation()` or the code will not compile.
161
162### Windows (WinUI)
163
164| Window Event | WinUI Callback |
165|---|---|
166| Created | `OnLaunched` |
167| Activated | `Activated` (foreground) |
168| Deactivated | `Activated` (background) |
169| Stopped | `VisibilityChanged` (false) |
170| Resumed | `VisibilityChanged` (true) |
171| Destroying | `Closed` |
172
173## Hooking Native Lifecycle Directly
174
175Use `ConfigureLifecycleEvents` in `MauiProgram.cs` when you need platform-specific callbacks beyond what Window events provide:
176
177```csharp
178builder.ConfigureLifecycleEvents(events =>
179{
180#if ANDROID
181 events.AddAndroid(android => android
182 .OnCreate((activity, bundle) => Debug.WriteLine("Android OnCreate"))
183 .OnResume(activity => Debug.WriteLine("Android OnResume"))
184 .OnPause(activity => Debug.WriteLine("Android OnPause"))
185 .OnStop(activity => Debug.WriteLine("Android OnStop"))
186 .OnDestroy(activity => Debug.WriteLine("Android OnDestroy")));
187#elif IOS || MACCATALYST
188 events.AddiOS(ios => ios
189 .OnActivated(app => Debug.WriteLine("iOS OnActivated"))
190 .OnResignActivation(app => Debug.WriteLine("iOS OnResignActivation"))
191 .DidEnterBackground(app => Debug.WriteLine("iOS DidEnterBackground"))
192 .WillEnterForeground(app => Debug.WriteLine("iOS WillEnterForeground")));
193#elif WINDOWS
194 events.AddWindows(windows => windows
195 .OnLaunched((app, args) => Debug.WriteLine("Windows OnLaunched"))
196 .OnActivated((window, args) => Debug.WriteLine("Windows Activated"))
197 .OnClosed((window, args) => Debug.WriteLine("Windows Closed")));
198#endif
199});
200```
201
202## Common Pitfalls
203
2041. **Resumed does not fire on first launch.** The initial sequence is `Created` → `Activated`. Use `OnActivated` for logic that must run on every foreground entry, not `OnResumed`.
205
2062. **Deactivated ≠ Stopped.** A dialog, split-screen, or notification pull-down triggers `Deactivated` without `Stopped`. Do not perform heavy saves in `OnDeactivated` — the app may never actually background.
207
2083. **Android back button skips Stopped.** On Android, pressing back may call `Destroying` directly without `Stopped`. Place critical save logic in both `OnStopped` and `OnDestroying`.
209
2104. **Multi-window apps fire events independently.** On iPad, Mac Catalyst, and desktop Windows each `Window` instance fires its own lifecycle events. Do not assume a single global lifecycle.
211
2125. **Long-running handlers cause kills.** Android enforces a ~5 second ANR timeout; iOS has limited background execution time. Keep lifecycle handlers synchronous and fast — use `Preferences` for quick saves, not database writes.
213
2146. **Do not use legacy Xamarin.Forms lifecycle methods.** `Application.OnStart()`, `Application.OnSleep()`, and `Application.OnResume()` exist for backward compatibility but bypass Window-level events. In .NET MAUI, prefer `Window` lifecycle events (`OnActivated`, `OnStopped`, `OnResumed`, etc.) for correct multi-window behavior.