Desktop Software for the Jobs a Browser Tab Cannot Do
Windows and macOS applications for offline work, connected hardware, heavy local files and kiosk screens — signed, notarized and updating themselves, because that is the part everyone forgets.
- Windows and macOS
- Signing set up in your name
- Auto-update from release one
What We Reach For, Depending on the Job
Does This Actually Need to Be a Desktop App?
We ask it on the first call, because the answer is no more often than people expect. A desktop application costs more to distribute than a web app: installers for each platform, certificates, an update mechanism, and support for whatever versions of Windows and macOS your users are running. If a browser can do the job, a browser is the cheaper answer and we will say so.
But there are jobs a browser genuinely cannot do, and for those a desktop application is not nostalgia — it is the correct tool. Reading a folder of ten thousand files. Talking to a scanner, scale, till drawer or lab instrument. Running full screen on a kiosk that has to survive a reboot. Working all day in a building with no reliable signal.
See what a web app can do insteadWhen Desktop Is Right, and When It Is Not
Offline is normal, not an edge case
Warehouses, basements, vessels, clinics, sites and rural routes. The application has to work all day with no connection and reconcile later.
Local hardware or the file system
Serial and USB devices, scanners, label printers, till hardware, lab instruments, or bulk work across thousands of local files and folders.
Kiosk and heavy local processing
A machine that boots into your software and stays there, or video, imaging and data crunching where uploading the input is slower than processing it.
Everything else, usually
Forms, dashboards, records, approvals and reporting used by people with a connection. No installer, no certificates, no version fragmentation, and one deploy updates everyone.
The Desktop Projects That Come to Us
Kiosk & Point of Sale
Full-screen software on a fixed machine, recovering cleanly from power loss, printing receipts and opening a drawer, and working when the line is down.
Hardware & Instrument Control
Reading from and writing to devices over USB or serial, capturing measurements, and translating a proprietary protocol into something your systems can use.
File & Batch Processing
Watching folders, converting and renaming thousands of files, merging exports, and producing the output a regulator or a partner insists on.
Offline Field Tools
Inspections, surveys and job sheets captured without a signal, stored locally, then synced with clear rules for what wins if the same record changed twice.
Data & Media Crunchers
Local video, imaging or dataset work where uploading is slower than processing, and the machine in front of the user is the fastest resource available.
Modernizing Old Desktop Software
The Access database, the VB6 tool or the unsupported application that still runs the business. Rebuilt without losing the years of data inside it.
Electron or Native, Stated Honestly
Electron gets defended and attacked with more heat than the decision deserves. Here is the actual trade, in the terms that affect your budget and your users.
| Question | Electron / Tauri | Native (.NET, Swift) |
|---|---|---|
| Both Windows and macOS | One codebase covers both | Two codebases, or one platform only |
| Time and cost to build | Lowest — often half the hours | Higher, roughly doubled if you need both |
| Installer size | Large — commonly over 100 MB for Electron, far smaller with Tauri | Small, typically a few megabytes to tens |
| Memory and startup | Heavier; each app carries a browser engine | Light and fast to start |
| Deep OS integration | Good for common needs, awkward at the edges | Full access to everything the platform offers |
| Finding developers later | Easy — it is web technology | Harder and more expensive, especially for macOS |
| Best when | Business software, both platforms, budget matters | Performance, tiny footprint or hardware depth matters |
Our default for business software on both platforms is Electron or Tauri, because the saving is real and the drawbacks rarely matter for an internal tool. When the application has to start instantly, sit in the tray all day on modest hardware, or drive a device closely, we build native and say why in writing. What we will not do is pick the stack we feel like using and present it as the only option.
How a Release Actually Reaches a User
This pipeline is set up before the first release, not discovered during it. It is also the part that surprises almost every client.
Build
One command produces the Windows installer and the macOS package from the same source, in a pipeline rather than on a developer laptop, so any release can be reproduced.
Sign
Windows needs a code signing certificate or SmartScreen warns people away. macOS needs an Apple Developer ID or Gatekeeper refuses to open the app. Both are annual costs bought in your name.
Notarize
Apple then has to scan and approve each macOS build before it will run on other machines. It is automated but it is a step in every release, and it fails in ways worth knowing about in advance.
Publish & Update
The signed build goes to your download page or release feed. Installed copies check it, update themselves quietly, and can be held back or rolled back if a release goes wrong.
Two details that catch people out. First, certificates expire — usually yearly — and an expired certificate means new builds stop being trusted, so the renewal has to sit with someone who will act on it. Second, auto-update has to exist in version one. If the first release cannot update itself, every later fix means personally asking each user to download an installer again, and some of them never will.
App Store or Direct Download
For business software the answer is usually direct. For consumer software it is usually the store. Sometimes it is both.
Direct download from your own site
- No commission and no store cut on anything you sell
- You release when you are ready, with no review queue in between
- No sandbox restrictions, which matters for hardware and file system access
- You control the update mechanism and can stage a rollout
- Cost: you provide the trust yourself, through signing and a credible download page
- Cost: no store search traffic — people find it because you told them about it
Microsoft Store and Mac App Store
- Familiar install and update path that non-technical users already trust
- Discovery from store search, which direct distribution never gives you
- Payment and refunds handled for you, for a percentage
- Cost: review before every release, and rules that can change under you
- Cost: sandboxing limits hardware and file system access on macOS particularly
- Cost: the store controls updates, so an urgent fix waits for approval
Whichever route you take, signing and notarization apply. They are what turn a download into something a user is willing to open.
Desktop Application Questions
When is a desktop app better than a web app?
When the software has to keep working with no internet, talk to hardware plugged into the machine, read and write large numbers of local files, take over the whole screen as a kiosk, or do processing heavy enough that shipping the data to a server is impractical. If none of those apply, a web application is usually cheaper to build and far cheaper to distribute, and we will say so.
Electron or native — which should we choose?
Electron when the same application has to run on Windows and macOS and the build has to be affordable: one codebase, web technologies, and a team that is straightforward to replace later. The honest cost is a large installer, typically well over a hundred megabytes, and heavier memory use, because every Electron app ships its own browser engine. Native is right when startup speed, memory footprint or deep operating-system integration genuinely matter, or when you only need one platform. We tell you which we think it is, and why, before you commit.
What is code signing and do we really need it?
Yes. An unsigned application shows a warning on Windows and is blocked by default on macOS. Signing means buying a certificate, and on macOS it also means submitting every build to Apple for notarization, an automated check that adds a step to each release. It surprises people because it is an annual cost and an ongoing process rather than a one-off task. We set it up in your name and document it, so releases never depend on us.
How do users get updates?
The application checks for a new version, downloads it in the background and installs it on restart. That goes in from the first release, because adding it later means asking every existing user to reinstall by hand. Updates are served from your own storage or a release service, releases can be rolled out gradually, and a bad one can be pulled back.
Can we distribute outside the Mac App Store and Microsoft Store?
Yes, and most business software does. You host the installer on your own site, people download it directly, and the auto-updater takes over from there. That avoids store commission, store review and store rules, at the cost of the discovery a store listing gives you. Signing and notarization still apply either way, because they are what make a direct download trustworthy rather than alarming.
Can the desktop app share data with a web version?
Usually yes. The common arrangement is a shared backend API with the desktop application keeping a local copy of the data so it works offline, then syncing when a connection returns. The sync rules — what wins when the same record was changed in two places — are a design decision we settle with you early, because they cannot be bolted on sensibly afterwards.
How much does a desktop application cost to build?
Most first versions land between roughly $15,000 and $70,000. The main drivers are how many platforms you need, whether hardware or heavy file system work is involved, and how much of the logic runs locally rather than on a server. Signing certificates, notarization and update infrastructure are small line items but real ones, and we list them separately instead of burying them in a total.
Often Built Alongside
Backend & API Development
The sync API behind an offline desktop tool, and the licensing or account checks it calls home with.
Learn moreIoT & Connected Devices
When the hardware is yours and needs a companion application on the machine next to it.
Learn moreCustom Business Software
If the real problem is an internal process rather than a platform, this is usually the better starting point.
Learn moreTell Us What the Machine Has to Do
Describe the hardware, the files or the offline days — we will tell you honestly whether it needs a desktop app, and what it would cost, within two business days.