npm install -g nativefier: what it installs in 2026 and what to check first

Typing npm install -g nativefier into Terminal still works. npm downloads Nativefier 52.0.0, puts a nativefier command on your path, and from there one line such as nativefier "https://app.asana.com/" produces a Mac app with its own Dock icon. What the command does not tell you is that 52.0.0 was published on August 25, 2023, that the GitHub repository was archived a month later, and that every app it builds ships with a copy of Chromium 114. This guide covers the install itself, the errors people most often hit, the handful of flags worth knowing, and the facts to check before relying on the result. Every version number below was checked against the official source on October 18, 2026.

What the install command actually gives you

npm install -g nativefier installs the package globally, which means the nativefier binary lands in npm's global bin folder instead of inside a project. On a Mac with Homebrew, that is usually /opt/homebrew/bin on Apple silicon or /usr/local/bin on Intel. You can confirm with which nativefier and nativefier --version.

The version you get is fixed. The npm registry lists 52.0.0 as the latest tag, and no newer release exists. The package metadata for that release declares two engine requirements:

• Node.js 16.16.0 or newer
• npm 8.11.0 or newer

The project README gives slightly lower numbers (Node.js 16.9 and npm 7.10) and macOS 10.13 or later. When the two disagree, the engines field of the package you are actually installing is the one npm enforces, so treat 16.16.0 as the floor.

Two optional tools change how smooth the experience is. ImageMagick or GraphicsMagick lets Nativefier convert a .png icon into the .icns format macOS wants. Without either one, supply an .icns file yourself or let Nativefier fetch the site's icon. Wine is only relevant if you want to build Windows apps from a Mac.

If you would rather not install anything globally, npx nativefier "https://example.com" runs the same package on demand. npm documents npx as an alternative to global commands for exactly this case, and it sidesteps the permission problems covered next.

Fixing the errors people hit during install

Most install failures fall into three groups, and the search results for this command are full of all three.

Permission errors (EACCES). If npm's global folder belongs to root, a global install fails with EACCES: permission denied. The tempting fix is sudo npm install -g nativefier. npm's own documentation recommends against that route. Its guide to EACCES errors offers two clean options: reinstall Node.js with a version manager such as nvm, or point npm at a folder in your home directory with npm config set prefix ~/.local and add ~/.local/bin to your PATH. Either one makes the global install work without elevated rights.

Engine or dependency errors. Very old Node.js installs fail the 16.16.0 check. Very new ones can also cause trouble, because Nativefier's dependencies were last updated in 2023 and nothing guarantees they build cleanly on the newest Node.js release. If the install stops with errors from a dependency rather than from Nativefier itself, an LTS release of Node.js managed through nvm is the most predictable setup.

Packaging errors from Linux package managers. Several threads that rank for this query come from Snap and the Arch User Repository, where the package is maintained by third parties. The README states plainly that those repos are not managed by Nativefier's maintainers. On a Mac, they do not apply. Plain npm is the supported path.

Once nativefier --version prints 52.0.0, the install is done.

Building a first app, step by step

The command shape is nativefier [options] [targetUrl] [dest]. A sensible first build passes only the URL and a destination:

nativefier "https://app.asana.com/" ~/Applications

Nativefier tries to work out the app name and icon from the site. Look at what it picked before adding flags. If the name is fine, skip --name. If the icon came through, skip --icon.

To avoid typing the destination every time, add export NATIVEFIER_APPS_DIR=~/Applications/ to ~/.zshrc. Without a destination and without that variable, the app is written to whatever folder Terminal is in, which is how many people end up with apps sitting in Downloads.

Then test three things:

1. The app launches and shows the right page.
2. Sign-in completes inside the app instead of jumping to your browser.
3. The features used daily, such as notifications, file uploads, and downloads, behave.

One trap is specific to Apple silicon. The default architecture is whatever your Node.js binary was built for. If Node.js came from an Intel copy of Homebrew running under Rosetta, the app is built for Intel. Run node -p "process.arch". If it prints x64 on an M-series Mac, add -a arm64 or reinstall Node.js natively. -a universal builds one app for both chip types.

The flags worth knowing

Nativefier has dozens of flags, but a Mac app used every day rarely needs more than these:

Flag	What it does
-n, --name	Sets the app name
-i, --icon	Sets the icon (.icns, or .png with ImageMagick)
-a, --arch	arm64, x64, or universal
--single-instance	Brings the existing window forward instead of opening a second copy
--tray	Keeps the app in the menu bar when the window is closed
--internal-urls	Regex for links that stay inside the app
--block-external-urls	Blocks navigation outside the internal range
--upgrade	Rebuilds an existing app with the installed Nativefier

