App capability declarations

Which kinds of apps do app capabilities apply to?

Most scenarios for app capabilities are relevant only to apps that have package identity, and that run in an AppContainer. All UWP apps meet those criteria; so capabilities apply to them. But you can also give a desktop app package identity, and configure it as an AppContainer app. So capabilities apply to some desktop apps, too.

• For more info about packaging and package identity, see Deployment overview.
• For more info about AppContainer apps, see AppContainer for legacy apps.

A desktop app that's an AppContainer app can be identified by uap10:TrustLevel="appContainer" in its app package manifest (for more info, see Application (Windows 10)). Similarly, a desktop app with mediumIL (an integrity level of medium) has uap10:TrustLevel="mediumIL". Medium IL apps—which are also known as full trust apps—don't run in an AppContainer.

The internetClient and enterpriseAuthentication capabilities grant an application the ability to perform certain operations that the user can already do. So those are examples of capabilities that apply only to AppContainer apps. Conversely, a Medium IL app is already running as the user; so an app like that can already perform those operations without requiring those capabilities.

But there are some scenarios where a Medium IL app should declare a capability, too. In fact, a Medium IL app needs to declare the runFullTrust restricted capability. And, to be able to register out-of-process COM servers for inter-process communication (IPC), a packaged app needs runFullTrust. That feature is known as Packaged COM (for more info, see the blog post COM Server and OLE Document support for the Desktop Bridge).

For info about another scenario that applies even to Medium IL apps, see Privacy-sensitive capabilities in this topic.

You can determine whether your app package manifest needs runFullTrust simply by building your package. Makeappx.exe will validate the schema, and if runFullTrust isn't declared but something needs it, then you'll see a detailed error message including what the problem is, together with line and column numbers.

Declaring capabilities

If you want to access certain APIs or resources (such as pictures or music), or devices (such as the camera or the microphone), then you must declare the appropriate app capabilities in your Windows app's package manifest

You can declare general capabilities by using the Manifest Designer in Visual Studio; or you can add them manually. For more info, see How to specify capabilities in a package manifest. It's important to know that when customers get your app from the Microsoft Store, they're notified of all the capabilities that the app declares. So be sure to declare only the capabilities that your app needs.

Privacy-sensitive capabilities

A sensitive resource is a resource that can access the user's personal data, or cost the user money. In this topic, capabilities that provide apps with access to a sensitive resource are annotated by an asterisk (*) in the Capability scenario column.

Privacy-sensitive capabilities signal to the operating system (OS)—and to the user—what the app intends to do. Since it's good to send this signal to the users of your app, we recommend that you declare privacy-sensitive capabilities even for Medium IL apps (where the application identity is used to provide individual privacy toggles). Doing so allows those apps to be managed in the privacy settings pages (managed by Windows Settings) as soon as they're installed; as opposed to later, when they access privacy-sensitive resources.

Those privacy settings let the user dynamically control access to sensitive resources. Thus, it's important that your app doesn't assume that a sensitive resource is always available. For more info about accessing sensitive resources, see Security.

Different kinds of capabilities

There are several kinds of capabilities.

• General-use capabilities, which apply to most common app scenarios.
• Device capabilities, which allow your app to access internal and peripheral devices.
• Restricted capabilities, which require approval for Microsoft Store submission and/or are generally only available to Microsoft and certain partners.
• Custom capabilities.

General-use capabilities

General-use capabilities are specified by using Capability elements in your app package manifest. These capabilities apply to the most common app scenarios.

Device capabilities

Device capabilities allow your app to access peripheral and internal devices. Device capabilities are specified by using DeviceCapability elements in your app package manifest. This element may require additional child elements and some device capabilities need to be added to the package manifest manually. For more info, see How to specify device capabilities in a package manifest and DeviceCapability Schema reference.

Restricted capabilities

If your app declares any restricted capabilities, then you must provide info during the app submission process in order to be approved to publish your app to the Microsoft Store. You provide this info on the Submission options page of your submission, explaining how your app uses each restricted capability that it declares.

Be sure not to declare these restricted capabilities unless your app truly needs them. There are cases where such capabilities are necessary and appropriate, such as banking with two-factor authentication, where users provide a smart card with a digital certificate that confirms their identity. Other apps may be designed primarily for enterprise customers and may need access to corporate resources that can't be accessed without the user's domain credentials.

To declare a restricted capability, modify your app package manifest source file (Package.appxmanifest). Add the xmlns:rescap XML namespace declaration, and use the rescap prefix when you declare your restricted capability. For example, here's how to declare the appCaptureSettings capability.

<?xml version="1.0" encoding="utf-8"?>
<Package
    ...
    xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
    IgnorableNamespaces="... rescap">
...
<Capabilities>
    <rescap:Capability Name="appCaptureSettings"/>
</Capabilities>
</Package>

Restricted capability approval process

Previously, we required you to contact support to get approval to use a capability. We now allow you to provide this info in Partner Center as part of the submission process.

When you upload packages for your submission, we will detect whether any restricted capabilities are declared. If we do so, you will be required to provide details about how your product uses each capability on the Submission options page. Be sure to provide as much detail as possible to help us understand why your product needs to declare the capability. Note that this may add some additional time for your submission to complete the certification process.

During the certification process, our testers will review the info you provide to determine whether your submission is approved to use the capability. Note that this may add some additional time for your submission to complete the certification process. If we approve your use of the capability, your app will continue through the rest of the certification process. You generally will not have to repeat the capability approval process when you submit updates to your app (unless you declare additional capabilities).

If we don't approve your use of the capability, your submission will fail certification, and we will provide feedback in the certification report. You then have the option to create a new submission and upload packages which don't declare the capability, or, if applicable, address any issues related to your use of the capability and request approval in a new submission.

Restricted capability list

The following table lists the restricted capabilities. You may request approval for these capabilities in apps that you submit to the Store by following the process described above.