A field-services company with engineers across three countries decides to retire its ageing Windows client and move everything to the browser. The web version ships on time and looks better than anything the old client ever did. Then the engineers go back to work: half of their jobs are in plant rooms and basements with no signal, the thermal printers in the vans need a vendor driver, and the diagnostic devices connect over a serial cable. Six months later there is a “helper app” installed on every laptop to bridge the browser and the hardware, with its own installer, its own update problems and nobody who owns it. The company now runs a web app and a desktop app, and only one of them was designed.
The opposite story is just as common. A finance team has used a WPF application for a decade because “people like it”. Every release needs a packaging job and a change ticket, a third of the fleet runs last year’s version, and a bug fixed on Monday reaches users the following month. Nothing in the application needs the desktop: it is forms and reports over a central database.
This article is for CTOs facing the “desktop or web” decision, or who already know they need a desktop client and are choosing the technology. It defends two positions a competent reader could reasonably dispute. First: in 2026 a desktop application beats the web in only four specific situations, and outside them it is an expensive habit. Second: when the desktop is justified, the first decision is not the UI framework but how the application will be distributed, signed and updated. That is the part that consumes budget for years, and the Electron-versus-Tauri debate is secondary to it.
Why is the desktop question coming back in 2026?
For a decade the default answer has been to build in the browser. A web application needs no installation, updates on refresh, runs on any operating system and never needs administrator rights. That answer was right for most business systems and still is.
The question is returning for several reasons. Cross-platform tooling has matured. Electron, which according to its documentation bundles Chromium and Node.js into its binary and produces apps that run on Windows, macOS and Linux, now underpins many widely used tools. Tauri 2.0, released on October 2, 2024, extended the framework from desktop to iOS and Android. Flutter compiles native desktop apps for Windows, macOS and Linux. Shipping on three operating systems no longer means three teams.
The Windows estate is changing too. According to Microsoft’s lifecycle page, Windows 10 Home and Pro reached end of support on October 14, 2025. Organisations replacing hardware and images are reviewing their old desktop applications and asking what to do with them. (Migrating legacy .NET Framework applications deserves its own article; this one is about the decision for a new application.)
Local processing matters again in more places: very large files, hardware integration in manufacturing and logistics, AI models running on the device, environments with poor connectivity. Some of this can be done in a browser, some cannot.
Finally, the cost of distributing desktop software has gone up, not down. Code signing requirements have been tightened, and operating systems increasingly block unsigned files. In the EU there is a further consideration: the Cyber Resilience Act, which entered into force on December 10, 2024, covers software products with digital elements, with reporting obligations applying from September 11, 2026 and the main obligations from December 11, 2027. An installed application you ship to customers is a product you will have to support with security updates. None of this argues against the desktop by itself, but all of it argues for making the decision deliberately rather than by habit.
When does a desktop application still beat the web?
A simple test works well: a desktop application is justified when at least one of four conditions holds. If none of them does, the burden of proof sits with the desktop.
Condition one: hardware and the file system. The application must talk to a device or to the operating system in a way the browser does not allow, or allows only in some browsers. Typical examples: label and receipt printers with vendor drivers, card and barcode readers, measuring instruments on serial ports, document scanners, industrial cameras, folders with thousands of files, and integration with other programs installed on the same machine. Browsers have APIs for some of this, but availability depends on the browser and vendor drivers are out of reach entirely.
Condition two: offline as the normal mode. Not “the connection sometimes drops”, but working without a network as the expected state: an engineer in a plant room, an inspector on a construction site, a store with an unreliable line, a vessel, a mine, a shielded factory floor. Offline web apps are possible, but their cost rises quickly once data is edited locally for hours and then merged.
Condition three: local performance on large data. Medical imaging, CAD models, multi-gigabyte files, video, simulations, a local database with millions of records and an interface that must respond instantly. Browsers now have WebAssembly and GPU access, but a native application still gives more control over memory, threads and disk access.
Condition four: control over the environment. The organisation must know exactly which version of the application and which rendering engine runs on a given workstation, because validation, certification or regulation requires it. Or the opposite: the workstation is locked down, has no browser and no internet access, and the application has to behave like an appliance.
Notice what is not on the list: “a better look”, “faster” ordinary forms, or “users are used to it”. A modern web application can look and respond as well as a desktop one, and user familiarity is an argument for good interface design, not for a particular platform.
When is the desktop an expensive habit rather than a need?
When the application is essentially forms, lists and reports over a central database, and users work on a stable connection, the desktop almost always loses on total cost of ownership. Every release must reach every machine. Every operating system and version is another configuration to test. Every change of signing certificate risks users seeing a security warning.
The most expensive symptom of the habit is a fragmented fleet. Without automatic updates, after a year some workstations run the current version, some the previous one and a few a version two years old because someone switched updates off “temporarily”. The team then has to keep the server compatible with several client versions at once, and every bug report starts with “which version do you have?”.
The second symptom is hidden support cost. In a web application, a bug fixed in the morning is fixed for everyone by the afternoon. In a desktop one, the fix needs a new build, signing, distribution and waiting for users to restart. If your TCO comparison leaves this out, it is incomplete. We cover the costs that only appear after go-live in more detail in our piece on total cost of ownership for software.
There is also a middle case that often leads to the wrong decision: the application is 90% an ordinary business system and 10% hardware. Instead of building the whole thing as a desktop client, consider a web application with a small, deliberately designed local component that handles only the hardware. That is the “helper app” from the opening story, except planned from day one with its own signing and update process. It can be cheaper than a full desktop client, but only if it really stays small.
Is a progressive web app enough instead of an installed application?
A progressive web app (PWA) is a tempting compromise: it runs in the browser but can have its own window, icon and cache for offline work. On macOS, since Safari 17 any website can be added to the Dock, and according to the WebKit blog it then always opens in its own window as a web app, even without a manifest file. Chrome and Edge have supported installable PWAs for years.
The limits appear with files and hardware. The File System Access API, which lets a page open a user’s file or folder and write changes back, is supported according to caniuse.com in Chrome (fully from version 105) and other Chromium-based browsers, but not in Firefox or Safari. MDN also describes the origin private file system (OPFS), a performance-optimised store visible only to the site, but that does not replace working on the user’s own files. Device APIs follow the same pattern: caniuse.com lists WebUSB in Chrome since version 61 but not in Firefox or Safari, and the serial and Bluetooth APIs are similarly limited to some browsers. Vendor drivers are not reachable at all.
The practical conclusion: a PWA is enough when the company controls the browser on its workstations (for example, managed Edge or Chrome everywhere), the application needs file access but not drivers, and offline work means viewing and brief edits. It is not enough when users are on Macs with Safari and need file access, when a device needs its vendor driver, or when offline means hours of editing followed by a merge.
One more argument for PWAs in internal tools: the entire signing and distribution process described below disappears. That is often the biggest saving in the whole project.
Which desktop technologies are realistic options in 2026?
If the test above points to the desktop, narrow the choice to seven options. Each has a natural area of use.
WPF and WinForms (.NET). Mature Microsoft technologies for Windows-only applications, running on modern .NET. A huge base of libraries, commercial control suites and developers who know them. A sensible choice when the application only needs Windows and the team knows C#. Mind the .NET support cycle: under Microsoft’s policy, LTS releases get three years of free support and STS releases two. .NET 10 (LTS) was released on November 11, 2025 and is supported until November 14, 2028, while .NET 8 and .NET 9 both reach end of support on November 10, 2026. A new application should start on .NET 10.
WinUI 3 (Windows App SDK). Microsoft’s newer UI layer for Windows, matching the Windows 11 look. Like WPF, Windows only. It makes sense when the application should feel like part of the modern operating system and use its newer features.
.NET MAUI. Microsoft’s cross-platform framework. According to its documentation it targets Android, iOS, macOS 12 or later via Mac Catalyst, and Windows 11 and Windows 10 from version 1809, where it uses WinUI 3. It does not target Linux. It makes sense when one C# codebase must cover Windows, Mac and mobile devices.
Electron. An application written in web technologies (HTML, CSS, JavaScript) with its own copy of Chromium and Node.js. It behaves the same on Windows, macOS and Linux, lets you share code with a web application and use a front-end team. The price is package size, memory use and the obligation to keep up: according to the project’s documentation, a new major version ships every eight weeks and the Electron team supports the latest three stable majors.
Tauri. Also a web-technology interface, but without a bundled browser: it uses the WebView already on the system, with a native layer in Rust. Its documentation says a minimal app can be under 600 KB. Since version 2.0 it also targets iOS and Android.
Qt. A mature C++ framework (with QML or widget-based interfaces), long used in industrial, medical and automotive software and anywhere performance and proximity to hardware matter. Available under a commercial licence or LGPL v3 (some modules only under GPL v3), which has consequences discussed below.
Flutter desktop. Google’s framework in Dart, which according to its documentation compiles native apps for Windows, macOS and Linux. It draws the interface with its own engine, so it looks identical everywhere. The natural choice when the company already has a Flutter mobile app and wants a desktop version.
A note on Qt licensing, because it is often misunderstood. Using Qt under LGPL v3 in a proprietary product is possible, but the licence’s “Combined Works” section requires, among other things, that you either use a shared library mechanism that works with a modified, interface-compatible version of the library, or provide equivalent means for relinking. For locked-down devices, “Installation Information” obligations can also apply. Have legal counsel review this before you commit, and budget for a commercial licence if compliance would be impractical.
How do these technologies compare side by side?
The table below organises the options by the criteria that decide the choice in practice. It describes typical characteristics, not benchmark results for a specific application; size and memory use depend on what the application does.
| Technology | Operating systems | Language and skills | UI engine | Main strength | Main risk |
|---|---|---|---|---|---|
| WPF / WinForms | Windows | C#, .NET | native Windows | maturity, libraries, available developers | Windows only, older look |
| WinUI 3 | Windows | C#, C++ | native Windows | Windows 11 look and features | Windows only, smaller control ecosystem |
| .NET MAUI | Windows, macOS, iOS, Android | C#, .NET | native controls per platform | one codebase with mobile | no Linux, platform differences |
| Electron | Windows, macOS, Linux | JavaScript/TypeScript | bundled Chromium | identical rendering, shared web code | size, memory, majors every 8 weeks |
| Tauri | Windows, macOS, Linux, iOS, Android | web front end + Rust | system WebView | small package, permission model | WebView differences, Rust skills |
| Qt | Windows, macOS, Linux, embedded | C++, QML | own | performance, close to hardware | licensing, C++ talent availability |
| Flutter desktop | Windows, macOS, Linux | Dart | own engine | consistency with Flutter mobile | smaller desktop plugin ecosystem |
A simple heuristic follows. Windows only and a .NET team: WPF or WinUI 3. Windows, Mac and mobile in one C# codebase: .NET MAUI. Three desktop operating systems and a web team: Electron or Tauri. Close to hardware, demanding performance or embedded targets: Qt. An existing Flutter mobile app: Flutter desktop.
The heuristic does not replace asking who will maintain the application for the next five years. A technology that nobody in the company or at the vendor knows well is a risk whatever its technical merits. If you are also considering a shared component library for web and desktop, check first whether the scale justifies it; see our analysis of design system cost and payback.
Electron or Tauri: what do you really gain with the lighter framework?
This is the most common debate for applications with a web interface, and it is worth taking apart, because each side is right about different things.
The case for Electron is predictability. The application always renders in the Chromium version you bundled. A rendering bug you see on Windows is the one you will see on Mac and Linux, and you test the interface once. The ecosystem is enormous, and a front-end team can build the application without learning a new language. The Node.js layer gives access to the file system, processes and native libraries.
The case against Electron is weight. Each application carries its own browser engine, which shows in installer size and memory. More important for a CTO is the pace: with a new major version every eight weeks and support for the latest three, an application that goes without an engine update for roughly half a year falls outside the support window. Every Electron upgrade is a new Chromium, meaning security fixes but also potential behaviour changes that need testing. That cost belongs in the maintenance budget from day one, not as a surprise in year two.
The case for Tauri is footprint and a security-first design. No bundled browser means small installers, and the Rust native layer brings memory safety. Its update mechanism is built on signatures from the start: the updater plugin documentation states plainly that a signature verifying the update’s origin is required and cannot be disabled.
The case against Tauri is dependence on the system WebView. According to Tauri’s documentation that is WebView2 (Edge, Chromium-based) on Windows, WebKit through WKWebView on macOS, and WebKit through webkit2gtk on Linux. Three engines mean three sets of rendering and feature differences, so interface testing must happen on each operating system. On Windows there is also the question of whether the WebView2 runtime is present: Microsoft’s documentation says the Evergreen runtime is part of Windows 11 and already installed on the vast majority of Windows 10 devices, but not all, so the installer should check. Skills are the second issue: some native logic has to be written in Rust, and Rust developers are scarcer than JavaScript developers.
How to decide? For managed corporate workstations where memory is not a constraint and the team is web-focused, Electron carries less project risk. For an application distributed to a wide external audience, where download size matters and the team is willing to invest in Rust and testing on three engines, Tauri makes the better product. Either way, the release pipeline will drive maintenance cost more than the framework.
Why do distribution and code signing cost more than the interface?
This is the core of the second thesis. You build the interface once and evolve it. You run the distribution pipeline on every release, on every operating system, for the life of the application. If it works badly, users see security warnings, administrators block installation and every fix reaches people late.
Windows. Microsoft Defender SmartScreen evaluates downloaded files by publisher reputation and file hash reputation. According to Microsoft’s documentation, an unsigned application triggers the “Windows protected your PC” warning and the user must choose to run it anyway, while enterprise policy can block that entirely. Even a signed new application can show a warning until it builds reputation, which the same page says can take several weeks and hundreds of clean installs. One change many organisations have missed: EV certificates no longer bypass SmartScreen, and Microsoft says paying a premium for EV solely to avoid warnings is no longer justified. Apps distributed through the Microsoft Store are re-signed by Microsoft and do not trigger the warning. Outside the Store, Microsoft recommends Artifact Signing (formerly Trusted Signing), which its documentation lists from USD 9.99 a month and which integrates with CI/CD pipelines without a hardware token.
The Windows package format is MSIX. According to Microsoft, it provides clean install and uninstall, differential updates (only changed 64 KB blocks are downloaded) and deployment through Intune and Configuration Manager, and every MSIX package must be signed before installation. On Windows 11 there is also Smart App Control, which Microsoft says blocks unsigned files that lack positive reputation.
Certificates and keys. Under the CA/Browser Forum code signing requirements, since June 1, 2023 subscriber private keys must be protected in a hardware crypto module. For certificates issued on or after March 1, 2026, the validity period must not exceed 460 days. In practice, the key can no longer sit in a file on a developer’s laptop, and renewing the certificate becomes a roughly annual event your release pipeline must plan for.
macOS. According to Apple, Gatekeeper checks for a Developer ID certificate on apps distributed outside the Mac App Store, and by default accepts software signed by a registered developer and notarised by Apple. Only the Account Holder of the team in the Apple Developer Program, which costs USD 99 a year, can generate the Developer ID certificate. Notarisation means submitting the signed app to Apple’s automated service, which scans it and issues a ticket Gatekeeper recognises. Since November 1, 2023, the notary service only accepts uploads through notarytool (or Xcode 14 and later). For budgeting: notarisation needs access to the Apple account and a macOS machine in the build pipeline.
Linux. There are several channels (distribution packages, AppImage, Flatpak, Snap), each with its own rules. If Linux is not a business requirement, decide explicitly not to support it rather than supporting it “along the way”.
Who owns all this? Ask that before choosing a framework. The Apple account, the Windows signing certificate or service, the hardware key module, the CI/CD pipeline that builds and signs every platform’s release, the renewal procedure, the procedure for a compromised key. These belong in the vendor contract, together with who owns the accounts and keys. If they belong to the vendor, changing vendors means changing publisher identity, losing SmartScreen reputation and warnings for your users. We discuss how to avoid that kind of dependency in our article on avoiding vendor lock-in.
How do you design updates so the fleet does not drift across five versions?
Updates are where the desktop most often loses to the web in practice, though it does not have to. Several decisions belong in the architecture phase.
Update channel. Each technology has its own mechanism. According to Electron’s documentation, the officially supported option is the built-in autoUpdater module based on the Squirrel framework, and the Electron team runs update.electronjs.org, a free service for open-source apps that requires code-signed builds on macOS. Tauri has an updater plugin with mandatory signatures: a private key signs the bundles and a public key in the app configuration verifies them. The documentation warns that losing the private key means you cannot publish updates to existing installations, which makes key custody a business continuity issue, not a developer detail. MSIX packages can update through App Installer without the Store, or through fleet management tools.
Version policy. Decide in advance how many client versions the server must support at once, and enforce it. A common pattern: on start-up the application checks the minimum supported version and, if it is older, forces an update with a clear message. Without this, the server has to stay backward-compatible forever.
Release rings. A pilot group gets new versions a few days before everyone else. It is the cheapest protection against a bug that stops the whole company working. In managed environments, these rings can be defined in Intune or similar tools.
Dependencies with their own cycle. In a desktop application, the engine ages alongside your code. In Electron, that is Chromium, updated with the framework. In Tauri and WinUI apps using WebView2, the system updates the engine: according to Microsoft, the Evergreen WebView2 runtime updates automatically, but the application only uses the new version after it restarts. An application running for weeks without a restart, such as a kiosk or a front-desk terminal, may keep running an older engine with an unpatched vulnerability unless it handles the new-version event. In .NET, it is the LTS and STS cycle described above.
Observability. Version telemetry (how many workstations run which version) and crash reporting broken down by version and operating system are the only way to know whether the update policy works. Without them, you find out about a drifting fleet from an escalation.
Well-designed updates shrink the gap between desktop and web in time-to-fix from weeks to hours. Badly designed ones are the main reason organisations decide a few years later to “move everything to the browser”.
How do you design offline work and data synchronisation?
If offline work is the reason for choosing the desktop, offline, not the interface, is the hardest part of the project. Three decisions drive the cost.
What is the source of truth. In the simplest model the server is the source of truth and the application keeps a read-only local copy refreshed when connected. Cheap and safe. In a local-edit model, the application writes changes to a local database (often SQLite) and sends them once the connection returns. More expensive, because conflicts must be resolved.
How conflicts are resolved. When two people offline change the same record, something must decide which change wins. Options: last write wins (simple, but loses data), field-level merging, a conflict queue for users to resolve manually, or data structures designed to merge automatically. The choice depends on how often conflicts occur and what a lost change costs. In an inspection system, a lost entry can have legal consequences; in a local order basket, a simple rule will do.
How long a workstation may stay offline. That number belongs in the requirements. One architecture handles an hour without a network, another a week. Security depends on it too: a local database with personal data needs encryption (and under GDPR you will have to explain that protection), and permissions cached locally must expire, so a departed employee does not keep access for a week just because their laptop never reconnected.
Design the data model for offline work at the very start. Adding local editing to an application designed as “always online” is effectively a rebuild of the data layer, not a new feature. If the application serves several business customers with data separation, the related decisions are covered in our article on SaaS architecture, multi-tenancy and data isolation.
What changes when the application needs hardware and deep OS integration?
Hardware integration is the second most common reason to choose the desktop and a source of risks that never show up in interface mock-ups.
Vendor drivers and SDKs. Industrial, medical and point-of-sale devices often come with their own libraries, usually for Windows, sometimes for a single processor architecture. That can decide the technology: if the vendor ships a .NET or C++ SDK, the simplest integration is from a .NET or Qt application. Electron and Tauri can do it too, but through an extra layer (Node.js native modules or Rust code) that someone has to maintain.
Processor architectures. ARM-based computers are increasingly common on both Apple and Windows hardware. If a vendor SDK exists only for x64, the application on ARM will run under emulation or not at all. Check this before choosing hardware and technology, not before rollout.
Permissions and isolation. Operating systems increasingly isolate applications. On macOS, access to the camera, microphone, certain folders or accessibility features requires user consent. On Windows, MSIX-packaged apps can run in a lightweight container with file system and registry virtualisation. Good for security, but an application that worked in testing with developer permissions may not work for a standard user.
The test matrix. Every combination of operating system, version, architecture and device is a potential test case. During planning, define which combinations are officially supported and which are not, and plan test stations with real hardware. An emulator will not reveal the printer driver issue that only appears on the hundredth print.
This part of the project rewards a short discovery stage before the main build: a prototype that connects to every device on the list, on the target operating system. It costs a fraction of the budget and removes the risk that the chosen technology cannot handle a critical device.
What does desktop development cost, and how do you choose a desktop application development company?
A desktop application’s cost depends on the same factors as any software (scope, integrations, quality), plus three items that a web application lacks or has in smaller measure: supporting several operating systems, the signing and distribution pipeline, and testing on real hardware.
An illustration, not a quote. A team of two senior full-stack developers, a senior QA engineer and a half-time DevOps engineer responsible for the build and signing pipeline. According to ARDURA’s pricing, a senior full-stack developer costs EUR 355-500 per day, a senior QA engineer EUR 335-465 and a senior DevOps engineer EUR 370-520. At the midpoints and 21 working days a month: two developers come to about EUR 17,950, QA about EUR 8,400 and half a DevOps engineer about EUR 4,670, roughly EUR 31,000 a month in total. Add fixed platform costs: USD 99 a year for the Apple Developer Program, the Windows signing service and test stations with the target hardware.
How should you read that number? The share of DevOps and QA is higher than in a typical web application precisely because of distribution and the test matrix. If a proposal for a desktop application on two or three operating systems includes nobody responsible for the release pipeline, that cost has not disappeared; it will reappear as manual releases and security warnings on users’ screens. General estimation principles and engagement models for custom software are covered in our guide to custom software development.
When choosing a desktop app development services provider, ask questions that separate desktop experience from web experience:
- What does your build and signing pipeline look like for each target operating system, and where are the keys held?
- Under whose accounts (Apple, Windows signing service) will the application be published, and how is ownership handed over at the end of the engagement?
- Which update mechanism do you propose, and how will you enforce a minimum client version?
- How do you test on real hardware, and on which operating system and architecture combinations?
- How will engine updates (Chromium, WebView2, .NET) be covered in the maintenance budget?
- Which offline model and conflict resolution approach do you propose for our case, and why?
A good answer to these questions is concrete and refers to decisions, not to a list of technologies in a portfolio. If you are replacing an existing desktop system piece by piece rather than all at once, the strangler fig pattern is a useful frame for planning the transition.
What are the key takeaways before you decide on a desktop application?
In 2026 a desktop application is neither a relic nor a default. It is a tool for four specific jobs, and outside them it costs more than a web application and delivers less.
Remember six things. First, check the four conditions: hardware and file system, offline as the norm, local performance on large data, control over the environment. If none applies, build in the browser. Second, consider the middle path: a web application with a small local component for hardware, or a PWA where you control the browser. Third, choose the technology by target operating systems and the skills of the team that will maintain it for years, not by popularity. Fourth, design distribution and signing before the first line of UI: accounts, keys in a hardware module, certificates renewed at most every 460 days, notarisation on macOS, MSIX or the Store on Windows. Fifth, design updates with an enforced minimum version, a pilot ring and version telemetry. Sixth, if offline or hardware is the reason, start with a prototype that solves exactly that problem before investing in the rest.
If you are weighing desktop against web, or choosing a technology for an application that must run on several operating systems and work with hardware, see how we approach custom software development, or book a call. Every project starts with a one-to-two-week discovery phase that ends with a scope and an architecture, including the decision on platform, distribution and updates.