The important property is that these are written into the app at build time. There is no settings window afterwards. Changing the name, the icon, or the link rules means building again.

Link handling causes the most rebuilds. By default, two URLs count as internal when they share a base domain after www. is stripped, so app.foo.com stays in the app and abc.com opens in your default browser. A built-in list treats common sign-in pages as internal, including accounts.google.com, login.microsoftonline.com, okta.com, and github.com/login. Services using a sign-in host outside that list need --internal-urls with a regex that covers it. All of this is documented in API.md.

Rebuilding, upgrading, and carrying apps around

Because every setting is baked in, keep the exact command used for each app in a text file next to it. When something needs to change, edit that one line and run it again. Rebuilding into the same destination replaces the old app unless --no-overwrite is set.

--upgrade takes a different path. Pass it the .app of an existing Nativefier build, and it reads the old options back out and rebuilds the app with the Nativefier version installed now. The documentation flags two conditions. The upgrade happens in place and replaces the current app, so back it up first. And the app must still be in the location where it was originally generated. Since 52.0.0 is the final release, --upgrade today mainly helps apps made with much older Nativefier versions; it cannot move anything past Chromium 114.

--portable stores cookies, cache, and sign-in data inside the app folder, so the app can be carried on a USB drive and open in the same state on another Mac. The documentation carries a strong warning with it: anyone who receives a copy of a portable app that has been used also receives that saved data, potentially including access to every account signed into it. The documented safe practice is to build, test, delete, rebuild the same way, and hand over the app without ever opening it.

Three facts to check before relying on it

This is the part the ranking pages mostly leave out.

The project is unmaintained. The repository shows the notice "Nativefier is unmaintained" at the top of its README, and it was archived on September 29, 2023. Bugs are not fixed and new macOS releases are not tested.

The bundled browser is old. The final source sets the default Electron version to 25.7.0, which bundles Chromium 114. Electron 25 received its last update, 25.9.8, on December 5, 2023. Electron's support policy covers only the latest three stable major versions, and the newest stable release on October 17, 2026 was 44.9.0 with Chromium 152. An app built today runs a browser engine 19 Electron major versions behind, and it never updates itself, because it does not use the Chrome installed on your Mac.

The -e flag lets you request a newer Electron, but Nativefier was never tested against those versions, so success is not guaranteed. There is also a flag named --disable-old-build-warning-yesiknowitisinsecure. The name is accurate.

The maintainers point elsewhere. The issue announcing the end of the project, #1577, says that people building wrappers for their own use should strongly prefer the shortcut features built into Chrome and Firefox, because those stay patched through the browser's own updates. For apps meant for distribution, it recommends using Electron directly.

Options that follow your browser's updates

Each of the following avoids the frozen-Chromium problem because it runs on a browser that keeps updating.

Chrome. Open the site, then choose More, then "Cast, save, and share", then "Install page as app". Chrome's help page also covers managing these apps from chrome://apps, including launching them at login.

Safari. On macOS Sonoma 14 or later, choose File, then Add to Dock. According to Apple, the web app shares no browsing history, cookies, or website data with Safari, and its name, URL, and icon can be changed later from the app's Settings.

A site to app tool built on your installed browser. Some Mac tools turn a website into a standalone Mac app by pointing at Chrome, Brave, Edge, or another Chromium browser already on the Mac, instead of bundling a copy. The app inherits browser updates, can run Chrome extensions, and gets its own profile so two accounts on the same service can stay signed in side by side.

Approach	Engine inside the app	Change settings later	Engine updates
Nativefier 52.0.0	Bundled Chromium 114	Rebuild	Stopped in 2023
Chrome "Install page as app"	Installed Chrome	Partly	With Chrome
Safari "Add to Dock"	Installed Safari	In app Settings	With macOS
Site to app tool on installed browser	Installed Chromium browser	In the tool	With that browser

The right choice depends on what the wrapper is for. A single internal dashboard that never leaves a locked-down machine is a different risk from a Gmail window you sign into every day.

What to change first

If Nativefier apps are already in your Applications folder, start with the ones you sign into daily and move them to an option that tracks browser updates. Chrome's install option or Safari's Add to Dock covers most single-account cases at no cost. If you need extensions or separate accounts per app, Kagemusha builds apps on your installed browser; the guide walks through a first app, and pricing lists the free tier and the one-time Pro price.