On July 27, 2026, Microsoft released a public preview of a dynamic projection that lets developers call Windows Runtime (WinRT) APIs directly from Electron and Node.js. It reduces the burden of building a C++ or C# native add-on for each API when using JavaScript/TypeScript to access Windows notifications, storage, on-device AI, and more. Type information is generated at build time, while actual API calls are handled dynamically by a shared runtime. That said, this doesn't eliminate the need for package IDs, manifests, or signing at distribution time to use Windows-specific features.
A three-layer structure that removes the C++ bridge
Until now, using a new WinRT API in an Electron app typically meant building either a C++ add-on with node-addon-api, or a C# add-on via node-api-dotnet. The former requires setting up node-gyp, MSVC, Python, and the appropriate Windows SDK, and managing builds for each Electron version and CPU architecture. The latter adds the .NET SDK and a project build process, and requires maintaining wrappers for every API you expose.
Of the three packages that make up the public preview, @microsoft/winappcli is the one developers install directly. The versions of the other two packages are managed by the CLI.
| Component | Role | What remains in the app |
|---|---|---|
@microsoft/winappcli |
Manages manifest, SDK metadata, binding generation, and debug IDs | Windows-specific settings and generation commands |
@microsoft/dynwinrt-codegen |
Reads .winmd and generates JavaScript and TypeScript declarations |
Typed bindings in .js and .d.ts |
@microsoft/dynwinrt |
Calls WinRT methods at runtime | Shared runtime for x64/arm64 |
Running npx winapp init . --use-defaults --add-js-bindings has the CLI create Package.appxmanifest and SDK settings, and places generated output under .winapp/bindings/. The app can then import the classes it needs from #winapp/bindings. In other words, what gets eliminated is the process of writing and updating a native bridge for each app—not the Windows SDK itself.
Types generated at build time, calls resolved at runtime
WinRT API definitions live in Windows Metadata (.winmd) files. Because dynwinrt-codegen generates pure JavaScript wrappers and .d.ts files from this metadata, editor autocompletion is preserved while avoiding the need to generate native code for each API class. Even when the Windows App SDK version is bumped, the basic workflow is to regenerate bindings from the corresponding metadata.
At call time, the native runtime of dynwinrt, implemented in Rust, passes processing through to the COM virtual function table via libffi. WinRT's HSTRING is converted to a JavaScript string, and HRESULT failures are converted into exceptions. Asynchronous operations can be awaited with await, and cancellation and progress notifications are also supported. In addition to collections and structs, enums and delegates are also included as projection targets.
The intent behind this separation is to reduce the combinatorial problem of rebuilding app-specific native projections every time the Windows App SDK is updated. On the other hand, calls at runtime pass through FFI and dynamic dispatch. The design documentation expects this overhead to be comparable to existing marshaling across language boundaries, but it does not guarantee general performance parity with static C++/C#/Rust projections. This is one of the items worth verifying during the public preview.
Notifications and on-device AI from the same JavaScript
The two Electron examples Microsoft has published are rich notifications via the Windows App SDK and on-device summarization powered by Phi Silica. For notifications, the sample uses AppNotificationBuilder to access a broader range of Windows functionality than Electron's standard basic notifications, including progress bars, action buttons, and input fields. The sample displays a progress value of 0.65 as 65%.
In the Phi Silica example, LanguageModel and TextSummarizer are loaded, and the partial string produced during generation is received via a progress callback. Microsoft's Electron on Windows Gallery includes a total of nine AI features, including text generation, summarization, rewriting, conversion to tables, as well as image description and OCR. The gallery itself is also in public preview and is not yet distributed via the Microsoft Store.
However, the Phi Silica sample in the announcement blog post requires a Copilot+ PC to run, and requires adding the restricted capability systemAIModels to the manifest. Phi Silica is also a Limited Access Feature. Furthermore, Microsoft Learn has indicated plans to provide a test package for Aion Instruct in September 2026, roll it out to Windows Insiders in October and to general devices in November, and then remove Phi Silica.
This planned transition also clarifies the role of dynamic projection. While the work of regenerating API types from metadata can be made lighter, the task of the app verifying model changes, supported devices, and access conditions still remains. Phi Silica is an example demonstrating the capabilities of the new path—it is not a fixed, long-term foundation.
Package IDs and UI remain boundaries
Many APIs, including notifications and Windows AI, require the app to have a Windows package identity. During development, you can give the Electron executable a temporary identity using npx winapp node add-electron-debug-identity, but you'll need to re-register if you change manifest capabilities, identity information, or the location of the executable. Even for regular Node.js processes, you can register a temporary package with winapp run, launch it via an execution alias, and unregister it when finished.
For production distribution, you'll need to separately decide which packaging approach to take, what to declare in the manifest, and how to handle signing and updates. While the WinApp CLI can also handle MSIX creation and signing, adding projection alone doesn't complete the distribution process for a Windows app. Third-party WinRT components can also have wrappers generated from .winmd, but placing the actual binaries and configuring activation remains the developer's responsibility.
The same boundary applies to UI handling as well. By default, the CLI generates data-oriented Windows App SDK APIs and excludes UI-specific packages such as Microsoft.WindowsAppSDK.WinUI and WebView2. WebView2 is excluded from generation. On the other hand, the dynwinrt repository also shows steps for hosting from JavaScript if you explicitly opt in to WinUI's Application and Window. In that case, the calling side is responsible for managing the STA UI thread, package identity, and lifecycle. It's not that UI can't be called at all—it's that the default, convenient path is limited to things like notifications, AI, and storage.
How far can Windows-specific features be maintained
For cross-platform Electron apps, this public preview doesn't eliminate Windows-specific code. Since the same WinRT APIs can't be called on macOS or Linux, installation processing and feature branching still need to be separated for Windows. Even so, there's real significance in keeping the platform-specific layer within the JavaScript/TypeScript project and narrowing the scope of native add-ons that need to be rebuilt with every SDK update.
What will determine success is how many unsupported types or APIs actually show up in real-world Electron apps, whether the overhead of dynamic calls is acceptable for each use case, and whether teams can reliably automate package identity and distribution procedures. Microsoft is also asking developers to report type mismatches and unsupported scenarios on GitHub. Before this reaches general availability, compatibility across Windows App SDK updates, and how the samples using Phi Silica get updated after the transition to Aion Instruct, will be key considerations for real-world adoption.