A fanless aluminium test unit powered on a workbench, one amber indicator lit at its edge while its display glows out of focus behind it

UI toolkit Packaging Lifecycle Handover

Desktop stacks on Windows, compared properly

Five Windows stacks, compared without a favourite

Name: Elmhurst Enterprises
Address: 8 Mill Lane, Calcot, Reading, RG31 7RS, GB
Telephone: +44 118 425 2191

Every studio has a default stack, and every default stack is wrong for some projects. This page sets out what the main Windows desktop options actually are, what Microsoft currently says about them, and where each one tends to win — for UK teams making a decision they will live with for years.

Talk through your stack Read the comparison below

Reading this page

Two options will suit you. The other three will not.

If you leave this page knowing which two options suit you and why the other three do not, it has done its job. The rows below are not ranked — they are laid out in the order the trade-offs tend to surface in a project.

A stack decision touches three things at once: the UI toolkit your team will live in, the packaging and deployment path that gets the software onto a managed laptop, and how long the framework will be supported the way you are using it.

The five stacks, at a glance

What it is for / What it costs you

WinUI 3

Microsoft's recommended native UI framework for new Windows desktop apps, shipping as part of the Windows App SDK.

new Windows-only

WPF

Mature enterprise desktop framework with a wide body of existing code and commercial control libraries.

modernisation

Windows Forms

Common in older internal tools and workflow applications; usually chosen today for maintaining what already exists.

legacy upkeep

.NET MAUI

Microsoft's framework for building multi-platform natively compiled desktop and mobile apps from one codebase.

share with mobile

Electron

Bundles Chromium and Node.js into each application; strong appeal for teams whose strength is web development.

web team route

Figures and positions on this page follow Microsoft's current desktop development guidance and are stated as a working reference, not a ranking.

01 · Native

WinUI 3 and the Windows App SDK

WinUI 3 is Microsoft's recommended native UI framework for new Windows desktop apps, and it ships as part of the Windows App SDK. It targets Windows 10 and Windows 11, and is normally written in C# with XAML.

Choose it when the product is Windows-only, you want current platform controls and Fluent styling without extra layers, and your team is comfortable in C#. The trade-offs are real: it is the newer stack, so some third-party control libraries and long-tail edge cases are less travelled than in WPF. For a greenfield Windows-only application in 2026, it is the natural first option to evaluate.

Current Windows controls and Fluent styling without extra layers

Fewer third-party control libraries than WPF has accumulated

Microsoft still references WPF as a valid option for enterprise desktop systems, and it remains part of long-running .NET desktop development on Windows. It is commonly used for internal line-of-business applications, which is exactly where we see it.

WPF's advantage is maturity. There is a large body of existing code, a wide range of commercial control libraries, and twenty years of answers to awkward questions. When a team is modernising an existing WPF application, or building one that leans heavily on a third-party grid or charting component, WPF is often the pragmatic answer rather than the nostalgic one. Its relevance today is mostly in modernisation rather than greenfield work.

Best fit

Enterprise desktop and internal line-of-business tools

Where it hurts

Greenfield projects that would rather start on the current stack

02 · Mature

WPF, still earning its place

03 · Legacy

Windows Forms and the case for leaving it alone

Microsoft still lists Windows Forms for enterprise desktop software, and it remains part of .NET desktop development on Windows. It is common in older internal tools and workflow applications, and it is usually chosen today for maintaining or extending software that already exists.

The framework is not the problem. A Windows Forms app that does a well-defined job, runs on current Windows and can be deployed through your management tooling is a working asset. Rebuilding it is a project with cost, risk and a training burden.

Questions worth asking

Is the app still supported on the Windows versions it must run on?
Does it deploy cleanly through your current management tooling?
Are the people who understand it still reachable?
If the answers are fine, so is the app.

04 · Multi-platform

.NET MAUI, Avalonia and Uno

.NET MAUI is Microsoft's framework for building multi-platform natively compiled desktop and mobile apps. It targets Windows and macOS for desktop, plus Android and iOS, using C# and XAML, and sits in Microsoft's current desktop stack alongside WinUI and the Windows App SDK.

It suits a .NET team that needs one codebase across desktop and mobile and is willing to accept that platform-specific polish takes extra work. If your target set includes Linux, look at Avalonia or Uno Platform instead, which is a separate decision and worth its own conversation. The shared lesson across all three: unify the parts that are genuinely shared, and expect to write some platform-specific code regardless.

Windows

Desktop

macOS

Desktop

Android

Mobile

iOS

Mobile

05 · Web team

Electron and the web-team route

Electron bundles Chromium and Node.js into each application. It supports Windows, macOS and Linux, and remains one of the most established desktop frameworks in active use. Its main appeal is that a team with strong web skills can ship a desktop program without learning a native UI toolkit.

