How to launch the default app for a URI (XAML)

08/31/2015

7 minutes to read

In this article

Learn how to launch the default app for a Uniform Resource Identifier (URI). URIs allow you to launch another app on the operating system to perform a specific task. For example, if you want to allow the user to send a mail to a contact in your app, you can use the mailto: URI to launch the user’s default e-mail app.

In some cases, the user might not have an app installed to handle the URI that you are launching. By default, the operating system handles these cases by providing the user with a link to search for an appropriate app on the store. If you want to give the user a specific recommendation for which app to acquire in this scenario, you can do so by passing that recommendation along with the URI that you are launching. To do this, call the Windows.System.Launcher.LaunchUriAsync(Uri, LauncherOptions) method with LauncherOptions.preferredApplicationPackageFamilyName set to the package family name of the app in the store that you want to recommend. Then, set the LauncherOptions.preferredApplicationDisplayName to the name of that app. The operating system uses this info to replace the general option to search for an app in the store with a specific option to acquire the recommended app from the store.

Note you must set both of these options to recommend an app. Setting one without the other will result in a failure.

Source apps that call LaunchUriAsync can request that they remain on screen after a URI launch. By default, Windows attempts to share all available space equally between the source app and the target app that handles the URI. Source apps can use the DesiredRemainingView property to indicate to the operating system that they prefer their app window to take up more or less of the available space. DesiredRemainingView can also be used to indicate that the source app doesn't need to remain on screen after the URI launch and can be completely replaced by the target app. This property only specifies the preferred window size of the calling app. It doesn't specify the behavior of other apps that may happen to also be on screen at the same time.

Note Windows takes into account multiple different factors when it determines the source app's final window size, for example, the preference of the source app, the number of apps on screen, the screen orientation, and so on. By setting DesiredRemainingView, you aren't guaranteed a specific windowing behavior for the source app.

Remarks

Your app can't select the app that is launched. The user determines which app is launched. The user can select either a Windows Runtime app or a desktop app.

When launching a URI, your app must be the foreground app, that is, it must be visible to the user. This requirement helps ensure that the user remains in control. To meet this requirement, make sure that you tie all URI launches directly to the UI of your app. The user must always take some action to initiate a URI launch. If you attempt to launch a URI and your app isn't in the foreground, the launch will fail and your error callback will be invoked.

You must specify the privateNetworkClientServer capability in order to launch intranet URIs, for example, a file:/// URI that points to a network location.

You can't use this method to launch a URI in the local zone. For example, apps can't use the file:/// URI to access files on the local device. Instead, you must use the Storage APIs to access files. If you attempt to launch an intranet URI without the correct capability or a local zone URI, the launch will fail and your error callback will be invoked.