Should your web app also ship desktop and mobile apps?

In February 2026, a Hacker News thread (opens in a new tab) asking "Why is Claude an Electron app?" drew 428 points and 458 comments. Drew Breunig's post (opens in a new tab) behind it asked the question plenty of web app teams are weighing now: "If code is free, why aren't all apps native?" A coding agent can turn a web app into a macOS, Windows or iPhone client in days, so shipping all three looks like the obvious next step. It isn't, for most products. The agent writes the first version, and then every release has to be signed, reviewed, updated and tested on each client for as long as the app exists. The web app vs desktop app guides I found ranking today compare platforms for someone choosing one, and skip what a second or third client costs to keep.

TL;DR: Ship a desktop or mobile app only when it does a job your web app can't, your users need that job regularly, and it runs on the same backend as the web app. Coding agents make the first build cheap. Signing, store review and updates still happen on every release, and no agent skips Apple's review queue.

Do coding agents make native apps free?

Coding agents make the first version of a native app cheap, and the rest of its life still needs an owner: every release gets signed, reviewed and shipped again. Breunig's argument was that one spec and one test suite could now produce a native client per platform. His own answer to why that hasn't happened: agents are "really good at the first 90% of dev," and the last stretch, edge cases and support once the app meets real users, stays hard.

The Claude Code team answered in the thread. Boris Cherny (opens in a new tab) said some of the engineers who built the app had worked on Electron, and that "it's also a nice way to share code so we're guaranteed that features across web and desktop have the same look and feel." A company whose product writes code for a living still chose one shared codebase over three native ones, and the reason it gave was keeping web and desktop in step.

Another commenter summed it up in four words: "Free as in puppy." You get it for nothing and feed it every day after.

What does a desktop app cost you after launch?

A desktop app costs you a release pipeline. Electron's own runtime, before a line of your code, is a 120.8 MB download (opens in a new tab) for Apple Silicon Macs and 158.2 MB for 64-bit Windows in version 45.2.1. Tauri (opens in a new tab), which uses the operating system's web renderer instead of shipping Chromium, says an app can be as small as 600KB. Size is what Hacker News argues about, and it matters less than what happens on release day.

On release day, a Mac app has to be code signed and then notarized by Apple, which needs an Apple Developer Program (opens in a new tab) membership at 99 USD a year. Electron's docs (opens in a new tab) are blunt about updates: "Squirrel.Mac requires the app to be signed for automatic updates to work at all." Squirrel.Mac is the updater Electron uses on macOS. So you also run an update feed, Windows signing and a build for each architecture, and you test the packaged app as well as the website.

A web app ships when you deploy. A desktop app ships when your users restart it, so bug fixes reach people on their schedule, and you support last month's version alongside today's. That last part is the one I'd budget for first. An agent can write a fix in minutes, and it still sits on a user's machine as last month's build until they restart.

What does a mobile app cost you after launch?

A mobile app puts a reviewer between you and every release. Apple's App Review (opens in a new tab) "typically" handles at least 50% of submissions in under 24 hours and 90% in under 48 hours. A web fix goes live when you deploy it. A fix in your iPhone app goes out when review clears it, and then when each user updates. Google Play (opens in a new tab) adds its own console and a US$25 registration, so two stores means two sets of rules and listings to keep current.

The cheapest mobile app an agent can write is the one Apple is most likely to turn away. Guideline 4.2 (opens in a new tab) says: "Your app should include features, content, and UI that elevate it beyond a repackaged website." A web view around your site with an icon on top is the obvious target of that line. Plan for the app to offer something the site it wraps doesn't, or expect a rejection under that guideline.

What can your web app already do?

Your web app can already do several of the jobs that used to justify a native app. Since iOS and iPadOS 16.4, web apps added to the Home Screen can receive push notifications (opens in a new tab). A progressive web app (opens in a new tab) can be installed and run in its own window, like any other app on the device.

The browser still stops at the edges of the operating system. A desktop app can register a keyboard shortcut (opens in a new tab) that works "even if the app does not have the keyboard focus," as Electron's docs put it, and it can keep an icon and a menu in the system tray after the window closes. It can watch and write the user's own folders without asking each time. A web app can open a file the user picks, and the browser's own storage, the origin private file system, is "not visible to the user like the regular file system," in MDN's (opens in a new tab) words.

Those are the jobs worth a second client: something that keeps running in the background, lives in the operating system's menus and shortcuts, or works on the user's files without a prompt each time. If your reasons are "users expect an app" or "it would feel more native," and your usage data doesn't say otherwise, make the web app faster first.

When should your web app get a desktop or mobile app?

Your web app should get another client when it passes three tests. I've been building for the web since 2014, and these are the tests I'd hold any extra client to.

1. It does a job the browser can't. A global shortcut, a tray icon, background sync, working on local folders, hardware the browser doesn't expose. Name the job in one sentence. If the sentence is about how the app feels, it fails.
2. Your users need that job regularly. A feature people touch once a quarter rarely earns a release pipeline. Check your analytics or ask your heaviest users before you build.
3. It runs on the same backend. The client calls the same API your web app calls, and the business rules stay on the server, as they do for the web app. Reuse the web app's interface code where the platform allows, as the Claude team does with Electron. A client with its own copy of the business rules means every rule change gets made twice.

How do you add the second app without doubling the work?

Start from what you already have. Wrap the web app's code instead of rewriting it, keep every rule on the server, and give the new client a thin layer that only does the job the browser couldn't. Then decide who owns the release work before you write a line: the signing certificates, the store listings, the update feed, the review queue. If nobody owns it, the app falls behind the web version and users notice.

Run the packaged app in the same test suite as the web app. An agent that changes shared code needs to see the desktop and mobile builds break in the same run, or you'll find out from a store review or a user.

What to do before you build the second app

Write the job the new app would do in one sentence and show it to your five heaviest users. If they'd install something for it, build that one job as a thin client on your existing backend and ship it to them first. If they shrug, spend the week on the web app, which every one of your users already has open.

More posts on building software with coding agents are on the gabs.app blog. I'm a full-stack engineer and my work is on gabs.app; if you're hiring, the contact form comes straight to me.