PWAs on a Mac: what the free tier covers

The price question has an answer that surprises people who arrive at it from a comparison article. Turning a website into an app on a Mac costs nothing, using software already installed. Every paid product in this category is selling something on top of that baseline, not access to it. So the useful version of the question is not what does this cost. It is what does the free version leave out, and is any of it worth money in this particular case. That is answerable in an afternoon, and the answer differs sharply depending on how many sites are involved and who else has to use them.

The routes that cost nothing

Two ship with software most Macs already run.

Safari has had this since macOS Sonoma 14. File, then Add to Dock, then a name, then Add. The result is saved to the Applications folder inside the home folder and opens from the Dock or Spotlight. There is no account to create, no trial period, and no limit on how many can be made.

Chrome reaches the same place through the three dot menu at the top right, then Cast, save, and share, then Install page as app. Installed apps are listed at chrome://apps, where a right click offers Launch at startup. Edge and other Chromium browsers carry equivalent commands.

Neither route charges anything, and neither is a stripped version of a paid product. They are features of the browser. The distinction matters because the language around this topic borrows from software pricing, where a free tier usually means a deliberately limited edition of something commercial. Here the baseline is simply what the browser vendors chose to expose, and the ceiling is set by engineering priorities rather than by a pricing decision.

What the zero cost routes actually include

The list is longer than most people expect, which is why it is worth reading before paying for anything.

A real application bundle in the filesystem, not a bookmark. An icon in the Dock, in the application switcher, and in Spotlight search by name. A window with no address bar. Apple's documentation notes that a web app can be added as a login item so that it opens automatically at sign in, and Chrome's equivalent setting is the Launch at startup item at chrome://apps.

Names and icons are editable on the Safari route. Its settings panel, reached by clicking the app's name in the menu bar and choosing Settings, offers Application Name, Application URL, Icon, Show navigation controls, and Show color in title bar, plus Privacy and Extensions tabs.

Notifications and unread counts are included. Apple's documentation describes the Dock badge and the condition attached to it.

Web apps support an additional notifications feature: The number of unread notifications appears as a red badge on the app's icon in the Dock. To use this feature, respond to the website's notifications request in the web app, not in Safari. Source: support.apple.com

Session separation is included on the Safari route as well, since a web app keeps no browsing history, cookies, website data, or settings in common with the browser. On the Chrome route separation comes from profiles instead, which means creating one profile per account and installing from inside each.

A single person putting three or four daily sites into the Dock has no cost problem to solve. The free routes cover that case completely.

Where spending money starts to make sense

The gap is not in the individual features. It is in everything around making twenty of them, or making them for other people.

Setup time is the first pressure. Each app on the free routes is created by hand: open the site, invoke the command, type a name, then hunt for an icon because the favicon a site publishes is frequently a low resolution square that looks wrong at Dock size. Once is trivial. Twenty times is an afternoon, and the icons are the part that consumes it.

Browser lock in is the second. An app installed by a browser runs in that browser, and the same site installed from two browsers produces two apps sharing no data. Anyone consolidating a mixed setup has to pick a browser and redo the rest.

Link routing is the third. Standalone windows have no answer for where an outbound link should go. A link out of the app hands off to the default browser, and a link to the app's own site arriving from mail opens in that browser too rather than in the app.

Firefox users have a fourth pressure that is absolute rather than incremental. There is no install command in Firefox on macOS, and MDN records that Firefox requires a PWA extension for this. The free routes require adopting a second browser.

Shared machines add a fifth. The free routes assume the person creating the app is the person using it, because each app is built by hand on one Mac and lives in that account's home folder. A team standardising on the same five internal tools has no way to hand out a finished set. Everyone repeats the same twenty minutes, and the results diverge immediately: different names, different icons, different ideas about which URL is the right starting point. The cost being paid there is not licence money. It is the support time spent later working out why one person's window opens on a login page and another's does not.

