Nativefier alternatives: what you can drop

The list of replacements is easy to assemble. Every one of them says the same sentence: put in a URL, get an app in the Dock. That sentence is true of all of them, which is exactly why the list does not help. What decides the move is not the number of candidates but a much smaller number: how many of the flags on the old build command are still doing real work. Count those first, and most of the list disqualifies itself.

Start with the build command, not the comparison table

Somewhere on the machine there is a shell history entry, a Makefile, or a note in a README with the actual invocation in it. That string is the requirements document. Open it before opening any product page.

A typical line carries between five and ten flags. Name, icon, window size, single instance, a list of internal URLs, sometimes an injected stylesheet or script. The published option reference groups everything into nine categories: app creation, window, internal browser, cache, URL handling, auth, graphics, security, and platform specific. Almost nobody used more than one category's worth.

Now go through the flags one at a time and ask a single question of each. If this flag disappeared tomorrow, would the daily routine break. Not "would it be slightly worse". Would it break. Most flags fail that test, and every flag that fails it comes off the requirements list.

This step matters because a comparison table built from the full option reference makes every candidate look inadequate. A table built from four surviving flags usually has two candidates that clear it, and the choice between those two is quick. If the count comes out at zero or one, there is no shortlist to build at all: the browser already does that job.

The three jobs a wrapper is actually doing

Underneath the flag names, a wrapper does three separable things, and the replacements differ in which of the three they take on.

The first is a launch target. An icon in the Dock, a name in the application switcher, a window that is not a browser tab. This is the job most people came for and the one every replacement covers, including the free ones built into browsers.

The second is a boundary. The wrapper decides which URLs stay inside the window and which get handed to the default browser, which logins belong to this app and not to the browser profile, and whether a second launch reuses the existing window. Some replacements cover this well, some cover it partially, and the browser built-ins cover it barely at all.

The third is modification. Injected CSS that hides a column nobody needs, injected JavaScript that fills a login form, a user agent string that persuades a site to serve the desktop layout. This is the job with the fewest replacements, and the presence of any of it on the flag list narrows the field immediately.

Sorting the surviving flags into these three buckets takes about two minutes and turns an unbounded comparison into three yes or no questions. It also explains why two people can look at the same replacement and reach opposite verdicts. Someone whose flags all sit in the first bucket finds a browser install perfectly adequate. Someone with an injected stylesheet holding an internal dashboard together finds the same browser install useless. Both are describing the tool accurately. They are describing different requirements.

What the browser already covers

If every surviving flag lands in the first bucket, the search is over. Chrome installs a page as an app from the menu at the top right, under the entry for casting, saving and sharing, or from an install control that appears in the address bar on sites that offer it. Safari places a site in the Dock directly. Both produce a real application entry, a real Dock icon, and a window with no tab strip.

Several flags that look like bucket two or three also turn out to be covered, just by something other than the wrapper:

• Window size and position: macOS restores the last geometry, so setting it once by hand replaces the flag permanently.
• Always on top: stage manager and the window layering controls handle this more predictably than a per app setting.
• Zoom level: the site usually remembers it per origin, and the browser keeps a per site zoom setting.
• Background colour and disabled context menus: if nobody can explain why these were set, remove them and see whether anything complains.
• User agent overrides: these were usually a workaround for one site's detection logic, and they age badly. Check whether the site still needs it before treating it as a requirement.

The honest outcome of this section is that for a large share of Nativefier users, the build command was doing one job that the browser has since learned to do. The project's own maintainer said as much when the repository was archived.

Nativefier is unmaintained and has been publicly archived. It was built a couple of years ago before the ability to create shortcuts for websites in Chrome, or similarly on Firefox. Users who want to build and use their own website wrappers should strongly prefer these options as they are protected from security vulnerabilities by the browser's self updating mechanism. Source: github.com

What nothing else picks up

Four capabilities have no clean substitute, and any one of them on the surviving list rules out the free routes.

Injected CSS and JavaScript is the first. A browser install offers no hook for it. Extensions can do some of it, but only if the app is built on a browser that accepts extensions, which rules out the wrappers that use the system WebKit view.

Per domain URL routing is the second. Keeping an internal admin panel inside the window while sending every outbound link to the default browser is not something a browser install can express. Nativefier had explicit options for this, including a built in list of common login pages that are treated as internal so that sign in flows do not escape the window mid way.

Cross platform output is the third. Producing Windows and Linux binaries from a Mac was a Nativefier feature, and it required Wine on the path to do the Windows half. Very few replacements aim at this at all.

