Ask a team scoping a Xamarin.Forms migration what they are estimating and you will get a careful answer about iOS and Android. Renderers, navigation, platform services, store submission, device testing. Then, somewhere near the end: “and we get Windows for free.”
You do not get Windows for free. You get a Windows target whose capability ceiling is set by someone else’s release cadence, and which you cannot raise yourself.
This is the least-discussed part of MAUI migration scoping, and it produces a specific kind of late surprise: not a bug, but a wall.
The mechanism
.NET MAUI’s Windows head is WinUI 3, which ships inside the Windows App SDK. So every Windows App SDK release is, indirectly, a MAUI release note.
Except MAUI does not let you choose the version. Microsoft’s position, from an official Q&A answer, is unambiguous:
Because MAUI relies on this internally defined combination of WinUI 3 and Windows App SDK, manually upgrading the WindowsAppSDK NuGet package is not supported. The workload ensures that MSBuild will ignore or downgrade any attempts to reference a newer version.
Not “discouraged.” Not “at your own risk.” The build system actively reverses the change.
Now the numbers, checked against the published package metadata on 31 July 2026:
| Version | |
|---|---|
| Windows App SDK — stable channel | 2.2.0, followed by 2.3.1 |
| Windows App SDK — experimental channel | 2.3.2-ExperimentalA |
| .NET MAUI 10, current stable | pins Microsoft.WindowsAppSDK 1.8.x |
| .NET MAUI 11, latest preview | still pins a 1.8 build |
A full major version behind, with no supported path to close the gap, and the .NET 11 previews have not closed it either.
Two caveats we would rather state than have you discover. First, these pins move — verify against your own release rather than trusting this table in six months. Second, the structural argument does not depend on the specific numbers: MAUI has consistently trailed the Windows App SDK across releases, because the workload must validate a known-good combination before shipping it. That is a defensible engineering decision by Microsoft. It is simply not one most teams factor into an estimate.
What that actually costs you
Platform capability arrives on the Windows App SDK’s schedule and reaches you on MAUI’s. Whatever lands in the 2.x line — the on-device AI surface, newer composition and rendering work, current API projections — is not addressable from a MAUI app until the workload catches up. If a Windows-specific feature request depends on something recent, the honest answer to your product manager is “not this year,” and it will not be a decision your team gets to make.
Your dependencies can raise the version for you, and that is worse than it sounds. This is the failure mode nobody scopes, and it has already happened in public.
CommunityToolkit/Maui issue #3109 records it: CommunityToolkit.Maui 14.0.0 introduced a transitive dependency on Windows App SDK 2.0.0-experimental3. Because that is an experimental SDK version, the Microsoft Store blocked submission of the generated MSIX package. The reported workaround was downgrading the toolkit to 13.0.0.
Sit with the shape of that. A minor version bump of a widely used community package — the kind of change that goes through review in ninety seconds — made the application unpublishable. Not slower. Not visually wrong. Unable to ship.
That is the risk profile of a target most teams estimated at zero.
Scoping the Windows head honestly
If you are estimating a migration right now, five questions produce a more truthful number than any line item you could add.
1. Who actually asked for Windows? Start here, because a meaningful share of MAUI Windows heads exist because the project template generated one. If nobody can name the users, you are carrying a platform through every release for nobody, and the rest of this article is moot.
2. Is Windows the same product, or a different one? A phone screen stretched onto a desktop window is not a desktop application. Keyboard navigation, window resizing, multi-window, drag and drop, file system access, printing — each is a real workstream, and each is invisible in a mobile-shaped estimate.
3. Does anything on your roadmap need a current Windows API? If yes, the version ceiling is a scoping constraint today, not a future annoyance. Establish it before you commit to a delivery date.
4. How is it distributed? MSIX and Store submission, or unpackaged sideloading, or MDM deployment. Each has its own signing, updating, and support story, and none of them is covered by your mobile release process.
5. Who owns the transitive dependency risk? After the toolkit incident, someone should be responsible for knowing what your package graph pulls in on Windows. In practice this means pinning versions deliberately and reviewing what a bump brings with it — which is a small ongoing cost, but only if someone owns it.
Three defensible answers
Ship the Windows target. Correct when Windows is a convenience surface showing broadly the same screens as mobile, when nothing on the roadmap needs a recent platform API, and when someone owns the dependency graph. The version ceiling is real but tolerable, and you genuinely do get most of the app for a fraction of a separate build.
Build a separate WinUI 3 application. Correct when Windows is a distinct product — a back-office tool, a keyboard-first workflow, a desktop experience users spend hours in rather than minutes. You give up code sharing on the UI layer and keep it in your domain and service layers, which is usually where the value was anyway. You also get to move at the Windows App SDK’s pace rather than MAUI’s, which for a Windows-heavy product is the whole argument.
Do not ship Windows. The most underrated option. If you cannot answer question 1, mobile-only is a legitimate scope, and Windows becomes its own decision with its own business case rather than a checkbox that quietly consumes a fifth of every release cycle.
There is no universally right answer here. There is a wrong process, which is deciding by default because a template made a folder.
A note on our own previous position
We have written before that broad desktop support is one of MAUI’s real advantages over Flutter, in Flutter vs .NET MAUI in 2026. We still think that is true — reaching Windows from a shared C# codebase is a genuine capability that Flutter’s Windows story does not match for line-of-business applications.
But “supported” and “unconstrained” are not the same claim, and the version ceiling is a material qualification we did not make at the time. If you are choosing a framework partly for its Windows story, read both articles together. We would rather correct the record than have you find this out during a Store submission.
FAQ
Can I upgrade the Windows App SDK version in a .NET MAUI app?
No, not in a supported way. Microsoft’s guidance is that .NET MAUI relies on an internally defined combination of WinUI 3 and Windows App SDK, that manually upgrading the WindowsAppSDK NuGet package is not supported, and that the workload ensures MSBuild will ignore or downgrade any attempt to reference a newer version. You get the version your MAUI workload ships with.
Which Windows App SDK version does .NET MAUI use?
As of 31 July 2026, the current stable .NET MAUI release pins Microsoft.WindowsAppSDK 1.8.x, and the .NET 11 previews still pin a 1.8 build. Meanwhile the Windows App SDK itself ships 2.2 as stable with 2.3 releases in the experimental channel. Check the pin for your own release rather than trusting this number later — it moves, but the structural gap has persisted across several releases.
Why did the Microsoft Store reject my MSIX package?
One documented cause specific to MAUI is an experimental Windows App SDK version arriving through a transitive dependency. CommunityToolkit.Maui 14.0.0 introduced a dependency on Windows App SDK 2.0.0-experimental3, and because that is an experimental SDK version the Microsoft Store blocked submission of the generated MSIX package. The reported workaround was downgrading the toolkit.
Is it better to build a separate WinUI 3 app instead of using the MAUI Windows target?
It depends entirely on how much your Windows experience differs from mobile. If Windows is a convenience surface showing the same screens, the MAUI target is usually the cheaper answer despite the version ceiling. If Windows is a distinct product with keyboard-first workflows, multi-window layouts, or a need for current platform APIs, a separate WinUI 3 application removes the ceiling and often costs less than fighting it.
Should we ship the Windows target at all?
Ask who asked for it. A surprising number of Windows heads exist because the template generated one, not because a user requested it. If you cannot name the users, shipping mobile only and revisiting Windows as its own decision is a legitimate and usually cheaper answer than carrying a third platform through every release.
Related reading
- Flutter vs .NET MAUI in 2026: An Honest Engineering Comparison — the framework decision this article qualifies.
- Mono Is Gone: What .NET 11 Does to Your Migrated Xamarin App — the same pattern on the mobile side: the platform moved and your app did not.
- Hardening a Flutter MVP for Production: The Last 20% That Hides the Cost — where estimates reliably go wrong.
Scoping a migration and unsure about Windows?
We help product teams decide what to build, what to drop, and what to hand off — before the estimate is committed rather than after. If a Windows target is sitting in your scope without a business case, book a 20-minute call and we will help you make it an actual decision.
Sources
- .NET MAUI compatibility with WindowsAppSDK 1.8 — Microsoft Q&A
- Microsoft.Maui.Core package dependencies — NuGet
- Windows App SDK release channels — Microsoft Learn
- Windows App SDK 2.0 release notes — Microsoft Learn
- CommunityToolkit/Maui issue #3109 — experimental SDK blocks Store submission
- dotnet/maui issue #14107 — Upgrade WindowsAppSDK dependency version
- Supported platforms for .NET MAUI apps — Microsoft Learn
Version pins verified against published package metadata on 31 July 2026. These move between releases; verify against the MAUI version you are actually building.