Learn about the lifecycle of a Windows Store app, from the time it is deployed through its removal. By working with Windows to suspend and resume your app appropriately, you ensure that your customer has the best possible experience with your app.
App deployment
Users acquire your app from the Windows Store as an app package. App packages have the file extension .appx. Each package contains a manifest and the files that constitute the app. The package manifest describes the app, and is used by Windows when it installs and removes the app.
The package manifest can also specify whether the app requires programmatic access to protected resources or connected devices. Customers can have confidence that your app can't access these system resources or the files in their libraries unless they approve this access. See App capability declarations.
For more info, see App packages and deployment.
App execution state
This illustration represents the transitions between app execution states. The next several sections of this page describe these states and events. For more detail about when each state transition occurs and what your app should do in response, see the docs for the ApplicationExecutionState enumeration.
App launch
An app is launched whenever it is activated by the user but the process is in the NotRunning state, because it was just deployed, it crashed, or it was suspended but could not be kept in memory.
When an app is launched, Windows displays a splash screen for the app. To configure this splash screen, see Adding a splash screen.
While its splash screen is displayed, an app should ensure that it's ready for its user interface to be displayed to the user. The primary tasks for the app are to register event handlers and set up any custom UI it needs for loading. These tasks should only take a few seconds. If an app needs to request data from the network or needs to retrieve large amounts of data from disk, these activities should be completed outside of activation. An app can use its own custom loading UI or an extended splash screen while it waits for these long running operations to finish. See the Extended Splash Screen documentation and Splash screen sample for more details. After the app completes activation, it enters the Running state and the splash screen is torn down. Showing a window, returning from the activation handler, and completing a deferral are specific ways that an app completes activation. For more info, see:
App activation
An app can be activated by the user through a variety of contracts and extensions. To participate in activation, your app must register to receive the Activated | activated event. Your app's activation event handler can test to see why it was activated and whether it was already in the Running state. Apps can be activated as follows.
| Activation type | Description |
|---|---|
| cached file | The user wants to save a file that your app provides content management for. |
| camera | The user wants to capture photos or video from an attached camera. |
| contact picker | The user wants to pick contacts. |
| device | The user wants your app to handle AutoPlay. |
| file | A user's app launched a file whose file type your app is registered to handle. |
| file open picker | The user wants to pick files or folders that are provided by your app. |
| file save picker | The user wants to save a file and has selected your app. |
| launch | The user launched your app or tapped a content tile. |
| print task | The user wants your app to handle print tasks. |
| protocol | A user's app launched a URL whose protocol your app is registered to handle. |
| search | The user wants to search with your app. |
| share target | The user wants your app to be target for a share operation. |
Your app can use activation to restore previously saved data in the event that Windows terminates your app, and subsequently the user re-launches it. Windows may terminate your app after it has been suspended for a number of reasons. The user may manually close your app, or sign out, or the system may be running low on resources. If the user launches your app after Windows has terminated it, it receives an activated event and the user sees the splash screen of your app until the app is activated. You can use this event to determine whether your app needs to restore the data which it had saved when it was last suspended, or whether you must load your app’s default data. The activated event arguments include a PreviousExecutionState property that tells you which state your app was in before it was activated. This property is one of the values from the ApplicationExecutionState enumeration. The table below summarizes the possibilities:
| Reason for termination | Value of PreviousExecutionState property | Action to take |
|---|---|---|
| Terminated by the system (for example, because of resource constraints) | Terminated | Restore session data |
| Closed by the user | ClosedByUser | Start with default data |
| Unexpectedly terminated, or app has not run since the user’s session started | NotRunning | Start with default data |
PreviousExecutionState could also have a value of Running or Suspended, but in these cases your app was not previously terminated and therefore you don’t have to worry about restoring data.
Note that if you log on using the computer's Administrator account, you can't activate any Windows Store apps.
For more info, see App extensions.
App suspend
An app can be suspended when the user switches away from it or when Windows enters a low power state. Most apps stop running when the user switches away from them.
When the user moves an app to the background, Windows waits a few seconds to see whether the user immediately switches back to the app. If the user does not switch back, Windows suspends the app.
If an app has registered an event handler for the Suspending | suspending event, this event handler is called right before the app is suspended. You can use the event handler to save relevant app and user data to persistent storage. We recommended that you use the application data APIs for this purpose because they are guaranteed to complete before the app enters the Suspended state. For more info, see Application data. You should also release exclusive resources and file handles so that other apps can access them while your app isn't using them.
Generally, your app should save its state and release its exclusive resources and file handles immediately in the event handler when the suspending event is received, and generally take about a second to do so. If an app does not return from the suspending event within 5 seconds, Windows assumes that the app has stopped responding and terminates it.
Windows attempts to keep as many suspended apps in memory as possible. By keeping these apps in memory, Windows ensures that users can quickly and reliably switch between suspended apps. However, if there aren't enough resources to keep your app in memory, Windows can terminate your app. Note that apps don't receive notification that they are being terminated, so the only opportunity you have to save your app's data is during suspension. When an app determines that it is activated after being terminated, it should load the application data that it saved during suspend so that the app appears as it did when it was suspended.
There are some apps that need to continue to run to complete background tasks. Your app can continue to play audio in the background; for more info, see Quickstart: Adding audio in a Windows Store app. Background transfer operations continue even if your app is suspended or even terminated; for more info, see Quickstart: Downloading a file.
For guidelines, see Guidelines for app suspend and resume.
For example code, see:
App visibility
When the user switches from your app to another app, your app is no longer visible but remains in the running state until Windows can suspend it (for about 10 seconds). If the user switches away from your app but activates or switches back to it before Windows can suspend it, the app remains in the running state.
Your app doesn't receive an activation event when app visibility changes, because the app is still running. Windows simply switches to and from the app as necessary. If your app needs to do something when the user switches away and back, it can handle the VisibilityChanged | msvisibilitychange event.
The visibility event is not serialized with the resume or activation events. Don't assume that these events come in a particular order.
App resume
A suspended app is resumed when the user switches to it or when Windows comes out of a low power state.
For an enumeration of the states that your app can be in when your app is resumed, see ApplicationExecutionState. When an app is resumed from the Suspended state, it enters the Running state and continues from where it was when it was suspended. No application data is lost, as it was stored in memory. Therefore, most apps don't need to do anything when they are resumed. However, the app could have been suspended for hours or even days. So if your app has content or network connections that may have gone stale, these should be refreshed when the app resumes. If an app registered an event handler for the Resuming | resuming event, it is called when the app is resumed from the Suspended state. You can refresh your content using this event handler.
If a suspended app is activated to participate in an app contract or extension, it receives the Resuming | resuming event first, then the Activated | activated event.
When an app is suspended, it does not receive network events that it registered to receive. These events are not queued, they are simply missed. Therefore, your app should test the network status when it is resumed.
For guidelines, see Guidelines for app suspend and resume.
For example code, see:
App close
Generally, users don't need to close apps, they can let Windows manage them. However, users can choose to close an app using the close gesture or by pressing Alt+F4. You can't include any UI in your app to enable the user to close your app, or it won't pass the Store certification process.
There's no special event to indicate that the user has closed an app. After an app has been closed by the user, it's suspended and terminated, entering the NotRunning state within about 10 seconds. If an app has registered an event handler for the Suspending | suspending event, it is called when the app is suspended. You can use this event handler to save relevant application and user data to persistent storage.
You should decide how your app behaves when it's activated after being closed by the user. It may make no difference to you whether the app was terminated by Windows or by the user. If your app needs to do something different when it is closed by the user than when it is closed by Windows, the activation event handler can determine whether the app was terminated by the user or by Windows. See the descriptions of ClosedByUser and Terminated states in the docs for the ApplicationExecutionState enumeration.
Apps shouldn't close themselves programmatically unless absolutely necessary. For example, if an app detects a memory leak, it can close itself to ensure the security of the user's personal data. When you close an app programmatically, Windows treats this as an app crash.
App crash
Apps are required to follow the system crash experience, which is to simply return to the Start screen. The system crash experience is designed to get users back to what they were doing as quickly as possible, so you shouldn't provide a warning dialog or other notification because that'll cause a delay for the user. The disappearance of the app should make it clear to the user that something went wrong.
If your app crashes, stops responding, or generates an exception, Windows asks the user for consent to send a problem report to Microsoft. Microsoft provides a subset of the error data in the problem report to you so that you can use it to improve your app. You'll be able to see this data in your app's Quality page in your Dashboard in the Windows Dev Center for Windows Store apps. (Note that you can't submit apps or view your app's data until the Windows Store opens for general submissions.)
When the user activates an app after it crashes, its activation event handler receives an ApplicationExecutionState value of NotRunning, and should simply display its initial UI and data.
App removal
When a user deletes your app, the app is removed, along with all its local data. Removing an app doesn't affect the user's data, such as files in the Documents or Pictures libraries.
Application lifecycle programming interfaces
- Windows.ApplicationModel namespace
- Windows.ApplicationModel.Activation namespace
- Windows.ApplicationModel.Core namespace
- Windows.UI.WebUI namespace
- Windows.UI.Xaml.Application class
- Windows.UI.Xaml.Window class
- WinJS.Application namespace
Related topics
- Guidelines for app suspend and resume
- Samples
- App activated, resume, and suspend using the WRL sample
Build date: 11/27/2012