A useful way to price all of this is to count the sites rather than the features. One site is free in every sense. Five is an hour spent once. Twenty, kept current across a team, is the point where a tool that builds them from a list stops being a convenience and starts being the only realistic way to keep them consistent.

What the paid tools charge

Prices below are what the vendors publish. All figures are from the product pages and are stated without recommendation.

Tool	Price	Structure	Stated requirements
Coherence X6	Starting at 39.99 USD	Buy once, optional paid upgrades, licence covers Coherence X 6.x only	macOS 13.5 or later, Apple Silicon and Intel
Unite Pro	Starting at 39.99 USD	Buy once, optional paid upgrades, licence covers Unite Pro 1.x only	macOS 15 or later
Fluid	Free, with a 5 USD licence	One time unlock for status bar pinning, userscripts and userstyles, full screen	Version 2.1, Mac OS 10.12 or later

Three details in that table matter more than the numbers.

The first is the phrase covering the version range. Both BZG products state that the licence applies to one major version, with optional paid upgrades afterwards. A one time purchase in this category is one time per major release, not once forever, and the interval between major releases is the real annual cost. Anyone budgeting should look at how often the version number has moved rather than at the sticker.

The second is the operating system floor. Unite Pro lists macOS 15 or later, Coherence X6 lists macOS 13.5 or later. Those floors rise with each major version, which is the mechanism that converts a purchase into a recurring one on older hardware.

The third is that both BZG products offer a free first app, so the decision does not require paying to find out whether the workflow fits.

The cost of building it yourself

Writing a wrapper is free in licence terms and expensive in every other term.

Nativefier was the reference tool for this for years. Its GitHub repository is archived and its last commit dates to September 2023, so anyone finding it in an older article is finding a project that is no longer maintained. Building on Electron or Tauri directly remains free and open source, and the runtime cost is a day of work per feature that the browser routes provide by default.

The unavoidable expense appears at distribution. An app built locally and run only on the machine that built it needs no certificate. An app that has to open on a colleague's Mac without a Gatekeeper warning has to be signed and notarised, and that requires membership in the Apple Developer Program. Apple states the fee directly on its enrolment page.

The Apple Developer Program is 99 USD per membership year. Prices may vary by region and are listed in local currency during the enrollment process. Source: developer.apple.com

That figure changes the arithmetic. A self built wrapper distributed to a team costs 99 USD a year before any development time is counted, which is more than twice the published starting price of either commercial tool. The build your own route pays off when the requirement is genuinely unusual, not when it is a cheaper version of the same thing.

The costs that never appear on a price page

Three of them, and they decide more cases than the sticker does.

Migration is the first. Apps are tied to the mechanism that made them. Moving from the Chrome route to a dedicated tool, or from one tool to another, means recreating each app and signing in again in each. The cost scales with the number of apps, which is exactly the number that made the tool attractive.

Maintenance is the second. Every macOS release moves the floor. A tool that has stopped being updated works until it does not, and the failure lands on a day chosen by the operating system rather than by the person using it. The maintenance signal to check is the date on the most recent release, not the feature list.

Uninstall residue is the third. Deleting an icon is not the same as clearing what the app stored. On the Safari route the data can be cleared beforehand from the Privacy tab in the app's settings. Chrome's uninstall dialog has a separate checkbox for deleting the data, unselected by default. On machines that hold work accounts this is a compliance question rather than a tidiness one.

There is a fourth that only shows up once a purchase has happened. Every tool in this category writes its apps in its own format, and an app built by a tool usually depends on that tool remaining installed and working. Removing the tool can leave a Dock full of icons that no longer open. That dependency is not a defect, it is how the architecture works, but it is worth confirming before a tool is used for anything that has to keep running. The question to ask of any candidate is what happens to the apps if the tool is uninstalled, and whether the answer is documented anywhere rather than discovered.

What to change first

Build two apps through the browser on the Mac right now and use them for a week, because that week is what reveals whether the ceiling is anywhere near. Check what the browser routes cover against Features, and look at Kagemusha only after the week produces a specific limit worth paying to remove.