Existing App Interop
You do not need to rewrite a WPF, WinForms, or Win32 app just to use Windows App SDK APIs. Add the SDK incrementally when one modern Windows feature justifies it.
Adoption Paths
| Existing app | Good first Windows App SDK feature | Watch out for |
|---|---|---|
| WPF | AppWindow, notifications, package identity, WebView2 | Bootstrap/runtime if unpackaged |
| WinForms | AppWindow, notifications, app lifecycle, WebView2 | HWND interop and threading |
| Win32 C++ | App lifecycle, windowing, deployment APIs | C++/WinRT setup and package graph |
| Existing installer app | Packaging with external location | Sparse package identity plus installer ownership |
Add Windows App SDK To Existing Desktop Apps
The broad pattern is:
1. Add Microsoft.WindowsAppSDK to the project.
2. Decide packaged, external-location, or unpackaged.
3. If unpackaged or external-location, initialize the runtime before using Windows App SDK APIs.
4. Use HWND interop for window-bound APIs.
5. Test the feature in the app's real deployment model.HWND Interop Is Normal
Many APIs need a window handle when called from desktop apps:
var hwnd = WinRT.Interop.WindowNative.GetWindowHandle(window);
WinRT.Interop.InitializeWithWindow.Initialize(fileOpenPicker, hwnd);Centralize that interop in a small service. Do not scatter HWND extraction through view models.
XAML Islands Caveat
UWP XAML Islands are a separate modernization path for hosting UWP XAML controls in desktop apps. They are not WinUI 3, and old XAML Islands docs often carry old platform constraints.
For new UI, prefer a WinUI 3 app. For existing WPF/WinForms modernization, consider whether the desired feature can be added without embedding a second UI framework.