Web app to desktop app: choosing the route on a Mac

Turning a web app into a desktop app means one of two quite different jobs, and the right route depends on which one is on the table. If the goal is to ship a desktop version of a product to its users, the work is a build: a framework such as Electron or Tauri, a code signing certificate, and an update system, with costs that start at Apple's $99 a year developer membership. If the goal is simply to use a website as an app on one's own Mac, no build is needed at all. Chrome's Install page as app, Safari's Add to Dock, or a tool that turns a website into a standalone Mac app produces a Dock icon and a window without tabs in a minute or two.

The two jobs share one question that decides whether the result still works a year later: who keeps it running when the browser engine underneath changes. The sections below take the builder's route first, then the user's routes, and compare them on that question. Prices and project status were checked on the official pages on October 18, 2026.

Two jobs that share one search

The pages that rank for this query show the split clearly. Electron's homepage and ToDesktop's pricing sit next to forum threads asking how to turn a website into a desktop app on Windows or Mac, and a thread pointing out that Chrome can install any tab as an app. One group is writing software for other people. The other wants a better window for software that already exists.

	Shipping a desktop app to users	Using a site as an app on one Mac
Who does it	The product's developers	Anyone with a browser
Output	A signed installer for macOS, and often Windows and Linux	A small app in the Applications folder
Typical tools	Electron, Tauri, ToDesktop	Chrome, Edge, Safari, a site to app tool
Cost	Developer time, signing, update hosting	Free or a small one time price
Who maintains it	The development team, permanently	The browser maker or the tool

Mixing these up is the most common mistake. A person who only wants Gmail in its own window does not need Electron, and a company shipping a product to thousands of users should not rely on a browser shortcut. The rest of this page keeps them apart.

Shipping a desktop app: Electron and Tauri

For a team that owns the web app, the two frameworks that dominate the conversation take opposite approaches to the browser engine.

Electron embeds Chromium and Node.js inside every app. Its homepage describes the bundled Chromium as a stable rendering target, and notes that Electron releases major versions in lockstep with Chromium so security fixes arrive as soon as they are available. The cost of that design is that each Electron app carries its own copy of the browser engine, and the team must keep shipping updates to stay current with it.

Tauri does the reverse. It uses the operating system's own web renderer, which on a Mac is WebKit, the engine behind Safari. Its homepage says a Tauri app can be as small as 600KB, and that application logic is written in Rust, with any front end framework on top. The trade is that the app renders with whatever WebKit version the user's macOS provides, so behaviour can differ between macOS releases and from Chromium.

	Electron	Tauri
Browser engine	Bundled Chromium	The system web view (WebKit on Mac)
App size	Includes a full engine	Can be as small as 600KB, per the project
Back end language	JavaScript with Node.js	Rust
Engine updates	Shipped by the app team with each release	Arrive with macOS updates

Either way, a Mac app distributed outside the Mac App Store needs to pass Gatekeeper. Apple's Developer ID page explains that Gatekeeper checks for a Developer ID certificate on apps from outside the Mac App Store, and that apps should be submitted for notarization. Getting that certificate requires a membership in the Apple Developer Program, listed at $99 a year.

Paying someone else to run the build

The build, signing, and update pipeline is the part teams most often hand to a service. ToDesktop is one of the services that appear for this search. On its own page, as checked on October 18, 2026, the plans for teams that already have Electron code were:

Plan	Monthly price	Downloads per month	Build retention
Essential	$100	10,000	30 days
Performance	$300	30,000	60 days
Scale	$1,200	100,000	360 days
Enterprise	Contact sales	Unlimited	Unlimited

All plans list a 7 day free trial, with yearly billing shown at a 20 percent discount. The Essential plan includes code signing, native installers, and app updates for Windows, Mac, and Linux. Mac App Store and Microsoft Store distribution appears from the Performance plan upward. The same page points teams without Electron code, who only have a web app, to a separate product, ToDesktop Builder.

These numbers frame the real cost of the builder's route. The framework is free, but a desktop app is a product with its own release pipeline, update servers, and signing certificates that expire. That cost is justified when users need features a browser cannot provide: deep file system access, background processes, system tray integration, or offline operation. It is not justified to give one person a cleaner window.

