Sharing a codebase between a desktop app and its browser version does not halve the work. On Arti — our floor plan editor for macOS, which also runs in a browser — the product logic was reused unchanged, but the web version needed its own hosting work, its own crash reporting and its own loading constraints. The code shares; shipping does not.

This is written from one real case rather than from a principle. The figures below were measured on the live deployment, not estimated.

What actually shares

The short answer: nearly everything you wrote, and none of what surrounds it. On Arti the whole editor is common to both platforms — drawing rooms, doors and windows that cut real openings, 244 furniture pieces at real dimensions, the switch to 3D, the export. There is no second implementation to keep in step, and a fix made once holds for both.

What does not share is the layer that touches the system: where files live, how an export is saved, and how a crash is reported. Those three look like footnotes on a plan. They are where the time goes.

Storage changes meaning, and so does the copy

On the Mac, a plan is a file in the app's container: it survives an update, it goes into the Time Machine backup, it is yours in the plainest sense.

In a browser, the same plan lives in browser storage on that one machine. Nothing is uploaded — the promise that your data does not leave holds — but a user can wipe it without realising, by clearing site data. This is not a technical defect, it is a wording problem: the page has to say where the plan lives and what deletes it, or the promise becomes a trap. On Arti the sentence sits permanently along the top of the web editor.

That is the first thing to budget for on a second platform: not the code, the text that explains what the code does differently.

Weight, and why it is settled at the hosting layer

An app compiled for the browser arrives all at once. On Arti a cold load is 13.2 MB raw, 4.7 MB compressed — and that compression is not an optimisation, it is the difference between an app that starts and a blank page on a mediocre connection. Your host either provides it or you configure it; in our case the server serves Brotli, which is better again than gzip.

Two deployment consequences that are rarely discovered in advance:

• Nothing in a web build has a per-version filename. The main file is called the same thing in every release. Caching it for a year — the ordinary reflex for static assets — guarantees a returning visitor never receives the update. The correct rule is to revalidate: the browser keeps its copy and simply asks whether it is still good.
• The browser demands cross-origin isolation before it grants access to fast storage. Without two specific headers the app does not fail cleanly: it hangs at startup with an error that reads exactly like a missing file. It was the most expensive defect of the whole port to diagnose, and it does not reproduce locally.

Crash reporting does not exist on the web

On mobile and on Mac, the standard crash reporter is provided and wires up in a few lines. It has no browser implementation and never has had one — this is not a configuration gap, and no amount of setup closes it.

So we wrote our own: a route that receives an anonymous report, groups it by fingerprint so one error in a loop cannot bury everything else, and keeps it for ninety days. The report carries no identifier, no address and no plan content — a random session id is enough to tell "one person triggered forty errors" from "forty people triggered one", which are not the same bug and do not have the same fix.

Counting this piece as free because it is free on mobile is the most common estimating mistake on a cross-platform project.

What the web version buys

A link. That is all of it, and it is a great deal: someone hesitating can try the whole application, with no install and no account, from the page that describes it. Not a cut-down demo — the same app, the same catalogue, the same export.

For a product sold by download, that moves the visitor's question from "do I want to install this?" to "does it do what I need?". The second one answers itself in two minutes.

Should you do it?

Three cases where the answer is an easy yes: your product is easier to try than to describe; your business users cannot install software freely; or your fix cycle is faster than an app store's review rhythm.

Three where it is no: you need hardware access a browser will not grant; your files are too large for browser storage; or your team cannot carry two separate releases, because that is what this is — one codebase, two deployments.

In short: budget the second platform at about a third of the first, not a tenth. The code genuinely shares. Hosting, wording and observability share nothing at all.

Arti is at artiplans.com, and the editor can be tried in the browser straight from that page.