The cost is footprint. Every installation carries a browser engine and a Node runtime, which affects installer size, memory use and the update cadence you inherit. For an internal tool on modern hardware that is often acceptable. For a distributed product on mixed hardware, it is a decision worth measuring rather than assuming.

The alternative

Tauri

Tauri is the usual alternative raised here, trading the bundled runtime for a system webview at the price of more platform-specific work. Smaller installers, but the webview differs between Windows versions and macOS releases.

Which of the two is right depends on how much control you want over the rendering engine on each machine your users actually run.

AI features

On-device or in the cloud

Microsoft's current guidance for Windows app technology includes Windows ML and Foundry Local. Windows ML is relevant to applications that need inference on Windows devices. Foundry Local is positioned for local AI scenarios rather than cloud-only integration, and sits alongside the Windows AI APIs in that guidance.

The choice between local and hosted inference is mostly about constraints, not preference. Local inference removes a network dependency and keeps data on the machine, which matters for regulated work. It also sets a hardware floor and complicates updates when the model changes. Hosted inference is simpler to run and harder to justify when the data should not leave the building.

Decide this early. It shapes the framework choice, not the other way round — a Windows-only app locked to local inference has very different packaging and update needs from one that calls a hosted model on every launch.

Where can the data legally go?

If the answer is "nowhere outside the building", local inference is the only path.

What hardware do your users actually have?

Local inference sets a floor. Check the slowest machine on the oldest site, not the demo laptop.

Can you update the model independently?

Bundled models make releases heavier and slower. Hosted models let the model move on its own cadence.

Packaging

The framework nobody lists

MSIX is Microsoft's packaging format for Windows apps and appears in enterprise desktop workflows as a matter of course. It is used for packaging and deployment, and is common in line-of-business and managed-device environments.

It belongs in this comparison because it constrains the others. A framework that produces an awkward MSIX package costs you deployment time on every release. A framework with a smooth packaging path saves it.

When you are weighing WinUI 3 against WPF, or Electron against Tauri, ask how the output gets onto a locked-down laptop in a finance department. That question eliminates options faster than performance benchmarks do.

A Installer size: Bundled runtimes inflate the package; system-webview routes keep it lean.
B Signing: Managed devices reject unsigned or self-signed builds; plan the certificate chain early.
C Update path: Store, line-of-business distribution, or an in-app updater — each implies a different framework.
D Rollback: A pack that reinstalls cleanly matters more than a fast first install.

Common mistakes

How stack decisions go wrong

These four patterns show up again and again on the projects that arrive here already in trouble. None of them are exotic. All of them cost real time to unwind.

01

Choosing by popularity

The most discussed framework is not the one with the longest support horizon for your use case.
02

Optimising for the demo

A beautiful prototype in a stack nobody on the team knows is a liability dressed as progress.
03

Leaving deployment until the end

Packaging and signing decide whether your software ever reaches users in a managed environment.
04

Over-engineering cross-platform

If nine of ten users are on Windows, one codebase for everyone may cost more than it saves.

Questions we get asked

Common questions about picking a Windows stack

These are the five questions that come up most often in the first call. The answers are the same ones we would give in an email.

Which framework should a new Windows-only app use in 2026?

Start with WinUI 3 and the Windows App SDK, since Microsoft positions it as the recommended native framework for new Windows desktop apps. WPF remains a reasonable choice if your project leans on mature third-party controls or your team already knows it well.

Is Electron still a good choice?

Yes, if your team's strength is web development and the app footprint is acceptable on your target hardware. It is one of the most established desktop frameworks in active use and supports Windows, macOS and Linux.

Can a Windows Forms app be modernised rather than replaced?

Often, yes. Microsoft still lists Windows Forms for enterprise desktop software. Modernisation might mean updating the .NET target, replacing an unsupported dependency, or improving the deployment path while the interface your staff know stays as it is.

Does .NET MAUI replace WinUI 3?

No. They sit alongside each other in Microsoft's current desktop stack. MAUI is for projects that need one codebase across desktop and mobile. For a Windows-only product, WinUI 3 gives you more direct access to platform capabilities.

How do we decide between local and cloud AI?

By asking where the data can legally and practically go, and what hardware your users have. Windows ML and Foundry Local exist for inference on the device. If neither constraint is binding, a hosted model is usually simpler to operate.

Where to next

Picked two? Now see how we act on it.

If you already have a shortlist, the useful next step is to see how a project runs end to end, or to put the decision in front of us with your own constraints attached.

Talk through your stack Review the services

The sequence

See how we run a project

From the first written scope through to the signed handover and support window.

The work

Review the services

New builds, legacy modernisation and deployment work for UK teams.

Reading

Read the guides

Practical notes on Windows desktop development and how the studio handles data.

The studio

About Elmhurst

Who we are, where the bench is, and the way we work with UK businesses.

Direct

Email [email protected] or call +44 118 425 2191. Working hours: Monday to Friday, 9:00 AM – 6:00 PM.