Windows desktop applications
Collapse the table of content
Expand the table of content
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Guidelines for app suspend and resume

Design your app to suspend when the user switches away from it and resume when the user switches back to it. Carefully consider the purpose and usage patterns of your app to ensure that your user has the best experience possible when your app is suspended and resumed. Follow these guidelines when you design the suspend and resume behavior of your Universal Windows Platform (UWP) app.

For a summary of the lifecycle of a UWP app, see App lifecycle.

Note  To improve system responsiveness in Windows 8.1 and Windows Phone 8.1 and later, apps are given low priority access to resources after they are suspended. To support this new priority, the suspend operation timeout is extended so that the app has the equivalent of the 5-second timeout for normal priority on Windows and a range of 1 to 10 seconds on Windows Phone. You cannot extend or alter this timeout window.

Dos and don'ts

  • When resuming after a short period of time, return users to the state the app was in when the user left. For example, if a user navigates to another app before finishing an email, the user should be returned to the page with their unfinished email instead of the mail app's main landing page.
  • When resuming after a long period of time, return users to your app's default landing page. For example, return a user to the main landing page of your news or weather app instead of returning them to an old, stale article or displaying outdated weather data.
  • If appropriate, allow users to choose whether they want to restore their app to its previous state or start fresh. For example, when the user switches back to your game app, you could display a prompt so the user can decide whether to resume the game or start a new one.
  • Save app data when the app is being suspended. Suspended apps don't receive notification when the system terminates them, so it is important to explicitly save app data to ensure that app state can be restored.

    If your app supports multiple launch points such as secondary tiles, and toast notifications, and File and URI associations, you should consider creating a separate navigation history for each launch point. When suspending, save the state associated with the primary launch point, and only save the state for secondary launch points in scenarios where it would frustrate the user to lose state. Saving too much state can cause the app to be slow to resume.

  • Use saved app data to restore your app.
  • Release exclusive resources and file handles when the app is being suspended. As stated earlier, suspended apps aren't notified when they're terminated, so make sure to release resources and handles (like webcams, I/O devices, external devices, and network resources) when your app is suspended to ensure that other apps can access them.
  • Update the UI if content has changed since it was last visible to the user. Your resumed app should look as if it was running while the user was away.
  • Don't terminate the app when the user navigates away from the app or closes the app using the close button. The operating system ensures that there is a consistent way for the user to access and manage apps. Your app is suspended when it is no longer visible to the user. By leaving the application lifecycle to the system, you ensure that your user can return to your app as efficiently as possible. Doing so also provides the best system performance and battery life from the device.
  • Don't restore state for an app that was explicitly terminated by the user. The user may have closed the app because it got into an unrecoverable state. If your app was explicitly closed by the user, provide a fresh experience rather than a resume experience. When the app was closed by the user, the PreviousExecutionState property will have the value ClosedByUser.
  • Don't restore state for an app that was terminated as the result of a crash. If your app was terminated unexpectedly, assume that stored app data is possibly corrupt. The app should not try to restore to its previous state using this stored data.
  • Don't include Close buttons or offer users other ways to terminate your app in its UI. Users should feel confident that the system is managing their apps for them. The system can terminate apps automatically to ensure the best system performance and reliability, and users can choose to close apps using gestures on Windows or through the Task Switcher on Windows Phone.
  • Don't strand users on deep-linked pages. When the user launches your app from a launch point other than the primary tile, landing on a deep-linked page, provide UI to allow the user to navigate to the app's top page. Or, allow the user to get to the top page by tapping the primary tile.
  • For some applications it makes sense to always return the user to the top of the app if it is launched from the primary tile but not when the user returns to the app by using the task switcher. If you need to tell the difference between these two scenarios, check LaunchActivatedEventArgs.PreviousExecutionState and if it is Terminated, check LaunchActivatedEventArgs.TileId. If TileID == “” then your app came back from termination via the task switcher because the user switched to it. In all other cases the user launched your app from a tile.

Related topics

For developers (XAML)
App lifecycle
Handle app suspend
Handle app resume
App activated, resume, and suspend using the WRL sample
App activate and suspend using WinJS sample
Getting Started with C# and VB: Hello World samples (Part 2)



© 2016 Microsoft