Nativefier alternatives: what you can drop

Nativefier is no longer maintained. The GitHub repository is archived, the README opens with "Nativefier is unmaintained", and the last npm release, 52.0.0, was published on 25 August 2023. Its source still pins Electron 25.7.0 and Chrome 114 as the defaults, while Electron's own latest release on npm was 44.9.0 when checked on 18 October 2026. Any app built with Nativefier today ships a browser engine that is years out of date. The replacement depends on what Nativefier was being used for. For a personal window around a site, the maintainers themselves point to the browser's built in shortcuts. For a lightweight packaged app from the command line, Pake is the actively maintained option closest to Nativefier's workflow. For an app to distribute to other people, the maintainers recommend Electron directly. This page covers each route, with a flag by flag map for anyone moving build scripts from Nativefier to Pake.

What the maintainers said when they stopped

The archive notice is unusually direct about what to use instead. The pinned issue, Nativefier is unmaintained, opened on 29 September 2023, makes two recommendations.

The first is for people building wrappers for their own use. The notice says Nativefier was built before Chrome and Firefox could create shortcuts for websites, and that users who want their own wrappers "should strongly prefer these options as they are protected from security vulnerabilities by the browser's self updating mechanism."

The second is for people building an app to hand to others. For a bespoke app wrapping a website for distribution, it suggests using Electron directly, "which offers much more flexibility".

The security point is the reason not to keep using an old Nativefier build. Electron's release timeline states that its official support policy is the latest 3 stable releases, with a new major version every 8 weeks. An app on Electron 25 is far outside that window, and every site it loads runs in an engine without current security fixes. Nativefier itself knew this: its API reference includes a flag named --disable-old-build-warning-yesiknowitisinsecure, which exists to silence the warning old builds show.

So the first decision is not which tool replaces Nativefier. It is which of the three jobs Nativefier was doing.

Three jobs, three replacements

Nativefier was used for three quite different things, and each now has a different best answer.

Job	What it needs	Replacement
A personal window for one site	Dock icon, separate window, current engine	Browser built in web apps, or a site to app tool
A scripted build from the command line	One command, custom icon, injected CSS or JS	Pake
An app shipped to other people	Signing, auto update, custom code	Electron directly, or a commercial service

A personal window is the most common case and the easiest to replace. Nobody needs to compile anything to get a site into its own window on a current Mac.

A scripted build is the case where Nativefier's command line was the point: a script that produces the same set of apps on every machine, with icons and injected styles. Pake keeps that shape.

A distributed app needs signing, updates, and code of its own, which goes beyond what a wrapper generator was built for. That is where the maintainers point to Electron, and where commercial services built on Electron exist. ToDesktop is one such service, and its site offers a free trial.

The browser built in route

For a personal window, the built in routes now cover what Nativefier did, with the browser keeping the engine up to date.

Safari, Add to Dock. Apple's page on Safari web apps lists macOS Sonoma 14 or later. Open the site, choose File, Add to Dock, name it, and click Add. The app is saved in the Applications folder inside the home folder. It shares no browsing history, cookies, website data, or settings with Safari, so the app keeps a session of its own, apart from the browser. Its Settings let the name, start URL, and icon be changed later, and an Extensions tab turns Safari extensions on or off per app.

Chrome, Install page as app. Google's help page on web apps in Chrome gives the path as More, Cast, save, and share, Install page as app. The result runs inside the Chrome profile that installed it, signed in, with that profile's extensions.

What these routes do not offer is Nativefier's injection. There is no built in way to add a custom stylesheet or script to a Safari or Chrome web app. Safari's per app extension switch is the nearest substitute: a user style extension enabled only for that web app.

For anyone whose Nativefier use was a handful of apps for Gmail, Slack, or a project tracker, this route is usually the end of the migration. It costs nothing and needs no Node.js install.

Pake: the command line replacement

Pake is the actively maintained tool with the closest workflow to Nativefier. When checked on 18 October 2026, its latest release was V3.17.6, published on 17 October 2026, and the repository showed more than 62,000 stars. It is licensed under GPL-3.0, where Nativefier was MIT.

The main technical difference is the engine. Nativefier bundled Electron, which carries its own copy of Chromium in every app. Pake is built on Tauri and Rust, and uses the system web view instead, which on a Mac is WebKit. The README says the installer is "typically under 10 MB on disk" and nearly 20 times smaller than Electron packages.

The setup is heavier than Nativefier's. According to the CLI usage guide, Pake needs Node.js 20.9.0 or later and Rust 1.85.0 or later, and offers to install Rust if it is missing. The first build sets up the environment and takes longer; later builds are fast. On macOS it produces a DMG installer by default, and setting PAKE_CREATE_APP=1 produces a plain .app bundle instead.

The basic command mirrors Nativefier's:

