The build system is set up so that you have access to APIs for which the ‘API Contract’ is listed as ‘Windows.Foundation.UniversalApiContract’ anywhere in C++ code. APIs under Windows.UI.XAML, however, will mostly not work, even though they’re in the universal contract, because we don’t create the UE game window as a XAML window. While there are docs out there that discuss overlaying XAML UI on a DirectX panel, that’s not the approach I’d typically recommend to games - instead I’d encourage you to draw your UI as you always have, to your game’s swap chain. That way you don’t have to go relearn how to get the perf and look you’re after, and it’s much easier to ship multiplatform.
UI APIs that pop external windows are typically not part of the XAML space and, per above, will work. The ones games are most likely to need (notably message box, and Xbox Live UI) should be wrapped with UE interfaces (e.g. FPlatformMisc::MessageBoxExt, methods of IOnlineExternalUI) again to facilitate multiplatform dev. But if you do need to add something more, say a FilePicker for some reason, you can. Be careful to only interact with Windows UI from the main game thread though, otherwise you’ll hit exceptions from violating the UWP threading model.
If you need to use a WinRT API outside the universal contract you can do that too! But you’ll need to add a reference to the contract from the build.cs file of the module where you wish to use it.
string StorageApiMetadata = VCEnvironment.GetLatestMetadataPathForApiContract("Windows.Gaming.XboxLive.StorageApiContract");
if (!string.IsNullOrEmpty(StorageApiMetadata))
{
PrivateWinMDReferences.Add(StorageApiMetadata);
}