Using a site as an app: the browser routes

For the second job, every major browser on the Mac already includes a way to install a site as an app, and none of them cost anything.

Chrome. Google's help page on installing web apps gives the steps: open the site, open the menu, choose Cast, save, and share, then Install page as app. On some sites an Install button appears at the right of the address bar. Installed apps are listed at chrome://apps, and the app runs on the Chrome profile it was created from, with its sign in and extensions.

Microsoft Edge. Edge is also built on Chromium and includes an equivalent feature for installing a site as an app, tied to the Edge profile in the same way.

Safari. Apple's page on Safari web apps says the feature requires macOS Sonoma 14 or later. In Safari, choose File, then Add to Dock. The web app is saved to the Applications folder in the home folder, and it shares no history, cookies, or website data with Safari, so sites need to be signed in to again. Its settings include the name, the start URL, the icon, whether navigation controls appear, and which Safari extensions are enabled for it.

These routes are where most people should start. They answer the question of who maintains the result very well, because the browser maker does. When Chrome or Safari updates, the installed apps update with it, with nothing to rebuild.

Their limits show up with daily use. Each Chrome app is tied to the profile it came from, so keeping two accounts of the same service open in separate apps means managing several Chrome profiles by hand. Safari web apps are isolated by design, which is good for privacy but means no shared sign in with Safari.

Using a site as an app: the generator routes

Between the browser shortcut and a full build sits a third group: tools that generate a Mac app from any URL. They exist because the browser routes leave out things people want, such as a separate profile per app created automatically, per app control over tabs and the address bar, or a choice of browser engine.

The history of this group is a lesson in the maintenance question. Nativefier was for years the best known open source generator, built on Electron. Its GitHub repository now carries a notice that it was archived by the owner on September 29, 2023 and is read-only, and the project marks itself as unmaintained. Every app it generated still contains the Chromium version that was current when it was built, and that copy never receives another update.

Newer generators take different routes to avoid that fate. Pake builds on Tauri and the system web view, and describes its installers as nearly 20 times smaller than Electron packages, typically under 10 MB. Other site to app tools on the Mac do not bundle an engine at all and instead launch the browser already installed, so the apps follow that browser's updates automatically.

Route	Engine	Who keeps the engine current	Profiles
Electron based generator (such as Nativefier)	Bundled Chromium	Nobody, once generated	One per app
Tauri based generator (such as Pake)	System WebKit	macOS updates	Depends on the tool
Generator using the installed browser	Installed Chromium browser	The browser maker	Per app, often automatic

The difference matters most for sites used every day and signed in for months. A generated app that carries a frozen engine slowly drifts out of date. One that runs on the installed browser stays exactly as current as that browser.

Which sites are worth converting

Not every site gains from its own window. The ones that do tend to share three traits: they stay open for hours, they hold state such as a draft or a signed in session, and they send notifications that matter. Mail, calendars, chat, project boards, analytics dashboards, and admin consoles fit. News sites and shopping sites, visited for a few minutes at a time, do not.

A useful test is whether the site already has an official desktop app. If it does and that app suits the Mac, the vendor is maintaining it, and that is the simplest answer. If it does not, or the official app requires a newer macOS than the Mac is running, a site in its own window is the practical alternative.

Before relying on any converted site, three quick checks catch most surprises. First, sign in and quit the app, then open it again, to confirm the session survives a restart. Second, allow notifications inside the new app window and send a test, because permission given in the main browser does not always carry over; Apple notes, for example, that a Safari web app must answer the notification request itself, not Safari. Third, open a link that the site normally sends to a new tab and see where it lands, since some routes open external links in the main browser and others keep them in the app. A route that fails one of these checks for a given site is usually fixed by trying another of the routes above, not by abandoning the idea.

For the sites that pass that test, a tool with presets saves the step of finding each URL and icon. The list of supported services shows which ones are preconfigured, and the guide covers how a generated app is created and kept current after browser updates.

What to change first

Decide which of the two jobs is actually on the table. To ship a product, start with Electron or Tauri and budget for signing and updates; to use a site as an app, install it from Chrome or Safari first, and move to a generator such as Kagemusha only when separate profiles per app or per app window settings are needed.