Companion apps get all the attention, but a large share of connected hardware still ships with a program that runs on a laptop. Not because the team was old-fashioned — because the job genuinely does not fit on a phone. A benchtop instrument streaming ten thousand samples per second, a machine controller that must keep running when the network drops, a configuration tool a field technician uses on a jobsite: none of those are improved by putting the interface behind a browser.

Where Desktop Software Genuinely Wins

  • High-rate data acquisition and analysis. When the product produces megabytes per minute, a native application with direct file access and real charting libraries handles it. A browser tab holding a hundred thousand points in memory does not.
  • Direct instrument control. USB, serial, GPIB, CAN, and vendor SDKs are reachable from a desktop process. Browsers can touch some of this through WebUSB and Web Serial, but only on Chromium, only over HTTPS, and only with per-session user consent — acceptable for a hobby tool, not for a lab workflow.
  • Air-gapped and offline environments. Defense facilities, hospital networks, manufacturing floors, and remote sites often forbid outbound connections entirely. Software that assumes cloud access is simply unusable there.
  • Dense, precise interfaces. Multi-window layouts, keyboard shortcuts, drag-and-drop against the local filesystem, and multi-monitor use are native strengths. Engineering and clinical users work faster in them, which matters when the tool is used all day.
  • Long unattended runs. A twelve-hour test that must not be interrupted by a browser update, a tab discard, or a sleeping laptop belongs in a native process with the appropriate power assertions.

Industrial equipment tends to hit several of these at once, which is why a PC-side application is close to standard in industrial machine development. Field service tooling hits a different subset, and often ends up as a second application entirely, along the lines discussed in user app and technician app.

How It Differs From an On-Device Web UI

Many products can skip desktop software by embedding a small web server in the device itself. The user connects to the product's own address, gets a full interface, and installs nothing. No signing, no notarization, no per-platform builds, no update distribution, and one codebase that works from a phone, a tablet, or a laptop. For configuration, status, and light control that is usually the correct answer, and the architecture is laid out in running a local web interface on a device.

The embedded server runs out of road in three places. It is limited by the device's own compute and memory, so heavy analysis is off the table. It cannot reach the user's filesystem, printers, or other instruments. And it cannot participate in a workflow that spans several devices at once. When any of those is central to the job, the desktop application earns its cost. When none of them is, it usually does not.

The Signing and Distribution Tax

This is the part that surprises hardware teams, because it is pure overhead that produces no feature.

Windows

An unsigned installer triggers a SmartScreen warning that stops a meaningful share of users cold. Avoiding it requires a code signing certificate from a recognized authority — roughly $300 to $600 per year, with extended validation options costing more — and current requirements keep the private key on a hardware token or in a cloud signing service rather than on a build machine, which complicates continuous integration.

Kernel-mode drivers are a much larger commitment. Any driver loading on modern Windows must be submitted through the Microsoft hardware developer portal for attestation or full certification signing, which means an enrolled company account, an EV certificate, and a submission cycle measured in days per revision. The strong recommendation is to avoid a custom driver entirely: design the product around USB CDC, HID, or WinUSB so a stock in-box driver serves you. That decision belongs in the electrical design phase, alongside the connector and protocol choices in USB-C in a new product.

macOS

Apple's path is stricter but more predictable. You need a paid developer account at $99 per year, a Developer ID certificate, hardened runtime enabled, and notarization — an automated Apple scan of every build before it will launch without a Gatekeeper block. Notarization typically returns in minutes and must be part of the release pipeline rather than a manual step someone forgets. Kernel extensions are effectively deprecated; anything needing low-level access should use system extensions or DriverKit, which run in user space and require a separate entitlement request from Apple.

Linux, by contrast, has almost no gatekeeping, but you inherit distribution fragmentation. Shipping AppImage or Flatpak sidesteps most of it.

Choosing a Framework

Electron gets a working cross-platform application fastest and lets a web team reuse its skills, at the cost of a bundle around 150 MB and noticeable memory use. Tauri produces far smaller binaries using the system webview, with a smaller ecosystem. Qt remains the default for instrument and industrial software, with genuine native performance, mature charting, and commercial licensing to evaluate. .NET with WPF or WinUI is the pragmatic answer when the customer base is entirely Windows, which for factory-floor and test-lab products it frequently is.

Pick on where the users are before picking on developer preference. A tool used by twenty metrology labs that all run Windows does not need macOS support, and building it anyway doubles the signing, testing, and support surface for nobody.

What It Costs to Own

A focused configuration and data-logging application typically runs $30,000 to $80,000 to build, and a full instrument control and analysis suite with plugin architecture runs well past that. Ongoing ownership is the number people miss: operating system releases break things annually, certificates expire, notarization requirements tighten, and each supported platform multiplies the regression testing. Budget fifteen to twenty-five percent of build cost per year, consistent with the pattern in annual software maintenance cost.

If the software is a revenue product rather than a giveaway, decide the licensing model early — node-locked keys, floating licenses, or subscription entitlement all change the architecture, as covered in licensing and subscriptions in product software. And if the desktop application interprets clinical data or drives therapy, it may itself be regulated, per software as a medical device.

Deciding What to Build

Projects House helps US product ventures decide between an embedded web interface, a mobile app, and a desktop application, then builds the one the job needs. Describe your product and who operates it through our contact form.