Yes, some jobs still need a desktop app: deep operating system integration, hardware connections, offline work, large local files, heavy performance needs, always-on background tasks and data that must stay on the device are all places where the web alone falls short. For most other business software, a web application ships faster and costs less to maintain.
Browsers have learned a lot in recent years: installable web apps, offline caching, fast code through WebAssembly. Still, a browser runs every site inside a security sandbox, and some doors stay closed on purpose. That is why the first question we ask on any desktop app development project is simple: can this be done in the browser?
What is the difference between a desktop app and a web app?
A desktop app is software installed on a computer that runs directly on the operating system. A web app runs in the browser and needs no installation. The real difference is the level of access. A desktop app can reach the file system, hardware, network and other applications, as far as the user allows. A browser isolates each site from the others and from the operating system.
The web has real advantages too:
- No installation; users click a link and start.
- Updates happen on the server, so everyone moves to the new version at once.
- The same code runs on Windows, macOS, Linux, tablets and phones.
- There are no installers, code signing or release distribution to manage.
So the default answer is often the web. Choosing desktop takes a concrete reason, and the seven cases below are the most common ones.
What are the 7 cases where the web falls short?
- You need deep operating system integration. System-wide keyboard shortcuts, an icon waiting in the system tray, starting at sign-in, window management or panels that open over other applications are out of reach for a browser. A browser tab only controls what is inside its own window. Our own Next Windows is an example: on Windows 10 and 11, it shows every virtual desktop with previews in a single Win+Tab panel and lets you drag windows between desktops.
- You need to talk to hardware and peripherals. Barcode scanners, receipt and label printers, card readers, scales, lab instruments and machines that speak over a serial port all belong here. Some browsers offer interfaces such as WebUSB and Web Serial, but support is not universal, and they do not help with devices that need a dedicated driver. At a checkout counter or on a production line, "it does not work in this browser" is not an option.
- A network connection is not guaranteed. Think of field teams, warehouses, construction sites or branches with patchy connections. Installable web apps can work offline to a degree. Keeping large datasets locally, working for days without a connection and resolving conflicting records when the connection returns are far more reliable in a desktop app with a local database.
- You work with large local files. Video editing, CAD drawings, medical images, high-resolution photo archives and gigabytes of logs are typical examples. Uploading these files to a server every time is slow and expensive. A desktop app opens files where they are and reacts to folder changes right away. Browser file access interfaces are improving, but consistent, persistent access is still limited.
- You need high performance and low latency. Real-time audio and video processing, 3D modeling, instant calculations on large datasets and control screens where milliseconds matter fall into this group. WebAssembly and WebGPU are narrowing the gap. Even so, direct access to every CPU core, the GPU and memory still gives native code the edge for this work.
- The app has to keep running in the background. A web page stops when its tab closes, and browsers throttle background tabs. Syncing folders, listening to a local service or showing notifications all day calls for an app that waits in the tray. Next Notify works this way: it starts at sign-in, waits in the tray or menu bar and sends a desktop notification when your AI coding agent finishes a task or asks for permission.
- Data must stay on the device or inside a closed network. Some organizations work on networks with no internet access, and some data must not leave the device because of regulation, contract or company policy. You can run a web app on a server inside a closed network. But where running a server is not possible, or data must stay on a single machine, a desktop app that processes data locally is often the only realistic path.
What these seven cases share is a need to step outside what the browser allows. Recognizing yourself in the list does not settle the desktop question on its own. It does show you in advance where the web will struggle, and that saves months spent on the wrong architecture.
Is there a middle ground?
The choice between desktop and web is not always all or nothing. Three middle paths are common:
- Progressive web app (PWA): the web app is added to the desktop with its own icon, opens in its own window and can work offline to a limited extent. Access to the operating system is still only what the browser permits.
- A desktop app built with web technology: frameworks such as Electron and Tauri run a web interface inside a desktop shell and add native capabilities, so your web team can build a desktop app too. We compare the options in Electron, Tauri or .NET.
- A web app plus a small local helper: the main app stays on the web, and a small program installed on the computer handles jobs such as talking to hardware or watching local files. This keeps the desktop burden limited to the part that truly needs it.
Which path fits depends on which of the seven cases apply to you. If you only need to reach a label printer, a small local helper may be enough. If the whole app must work offline for days, a full desktop app is the better call.
What are the hidden costs of a desktop app?
A desktop app costs more than its development. Factor in these items before you decide:
- Distribution: installers, a code signing certificate and Windows security warnings are a workstream of their own. We cover the details in Shipping a Windows App.
- Updates: on the web everyone runs the same version; on the desktop, users can stay on different versions. A reliable auto-update mechanism has to be in place from the start.
- Platform differences: Windows, macOS and Linux each need separate testing, separate packages and sometimes separate code.
- Version support: decide early how long you will support old versions and which operating system versions you target; that choice directly drives testing and support costs.
- User machines: different display scaling, security software, restricted user accounts and corporate policies all add to the support load.
Which questions should you ask before you decide?
Answer these with your team. If you say "yes" to two or more, take desktop seriously:
- Does the app have to talk to a device, a printer or other local software?
- Will users work without internet for long periods?
- Are gigabytes of local files or heavy computation involved?
- Should the app keep working when its window is closed?
- Must data stay on the device or inside the company network?
If every answer is "no," a web app is most likely the better, faster and more economical choice.
Default to the web; save the desktop for the places where the web truly falls short.
Frequently asked questions
Can a PWA replace a desktop app?
For simple tools, often yes. It offers a desktop icon, its own window and limited offline use. It falls short when you need hardware access, always-on background work or deep system integration.
Can one desktop app run on both Windows and macOS?
Yes. Frameworks such as Electron, Tauri and .NET MAUI let you target more than one operating system from a single codebase. You still need to plan testing, packaging and signing for each system.
Is a desktop app more secure than a web app?
Not by default. Keeping data on the device removes some risks, but lost devices, outdated versions and local permissions add new ones. Security depends more on the measures you apply than on the platform you pick.
Can we move our existing web app to the desktop?
In most cases, yes. Wrapping a web interface in a desktop shell takes far less time than a rewrite. The real work is adding native capabilities and building the distribution and update pipeline.
Does building a desktop app take longer?
Usually somewhat longer, because installers, code signing, an update pipeline and testing on each operating system come into play. The gap shrinks when the interface is built with web technology.
Where to start?
Start by listing the jobs your users cannot do in a browser today. Mark which of the seven cases apply to you and write a one-sentence scenario for each. That list makes it clear whether you need a desktop app, a web app or a mix of both.
If you are planning a desktop app or thinking about bringing your existing software to the desktop, get in touch.