Working notes · desktop development

Guides for people who have to decide

These are working notes on Windows desktop development, written for the person weighing up a rebuild, a framework choice or a deployment problem. They come out of project work rather than research, and where an answer depends on your situation we say so instead of pretending there is one right way.

New guides are added as questions come up in scoping calls. If something you need is missing, ask and it may end up here.

Start with the framework note Talk through your project

In this collection

Choosing a framework WinUI 3, MAUI or Electron Keeping WPF in the plan What actually needs fixing When to leave Forms alone Age is not the argument Packaging and MSIX Why it constrains design

On-device AI decisions Windows ML and Foundry Local Working with a studio Scope, not code Four beginner mistakes Common traps in delivery Questions on these And questions we have not written

Note one

Choosing a framework for a new Windows app

Ratified · from project work

The question arrives in almost every first call, usually phrased as "which one is best". The honest structure of the answer is a shortlist and an elimination.

Start with whether the product is Windows-only. If it is, WinUI 3 and the Windows App SDK are where Microsoft's current guidance points for new native desktop apps, written in C# and XAML.

Framework

Where it fits

What it costs in the room

Surface

WinUI 3

New native Windows apps written in C# and XAML

Current platform capabilities, Microsoft's forward guidance; smallest set of unknowns

Windows only

.NET MAUI

One C# and XAML codebase behind a shared UI

Worth it only when a real share of users is on macOS or a mobile companion is on the roadmap

Windows · macOS

WPF

Long-running Windows desktop and enterprise systems

Still a valid option per Microsoft; the question is renewal or replacement, not age

Windows only

Windows Forms

Older internal tools and workflow applications

Mostly chosen today for maintaining or extending an existing system, not for greenfield

Windows only

Electron

A team strongest in web technologies

Lets a web team ship without a native UI toolkit; the app footprint has to be acceptable

Win · macOS · Linux

Question one

What hardware will this run on?

Whether the floor is a managed laptop or a workshop terminal decides the toolkit before the framework does.
Question two

Who maintains it in three years?

If nobody in-house will, the framework needs a shallow maintenance story and a plain deployment route.
Question three

How does it reach a managed laptop?

If the management platform cannot install it, the framework choice loses to the deployment reality.

Note two

Keeping WPF in a modernisation plan

WPF is not a legacy framework in the way Windows Forms is often assumed to be. Microsoft still references it as a valid option for enterprise desktop systems, and it remains part of long-running .NET desktop development on Windows. For internal line-of-business applications it is common, and for good reasons: mature control libraries, a large body of existing code, and a decade of documented answers.

If you are modernising a WPF application, the useful question is what specifically is failing. An outdated .NET target, an unsupported dependency, a deployment process held together by one person. Those are fixable without discarding the interface your staff know.

A move to WinUI 3 makes sense when the product has a long Windows-only future and the team wants current platform capabilities. It makes less sense as a reflexive upgrade.

Fixable without a rebuild

An outdated .NET target that no longer receives updates
An unsupported third-party dependency blocking upgrades
A deployment process that only one person on the team can run

Note three

When a Windows Forms app should be left alone

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

The framework's age is not a reason on its own. If the application runs on current Windows, does a well-defined job, and can be deployed through your management tooling, it is a working asset with a known cost.

Rebuilding it introduces a project, a risk and a training burden for users who did not ask for anything new.

Worth investigating

Is the build still reproducible on a clean machine?
Is anyone reachable who understands the awkward parts?
Are there dependencies that are no longer supported?

If those answers are comfortable, the sensible plan may be to leave it running and spend the budget elsewhere.

A closed fanless aluminium computer case on a workbench at the end of a working day, hand tools laid down beside it

Note four

Packaging matters more than people expect

MSIX is Microsoft's packaging format for Windows apps and is used widely in enterprise desktop workflows. In line-of-business and managed-device environments it is the difference between software arriving and software being blocked.

The mistake we see most often is treating packaging as a final step. It is not, because it constrains design decisions. If the application writes to protected locations, or expects administrator rights at first run, or updates itself in a way the management platform does not allow, those are architecture problems rather than installer settings.

Deciding the packaging route during scoping costs nothing and saves weeks.

Decide at scoping

Which MSIX packaging path your management platform accepts, and what it expects of the app

Cost of getting it wrong

Rewritten install logic, redirected writes, a second signing pass and a delayed rollout

Note five

On-device AI in a desktop application

Microsoft's current guidance for Windows app development includes Windows ML and Foundry Local. Windows ML is relevant when an application needs to run 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.

In practice the decision is about constraints. Local inference keeps data on the machine and removes a network dependency, which matters when the data should not leave the building or the connection is unreliable.

It also raises the hardware floor and makes model updates harder to manage. Hosted inference is easier to operate and harder to justify for sensitive data. Settle this early, because it affects the framework and the packaging as much as the model.

Note six

Working with a studio on a desktop project

Most of the difficulty in commissioning desktop software sits in scope, not code. A scope that describes what the software will do in terms a user would recognise, and states what it will not do, prevents more disputes than any other document.

Ask before work starts

The deployment route, in writing, before work starts.
Who tests on a managed machine, not just on a developer laptop.
What the handover contains, and whether the source is buildable without the original developer.

A studio that answers those plainly is a studio you can work with, and the answers take less time to give than to argue about later.

Note seven

Common beginner mistakes in desktop delivery

Four of these come up again and again across small teams and first projects. Naming them early is cheaper than discovering them at the rollout.

One Choosing a framework by popularity rather than by maintenance.
Two Designing the interface around a demo and discovering the deployment constraints afterwards.
Three Assuming cross-platform is free because a framework compiles to several targets; the shared parts are shared, and the platform-specific work remains.
Four Treating an existing application as worthless because it is old. Applications with years of real operational knowledge inside them are assets; the judgement is about support, deployment and reachable expertise, not age.

Note eight

Questions worth asking before you commission

If a question you came with is not answered here, write it in. Guides on this page started as questions asked in scoping calls, and the ones we can answer usefully in writing tend to end up as notes.

Contact the studio

Do these guides apply to any desktop project?

They are written from Windows-first project work with UK businesses, so the packaging and deployment sections assume that environment. The framework comparison is general and useful regardless.

Can I ask about a topic not covered here?

Yes. Questions from scoping calls often become guides. Send a note through the contact page and, if it is a question we can answer usefully in writing, it may appear here.

How often are new guides added?

When a question comes up often enough in scoping work that writing it down once saves the next caller time. There is no fixed schedule and no editorial calendar behind the page.

Do these notes replace a proper scoping call?

No. They are meant to shorten it. A scoping call looks at your specific application, your users and your deployment environment, and the useful output is a shortlist of two or three options with reasons — which is what the notes help you prepare for.

Next step

If a note raised a specific question about your application, ask it before you scope anything.

A short call about the framework, the packaging route or the deployment target usually shortens the written scope, and it saves the back-and-forth that a wrong assumption would have cost.

Talk through your project See the services Compare the stacks

Studio bench

Elmhurst Enterprises

8 Mill Lane, Calcot, Reading, England

Monday to Friday, 9:00 AM – 6:00 PM