npm install -g pake-cli
pake https://github.com --name "GitHub"

For people who do not want a build environment at all, the README also lists ready made packages for several popular sites and an online build option through GitHub Actions.

Mapping Nativefier flags to Pake

Most Nativefier scripts use a small set of options. The table below lines them up with the options listed in each project's own CLI reference. Pake option names are taken from its CLI guide as published on 18 October 2026.

Nativefier option	Pake option	Notes
--name	--name	Same purpose
--icon	--icon	Pake accepts a file path or URL
--width, --height	--width, --height	Same purpose
--min-width, --min-height	--min-width, --min-height	Same purpose
--inject	--inject	Custom CSS or JS
--internal-urls	--internal-url-regex	Which links stay inside the app
--tray	--show-system-tray	Menu bar or tray icon
--always-on-top	--always-on-top	Same purpose
--user-agent	--user-agent	Same purpose
--full-screen	--fullscreen	Spelling differs
--hide-window-frame	--hide-title-bar	Closest equivalent on macOS
--zoom	--zoom	Same purpose
--widevine	None listed	See below

Two differences need attention before switching.

DRM video. Nativefier had a --widevine option for sites that need Widevine, such as some streaming services. Pake's CLI guide lists no equivalent. Because Pake uses WebKit on a Mac, sites that require Widevine specifically may not play.

Chromium only sites. A site that tests for Chrome, or relies on a Chromium only API, behaved in Nativefier exactly as in Chrome. In Pake on a Mac it behaves as in Safari. Testing each site after the move is the safe step; the --user-agent option can help where a site only checks the browser name.

Other projects exist in the same space. naty describes itself as a "Nativefier alternative that provides a WebView of any website with a minimal install size", but its repository showed 8 stars and a last push in July 2024 when checked, so it is a smaller bet than Pake.

Mac apps with a graphical interface

Some Nativefier users only ran it from the command line because there was no other free option. On a Mac, several tools now build site specific apps from a window, with no Node.js or Rust needed. Figures below are from each vendor's official page on 18 October 2026.

Tool	Engine	Free tier	Paid
Unite Pro	WebKit	1 app	From $39.99 one time
Coherence X6	Chrome based browsers on the Mac	1 app	From $39.99 one time
Fluid	Not stated	Unlimited apps	$5 licence for extras

BZG's comparison of Unite and Coherence states that Unite does not support third party extensions while Coherence supports Chrome extensions, and gives typical app sizes of about 90 MB for Unite against 200 MB or more for Coherence. Unite Pro requires macOS 15 or later, and Coherence lists macOS 13.5 or later. Fluid's home page offers version 2.1, requiring Mac OS 10.12 or later, with a $5 licence that adds menu bar pinning, userscripts and userstyles, and full screen mode.

The choice of engine matters for the same reason it matters with Pake. A tool built on Chrome based browsers already on the Mac keeps Chromium behaviour and Chrome extensions, and its engine updates whenever the browser does. That is the property the Nativefier maintainers were pointing at when they recommended the browser's own update mechanism. Checking a tool's list of supported services shows which sites it has already been tested with, and its guide shows which settings, such as injected styles or link rules, carry over from a Nativefier setup.

Moving a set of apps without losing anything

A migration off Nativefier is rarely one app. It is usually five or ten, built at different times, some with options nobody remembers choosing. A short, ordered process avoids the two common losses: a forgotten app that keeps running the old engine, and a setting that silently disappears.

1. Make an inventory. List every Nativefier app on the Mac, and for each one write down the URL, the name, the icon source, and the full build command if a script or shell history still has it. Options such as --inject, --internal-urls, and --user-agent are the ones most often forgotten, and the ones that change how the site behaves.
2. Decide the route per app, not for the whole set. A plain mail or chat window can go to Safari's Add to Dock. An app with injected CSS can go to Pake. An app whose site needs a Chrome extension goes to a Chromium based tool.
3. Rebuild one app and use it for a day before rebuilding the rest. This catches engine differences, link handling, and notification permissions early.
4. Sign in again in each new app. The new app has its own session, so two step verification will be asked for again. Doing this in one sitting is faster than meeting it app by app over a week.
5. Remove the old app and its login item. In System Settings, General, Login Items, check that no Nativefier build is still set to open at login. An old app left in the Dock is the one most likely to be opened by habit.

Keeping the inventory as a plain text file after the move is worth the minute it takes. It turns the next machine change, or the next tool change, into a short list of rebuilds rather than a search through memory.

What to change first

Rebuild the apps that are used every day before anything else, because those are the ones running the outdated engine for hours at a time. Use Safari's Add to Dock for simple cases, Pake where a scripted build or injected CSS matters, and a Chromium based tool such as Kagemusha where Chrome extensions or Chromium only sites need to keep working.