Reproducibility is the fourth and the most underrated. A command in version control produces the same app on any machine, which is what makes a fleet of twenty identical wrapped apps maintainable. Tools driven by a graphical interface cannot offer this, and for a team that rebuilds on a schedule, the gap shows up as labour rather than as a missing checkbox.

A useful way to test whether these four really apply is to look at what happens when they are removed rather than at what they do. Delete the injected stylesheet and the dashboard is still usable, just cluttered: that is a preference, not a requirement. Delete the URL routing and outbound links start opening inside the app window, leaving a browser window's worth of unrelated pages stacked where the work was: that is a requirement. The distinction is worth being strict about, because each one that survives cuts the shortlist roughly in half.

What each option takes on

The published facts, side by side. Prices are the list prices on each vendor's own page.

Option	Engine inside	Price	Injection and URL rules	Reproducible from a command
Browser install as app	The browser itself	Free	No	No
Electron used directly	Bundled Chromium	Free	Build it yourself	Yes
Pake	System WebView, via Tauri	Free, GPL-3.0	Partial	Yes
Coherence X6	A Chromium browser already installed	From 39.99 USD	Yes	No
Unite Pro	System WebKit	From 39.99 USD	Yes	No
WebCatalog	Bundled	Free tier, paid from 5 USD per user monthly	Partial	No
Fluid	System WebKit	Free, 5 USD unlocks some features	User scripts	No

A few notes on the numbers. Coherence X6 and Unite Pro are both one time purchases listed from 39.99 USD, each licensed for one major version line, with Coherence requiring macOS 13.5 or later and Unite Pro requiring macOS 15 or later. Both are also available through a subscription bundle service priced from 9.99 USD per month. WebCatalog's free tier covers two desktop apps, with paid tiers from 5 USD per user per month billed annually. Fluid is free with a 5 USD licence that unlocks status bar pinning, user scripts and full screen.

Price is the wrong column to read first

The column that decides the outcome is the engine column, because it answers a different question: who ships the security update.

When the engine is bundled, the version present at build time is the version that stays. Moving it forward means somebody rebuilds. Nativefier's default was Electron 25.7.0, carrying Chromium 114. Electron supports the latest three stable major lines and ships a new major roughly every eight weeks, so a bundled build drifts out of support within months of being made. The current Electron stable line is in the forties.

When the engine is the system WebView or a browser that is already installed and updating itself, nobody on the team presses anything. Pake sits on this side: it is built on Tauri and uses the platform WebView, which is also why its installers are described as roughly twenty times smaller than Electron equivalents and typically under 10 MB on disk. The cost shows up elsewhere, in a build environment that wants Rust 1.85 or newer and Node 22 or newer.

So the sequence is: decide whether there is a person who will rebuild on a schedule. If there is not, delete every bundled engine row from the table before looking at prices. That single question usually removes more candidates than the entire feature comparison does. The features page is a reasonable place to check which of the bucket two and three capabilities survive on the hosted side of that line.

Handing the app to someone else

Everything above assumes the app runs on the machine that built it. The moment it is passed to a colleague, two more facts apply.

Signing and notarization is the first. macOS has required notarization by default since Catalina, and an app that is neither signed nor notarized produces a warning on first launch. Nativefier output is neither, unless extra work is done, so every recipient walks through the same warning, and on a managed Mac the administrator's policy may not allow walking through it at all. The practical cost is not the warning itself but the explaining: the same conversation repeats for every new hire, and the instruction "click through the security warning" is a poor thing to put in an onboarding document.

Licensing is the second. Nativefier itself is MIT, which is permissive. Pake is GPL-3.0, which is a different conversation once distribution outside the organisation is on the table. Commercial tools absorb both of these questions on the vendor's side, which is part of what the purchase price covers.

If the answer to "who opens this app" is anyone other than the person who built it, both facts move from footnotes to requirements, and they belong on the shortlist before any feature does. The supported services list is useful here for a different reason: it shows how differently the boundary rules have to be set for a chat tool, a mail client and an internal admin panel, which is the part that gets rebuilt most often when a wrapper is replaced in a hurry.

What to change first

Open the old build command and cross off every flag that would not break the day if it vanished. If nothing survives, install the site through the browser this afternoon and delete the build script. If injection or URL routing survives, the shortlist is short enough to price out on the pricing page, and Kagemusha is one of the options that already answers the signing question on its own side.