What Are App Capabilities?
A UWP app runs inside an app container, a sandbox that by default cannot touch the webcam, microphone, documents library, internet, or almost anything else on the machine. Capabilities are declarations placed inside the <Capabilities> element of Package.appxmanifest that punch specific, named holes in that sandbox. The Windows app model enforces least privilege: an app can only access exactly the resources it has explicitly listed, and the OS refuses everything else by default regardless of what the code tries to call.
Cricket analogy: Compare to a fielding restriction card that names exactly which positions a captain may use during powerplay overs — like Rohit Sharma's team must declare fielders inside the circle before the over starts, a UWP app must declare each resource it intends to touch before the OS allows it.
General vs. Restricted Capabilities
Capabilities fall into tiers. General capabilities, such as internetClient, documentsLibrary, and microphone, can be self-declared by any developer and trigger a Store certification check plus, for some, a runtime consent prompt. Restricted capabilities, such as enterpriseAuthentication or sharedUserCertificates, require additional Store review or special enterprise provisioning because they touch sensitive system state. Device capabilities are a third category, declared under <DeviceCapability> using a device interface class GUID to grant access to a specific class of connected hardware.
Cricket analogy: Comparable to DRS reviews — a captain can request a normal review anytime, like a general capability, but reviewing a no-ball for height needs a special third-umpire protocol, like a restricted capability needing extra approval.
Declaring Capabilities in the Manifest
Capabilities are declared as XML elements inside <Capabilities>, using namespaces such as uap for standard UAP capabilities and rescap for restricted ones. Missing a declaration doesn't cause a build error — it causes a runtime failure, typically an UnauthorizedAccessException or a silent no-op, when the app later calls an API like MediaCapture, Geolocator, or PhoneCallHistory that depends on that capability being present. Because the failure surfaces far from the manifest file, forgotten capability declarations are one of the most common causes of "it works on my dev machine but fails after packaging" bugs.
Cricket analogy: Like a scorecard that must list a bowler's name in the XI before he's allowed to bowl — if a groundsman forgot to add Bumrah's name pre-match, the umpire won't let him bowl, just as an undeclared capability throws an exception at runtime.
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap rescap">
...
<Capabilities>
<Capability Name="internetClient" />
<uap:Capability Name="documentsLibrary" />
<DeviceCapability Name="microphone" />
<DeviceCapability Name="webcam" />
<rescap:Capability Name="enterpriseAuthentication" />
</Capabilities>
</Package>A missing capability declaration almost never fails at compile time. It surfaces as an UnauthorizedAccessException (or a quiet empty result) the first time a dependent API is called at runtime — often deep into QA or after Store submission. Always cross-check every API you call against the required capability listed in its MSDN/Learn documentation before shipping.
Runtime Permission Checks and User Consent
Declaring a capability in the manifest is necessary but not always sufficient. Privacy-sensitive capabilities like microphone, webcam, and location additionally require live user consent, surfaced through Windows Settings > Privacy and checked at runtime by APIs such as MediaCapture.InitializeAsync or Geolocator.RequestAccessAsync. A user can revoke consent at any time in Settings even after granting it once, so a well-behaved app must handle the denial path gracefully — showing a clear message and a way to re-open the Settings page — rather than crashing or silently doing nothing.
Cricket analogy: Like a player passing the fitness test administered by the board on match morning, even though he was already selected in the squad — selection, like the manifest declaration, alone isn't enough without a fresh runtime check, the consent.
- Capabilities are declared inside <Capabilities> in Package.appxmanifest and enforce least-privilege sandboxing for UWP apps.
- General capabilities (internetClient, documentsLibrary) can be self-declared; restricted capabilities (rescap namespace) require extra Store review or enterprise provisioning.
- Device capabilities target a specific hardware interface class GUID under <DeviceCapability>.
- A missing capability typically fails at runtime, not compile time, often as UnauthorizedAccessException.
- Privacy-sensitive capabilities like microphone, webcam, and location require live runtime user consent via Settings > Privacy in addition to the manifest declaration.
- Users can revoke consent at any time, so apps must handle the access-denied path gracefully.
- Always verify the exact required capability for each API against official documentation before shipping.
Practice what you learned
1. Where must a UWP app declare that it needs microphone access?
2. What typically happens when an app calls an API like Geolocator without declaring the required capability?
3. Which XML namespace prefix is used for restricted capabilities that require special Store review?
4. For a privacy-sensitive capability like the microphone, what else is required beyond the manifest declaration?
5. How does a UWP app declare access to a specific connected hardware device class, such as a specialized USB sensor?
Was this page helpful?
You May Also Like
File Access in UWP
How Universal Windows Platform apps read and write files safely through the sandboxed StorageFile/StorageFolder model, pickers, and the Future Access List.
UWP Sensors and Devices
How Universal Windows Platform apps read hardware sensors like accelerometers and compasses, query location, and enumerate connected devices such as cameras.
UWP Background Tasks
How Universal Windows Platform apps run code while suspended or not in the foreground, using triggers, conditions, and a constrained execution model.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics