Add API support matrix for packaging configurations

[guimafelipe]

Summary

• Adds a centralized API support matrix document showing which WinAppSDK APIs are supported under each packaging/configuration combination (Packaged, Unpackaged, Self-Contained, Framework-Dependent)
• Covers App Notifications, Push Notifications, App Lifecycle, MRT Core, Application Data, Deployment, Windowing, Version Info, Storage Pickers, and WCR
• Information extracted from individual spec documents into a single reference

Fixes #5768

[DrusTheAxe]

This (and other entries in this table) say 'P' but no explanation what it means

[DrusTheAxe]

SUGGESTION: Change 'P' to as a reference to a footnote after the table e.g.

| API | Packaged | Unpackaged | Self-Contained | Notes |
...
| PushNotificationManager.Unregister() | Y | Y | 1 | |

1. Image protocols in notifications only support file:// URIs in Unpackaged and Self-Contained configurations.

[DrusTheAxe]

Combination heading should be Configuration

[DrusTheAxe]

Packaged

Remove the (MSIX).

[DrusTheAxe]

I'm puzzled over this whole table.

Rows 1+2 are orthogonal to 3+4.

Let's start with the 1st row, **Packaged (MSIX)". Ignoring the "(MSIX)" part is redundant and misleading, the description for the phrase "Packaged" is incorrect and misleading.

• "Packaged" means "process HAS package identity"
• "Unpackaged" means "process LACKS package identity"

https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/packaging/#packaged-vs-unpackaged-apps

There are many ways you can distribute and install and ultimately get a running process with package identity.

Additionally, "MSIX Desktop Bridge" aka "Desktop Bridge" aka "packagedClassicApp" aka "Centennial app" isn't the only form of a running process with package identity. If you specify uap10:RuntimeBehavior="win32App" in appxmanifest.xml you get a "Win32app" aka "Win32alacarte" running process which has package identity. Such processes are not Desktop Bridge processes but no less Packaged processes, as they equally have package identity.

For another example, a packaged Service, specified via desktop6:Service in appxmanifest.xml also produces a running process with package identity and is equally a "Packaged" process, despite no Desktop Bridge in play.

There's also Packaged processes you get by running some non-MSIX installer to install classic unpackaged software and registered a package with a External Location pointing to that classic unpackaged software so when c:\classic\non-msix\installed\foo.exe runs it has package identity.

Packaged vs Unpackaged is already well defined at https://learn.microsoft.com/windows/apps/package-and-deploy/packaging/#packaged-vs-unpackaged-apps and is all about if a running process HAS or LACKS package identity in its process token.

Rows 3+4 are an entirely independent concept - the form of the Windows App Runtime consumed by a process:

• Framework-Dependent -- Windows App Runtime is used from WinAppSDK's installed MSIX packages
• Self-Contained Windows App Runtime is used via a redistributable copy colocated with the consuming application

A more convenient set of lingo is WinAppSDK/MSIX vs WinAppSDK/SelfContained.

If I make a packaged application using WinAppSDK/SelfContained then my packaged app includes a copy of the Windows App Runtime inside my package for use by my packaged app. In that case...
*

• MyAwesomeApp.exe is a Packaged app
• MyAwesomeApp.exe is in MyAwesomeApp.msix
• Windows App Runtime (Microsoft.WindowsAppRuntime.dll etc) is also in MyAwesomeApp.msix

If MyAwesomeApp is packaged but using WinAppSDK/MSIX then...
*

• MyAwesomeApp.exe is a Packaged app
• MyAwesomeApp.exe is in MyAwesomeApp.msix
• Windows App Runtime (Microsoft.WindowsAppRuntime.dll etc) is is WinAppSDK's MSIX packages*

* Saying 'Framework-Dependent' or WinAppSDK/Framework is misleading for multiple reasons. WinAppSDK is currently composed of multiple MSIX packages - Framework, Main, Singleton, DDLM. It's not just a Framework package. WinAppSDK/MSIX is the more accurate phrase, avoiding the misperceptions conveyed by citing any particular packages or package types making up WinAppSDK's runtime.

[DrusTheAxe]

This is problematic and increasingly so over time.

For one, only a fraction of feature areas are mentioned. I see nothing about Decimal, Dynamic Dependencies, Environment Manager, OAuth, Package Management, Runtime Compatibility or more.

For another, the level of detail is partial and asymmetric. For example, the Application Data table lists 2 of the 4 static methods and none of the instance methods. Nor is there any relation to apicontract version - 1 of the static methods mentioned is v2, the other and the others not mentioned are v1.

Furthermore, the standard is all Windows App SDK APIs are required to work on all supported platforms and in support supported configurations, unless exceptional justifications apply.

If you're seeking to ensure clear documentation of what is and isn't available, across all platforms and configurations, you'd be better off refocusing this document on the exceptions. That's a much smaller, tractable and maintainable list, and provides more value to the reader (just the exceptions, not cluttered with the far more numerous 'normal'/everywhere cases).

For example:

Overview

This document applies to all releases of Windows App SDK version 2.* .

Packaged vs Unpackaged

Windows App SDK's runtime can be used by packaged and unpackaged processes except where otherwise stated. See Package vs unpackaged apps for more information about packaged vs unpackaged.

Configurations

Windows App SDK's runtime can be used via MSIX packages or Self-Contained unless stated otherwise.

These configurations are referred to as WinAppSDK/MSIX and WinAppSDK/SelfContained.

Platform Support

Windows App SDK supports the following platforms unless stated otherwise:

• Windows Desktop version >= 10.0.17763.0 (aka RS5)
• Windows Server version >= 10.0.something.0 (aka 2019)

Exceptions

Bar

The Bar feature is only available on Windows Desktop version >= 10.0.12345.678.

Foo

The Foo feature's API Microsoft.Windows.Huh.Foo.HowAboutNow() does not support WinAppSDK/MSIX for Unpackaged processes.

The Foo feature is only available on Windows Desktop version >= 10.0.23456.87 and Windows Server version >= 2025 (10.0.34567.0).

Meh

The Meh feature does not support WindowsAppSDK/SelfContained.

The Meh feature 's API `Microsoft.Windows.Yawn.Meh.JustDoIt() is only available on Windows Server >= 2025 (10.0.34567.0).