Desktop App

Back when all software was installed software, nobody needed the phrase. A program meant something you downloaded and installed on your machine, and there was no reason to put "desktop" in front of it.

The name got tangled once web apps spread. One word, "app", came to cover three different things: something you open in a browser, something installed on a phone, and something installed on a computer. When a meeting produced "let's make that work in the app", one person pictured a browser screen, another a phone screen, and another an installer. Those three differ in how they're built, how they ship, and how long they take, so a team could spend two weeks building different things off the same sentence before noticing.

Desktop app is the label that settled in to keep the three apart. It didn't invent a new idea so much as name one that had always been there. That's why the phrase usually shows up in a discussion about which shell to build in, not about what the product does.

It covers three things a browser either can't do or does badly.

1. It uses the full capacity of the machine. Browsers fence off how much memory and processing a page can take, for safety. Editing an hour of video or holding tens of thousands of lines of code open strains that fence. If the same file takes 40 seconds to open in a browser and 4 seconds in installed software, someone who opens it twenty times a day loses 12 minutes a day to the difference.
2. It reaches local files and other programs directly. Watching a folder and uploading only what changed, handing work straight to another program without an export step, picking up what a different window is doing — all of that lives here. A browser only receives the one file a user picks, so it can't keep watching a folder.
3. It runs while sitting in the background. It stays in the corner of the screen, comes up on a keyboard shortcut no matter what else is in front, and keeps working when the connection drops. Editing a document on the subway and having it merge the moment the office network comes back is this capability.

There's a price. Every operating system needs its own build, its own signing, and its own release. On the web, pushing a fix means everyone is on the new version instantly; with installed software, a user has to accept an update. So there's always a group still on a version from six months ago, and a single bug fix takes weeks to reach everyone. Automatic updates help, but not at companies whose security policy blocks installs.

Three other shells can carry the same work.

1. A web app wins on having no install at all. One link brings someone in, one deploy finishes the job, and everyone runs the same version. You give up heavy processing and local file access, and you get a large cut in both build cost and maintenance cost.
2. A mobile app occupies a different place. It suits what happens away from a desk — getting a notification, checking something briefly, replying. Writing long documents or working through a spreadsheet rarely moves there even when it's offered.
3. A browser extension rides on top of someone else's web page that the user is already looking at. It takes over a little of the always-there quality of installed software, but its reach stops wherever the browser says it stops.

There's also the route of wrapping a web interface in a window and shipping it as an install. One build covers three operating systems, which is why small teams reach for it. What it buys is the background presence and the file access; speed stays roughly what it was in the browser. If heavy processing was the reason for going installed, this route doesn't solve it.

The choice isn't a matter of taste. It comes down to three things: where the user does this work, whether local files and raw performance are genuinely needed, and whether the team can carry one more shell. Five engineers running a web version and an installed version together usually leave one of them untouched for two months at a stretch.

"Local folder sync can't be done on the web. We need a desktop app."

Browser limits make the feature impossible as such, so the team has to take on another shell.

"On the desktop app side, 15 percent of accounts are still on last year's version."

Updates are in the user's hands, so old versions have to stay supported.

"Let's ship the desktop app on Mac first and look at Windows next quarter."

Each operating system is a separate build, so they can't all land at once.

Pagedeck started as a document tool used in a browser. Support tickets kept surfacing the same thing: teams that keep design files and documents in one folder were dragging files up one at a time and giving up partway. Adding a feature that watches a folder and uploads only what changed had no path through the browser.

Theo brought two options. Wrap the web interface in a window and ship it as an install, or build a small separate program that does nothing but sync. Mia picked the second. What they needed was folder watching, not performance, and splitting the editing interface into two builds is where features start drifting apart.

The most common mistake is reading installed software as a dated form the web has replaced. Most work tools did move to the browser, so it looks that way. But the territory the browser fenced off is still fenced off. Video editing, writing code, three-dimensional design, music production — anything that pushes a machine hard still lives in installed software, and collaboration tools keep shipping installed versions to get a window that's always there and files that connect. Rule it out as dated and you hand a competitor the thing a user opens every morning.

The other mistake is assuming that wrapping a web interface in a window makes it a desktop app in every sense. There's an icon, there's a window, so it looks the same. What actually changes is the background presence and file access; speed does not. Wrap an interface to answer complaints about performance and two months later the same complaints come back unchanged. Writing down what the installed version is supposed to buy you keeps this fork simple.