Desktop technology guide
Choosing between WinUI 3, WPF, UWP, ATL and Electron
Framework choice is the decision that is hardest to reverse in desktop software, and it is usually made with less information than it deserves. We work in all of them, so this guide can be honest about each.
Act II
Three frameworks, three criteria
The Microsoft recommendation, and what it costs you later
Microsoft positions the Windows App SDK as the recommended development platform for new Windows desktop applications, paired with WinUI 3 for the interface layer. The desktop app documentation was updated in 2026 and targets current Windows scenarios rather than legacy desktop patterns. If you are starting a new Windows product with no existing code to carry, this is the default that will age best.
The practical advantages are a modern UI framework, support for current Windows features, and a vendor path that is being actively developed rather than maintained at a distance. The cost is that some third-party components and older code patterns assume earlier frameworks, so a migration of existing code is not a like-for-like exercise.
How the three compare
Deployment
New installers assume current Windows servicing and a modern package path. Existing ClickOnce or MSIX pipelines need rework to follow.
Deployment
Fully proven for line-of-business rollout: MSIX now, ClickOnce or MSI for older managed fleets.
Deployment
WPF ships with a long deployment history. Electron wraps the app in its own signed installer and its own runtime update mechanism.
Native integration
Direct access to current Windows APIs; the platform team's own direction.
Native integration
Excellent Windows-native reach. ATL and low-level components still integrate in the same process.
Native integration
WPF is Windows-only. Electron reaches low-level hardware through additional work, not by default.
Cross-platform reach
Windows only. Pair it with a separate macOS build if a mixed fleet is in scope.
Cross-platform reach
Windows only. WPF suits a native Mac companion through MAUI or a separate Swift build.
Cross-platform reach
One codebase across Windows, macOS and Linux. The strongest reason most teams choose it.
Where each framework now sits
WPF, WinForms, UWP and ATL in practice
WPF: still live, still earning
A great deal of WPF is in production and much of it works. If your organisation runs a substantial WPF application, extending it is frequently the sensible commercial choice — the framework is not deprecated, your team may already know it, and the alternative is a rewrite measured in months. What WPF does not give you is the newest Windows capabilities without extra work.
WinForms: the quiet workhorse
WinForms does not appear in most comparison tables and still runs a large share of internal business tools. It is fast to build with, well understood, and adequate for data-entry screens on fixed workstations. For a small internal tool with a short lifespan it can be the pragmatic answer; anything with a ten-year horizon or a demanding UI usually needs a different footing.
UWP and where it now sits
UWP still appears in modernisation conversations, but newer Microsoft guidance emphasises WinUI 3 and the Windows App SDK. That places UWP in the older app generations category: relevant if you have UWP code, less relevant as a target for new work. The common task is deciding whether to port the interface layer forward or leave the app as it is until its function changes.
ATL and the lower-level layer
ATL is still named by Windows application specialists in the UK and is associated with lower-level native Windows development. It often appears in legacy modernisation work, and it remains relevant for specialised Windows components where control over memory, threading or COM interfaces matters. Most business software does not need ATL. Some does, particularly where a component is embedded in a larger product or must run with minimal overhead.
The workbench
Electron and the cross-platform trade
Electron is a major cross-platform choice and remains attractive to teams with JavaScript skills who want one codebase across Windows, macOS and Linux. It delivers a consistent application on all three without three separate engineering efforts. The trade is weight and integration depth: an Electron app carries a browser runtime, and reaching low-level hardware or behaving exactly like a native application on each platform takes additional work. It is a strong fit for products that are information-heavy and device-light, and a weaker one for tools that exist because of a scanner.
Matching the framework to your constraints
Four questions usually settle it
A device-heavy internal tool on managed Windows machines points one way. A cross-platform product for a mixed fleet of laptops points another. Ageing WPF software with a working business behind it often points to extension rather than replacement. Write the answers down and the shortlist becomes short.
Device access
Does it talk to local hardware?
Scanners, scales, industrial printers and serial devices usually want a native Windows build, often with an ATL or WinUI 3 layer.
Platform reach
Must it run on macOS too?
If yes and the app is information-heavy, Electron earns its weight. If yes and the app is device-bound, plan two builds.
Lifetime
How long does it need to live?
A two-year internal tool and a ten-year product line do not deserve the same framework — or the same amount of rewriting.
Existing code
What does your estate already use?
A working WPF application with a real business behind it is an asset, not a mistake. Extend before you rewrite.
What we would not do
We would not start a new Windows product in a framework that Microsoft has moved past, unless there was a specific reason such as component availability. We would not choose a cross-platform runtime for an application whose main value is deep operating-system integration. And we would not propose a rewrite where staged modernisation gives the same outcome with less risk.
None of this is a rule against any particular technology. It is a rule against choosing one before the constraints are known.
A short note is enough to start
Tell us what stack you are running
We read every message ourselves and reply on the next working day. Send the framework, the age of the software and the constraint that matters most — hardware access, macOS reach, or how long it needs to live. That is usually enough to suggest a shortlist.
Where we are
Ashgrove Imports Limited
8 Mill Lane, Calcot,Reading, England +44 118 478 4187 [email protected]
Monday to Friday, 9:00 AM – 6:00 PM
One minute of context
Which stack fits your project?