Nativefier on a Mac in the years after it stopped

The install command still works. npm install -g nativefier pulls down version 52.0.0, a build of any URL finishes in a couple of minutes, and a new app appears with the right icon and its own Dock slot. Nothing in that sequence announces that the repository was archived on 29 September 2023, that 52.0.0 was the last release, or that the browser engine inside every app produced by it is pinned to a build Google shipped in May 2023. On a Mac in 2026, those three facts are what separate a reasonable shortcut from a slow liability, and they are worth knowing before a dozen wrapped sites are sitting in the Applications folder.

What a build still produces

A Nativefier build is an Electron application with the page loaded into it. The command takes a URL, downloads a prebuilt Electron binary, copies a generic wrapper into it, and renames the result. There is no code to write and nothing to configure afterwards.

The flags are where the tool earned its reputation, because most of them map to a real annoyance:

--name sets the application name and the Dock label. --icon takes a .icns file or a PNG that gets converted, which matters because the default icon is generic and a Dock full of identical icons defeats the point.

--internal-urls takes a regular expression. Links matching it stay inside the app window, and everything else opens in the default browser. Without it, a single external link turns the wrapper into a general purpose browser with no address bar, which is the worst of both worlds.

--single-instance stops a second copy from launching. --tray keeps the app resident in the menu bar after the window closes. --counter reads a number out of the page title and puts it on the Dock icon, which is how a wrapped mail interface gets an unread badge.

--inject takes a CSS or JavaScript file and applies it to every page load. This is the flag people stay for: hiding a sidebar, forcing a font, or removing a banner that the site has no setting for.

Each wrapped app also gets its own storage. Cookies and local storage do not leak between builds, so two accounts on the same service can sit in two apps without a profile switcher. That session separation, not the icon, is usually the reason a wrapper is worth building at all.

The engine inside, and the date it stopped

Version 52.0.0 was published on 25 August 2023 and bundles Electron 25.7. Electron 25 carries Chromium 114 and Node.js 18.15. That is the engine in every app built with the released tool, and it does not change when the Mac updates, when Chrome updates, or when the app is relaunched. A bundled engine is patched only when someone rebuilds against a newer one.

For scale: the Chrome stable channel on macOS was at version 152 at the start of September 2026, and Chrome moved from a four week release cycle to a two week one that same month. The gap between a Nativefier app and the browser sitting next to it is now measured in dozens of major versions, and it widens roughly twice a month without anyone touching anything.

The Electron project supports the three most recent stable major versions. Security fixes land there and nowhere else, so Electron 25 has been outside the support window for a long time. The archival notice on the project says the same thing in plainer terms.

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

The maintainer's second recommendation is for a different audience: anyone building a bespoke wrapper for distribution should use Electron directly, because it offers far more control. That is accurate, and it is also a project rather than a command.

Where builds fail on a current Mac

Five things go wrong often enough to plan around.

Architecture comes first. A build defaults to producing an app for the machine it runs on, but the flag --arch arm64 exists because that assumption has been wrong often, particularly in scripts and CI. An x64 build launches on Apple Silicon through Rosetta 2, which means it needs Rosetta installed and gives up the performance of a native binary for no benefit.

Installation comes second. The package requires Node.js 16.9 or newer and npm 7.10 or newer, and it was last published in 2023. It was never tested against the Node versions shipping today, so a global install on a current runtime is the step most likely to fail before a single app is built.

Distribution comes third. A locally built app opens on the machine that built it because nothing marked it as downloaded. Send the same bundle to a colleague and macOS quarantines it, because it carries no Developer ID signature and has not been notarized. Fixing that means an Apple Developer Program membership at 99 US dollars per year and a notarization step on every release, which is a heavier commitment than the two minute build implies.

Sign-in comes fourth, and it is the most common complaint. Google blocks sign-in from embedded browser frameworks, so a wrapped page that bounces through a Google account often stops at a screen saying the browser or app may not be secure. The usual answer is to pass a current desktop Chrome string through --user-agent. It frequently works, and it is a disguise rather than a fix.

Protected media comes fifth. Electron ships without the Widevine content decryption module, so DRM protected streaming does not play in a wrapped app. A music or video service is the wrong candidate for this approach regardless of how convenient the icon would be.

The options, side by side

Option	Engine updates	Runs on another Mac	Separate session per app	Cost
Nativefier build	Only by rebuilding	Only if signed and notarized manually	Yes	Free
Electron written directly	Only by rebuilding and shipping	Requires Developer ID, 99 USD per year	Yes	Free tool, paid membership
Chrome, page installed as an app	With Chrome, automatically	Set up per machine	Per Chrome profile	Free
Safari, Add to Dock	With macOS, automatically	Set up per machine	Shares Safari's session	Free
A maintained site to app tool	Depends on the tool	Depends on the tool	Depends on the tool	Varies

The row that matters is the first column. Everything below the second row inherits security updates from software that already updates itself. Everything above it inherits them from whoever remembers to rebuild.

What a wrapper is actually being asked to solve

Most people who reach for this tool want four things, and it is worth separating them because they have different answers.

A window that survives. The site does not get closed with forty other tabs, and it comes back where it was left.

An icon in the Dock and a place in the application switcher, so the site can be reached with muscle memory instead of a search through tab titles.

A signed in session that stays signed in and does not collide with a second account on the same service.

Small alterations to the page: a hidden element, a font change, a keyboard shortcut that the site does not provide.

The first two are solved by the browser now, which is exactly the point the archival notice makes. The third is solved by browser profiles, at the cost of a profile switch. The fourth is where a wrapper still has an argument, and it is also the one that keeps a build alive for years, which is how a five year old Chromium ends up handling a login form. Anyone weighing that trade should look at what a current tool covers before rebuilding an old one, and the Features page is a short version of that list. The Supported services page is useful for a different reason: it shows which sites people actually wrap, which is a better guide to the sensible candidates than a blank text field.

A build worth keeping, if one is going to exist

Most abandoned wrappers were built with a bare URL and nothing else, which is why they end up as generic icons pointing at pages that later break. A build that survives contact with daily use gets four decisions made at creation time rather than discovered later.

The link boundary comes first. Set --internal-urls to a pattern covering the domains the site legitimately moves through, including the identity provider it redirects to during sign-in, and leave everything else to the default browser. Getting this wrong in the tight direction breaks login. Getting it wrong in the loose direction produces a browser with no address bar, no history, no extensions, and no password manager, which is a genuinely unpleasant place to end up.

The icon comes second, and it is not decoration. A Dock and an application switcher full of identical generic icons removes the reason the app was built. Supply a real .icns file, or a square PNG large enough to survive conversion.

The behaviour on close comes third. A tool used all day should stay resident, which is what --tray and --single-instance are for. A tool used twice a week should quit properly, because a menu bar item for something rarely opened is noise.

The architecture comes fourth. On Apple Silicon, confirm the output is an arm64 build rather than an x64 one running through Rosetta 2, especially when the build runs from a script or on a different machine than the one that will use it.

The reason to write these down is that they are the parts a rebuild has to reproduce. An undocumented build command is the most common reason an app that broke in 2024 is still installed and still broken, because nobody can remember what produced it.

The forks, and what taking one on means

At least one hard fork exists and is described that way by its own author, with development moved off GitHub to Codeberg. Forks of an archived tool are genuinely useful, and they change the shape of the problem rather than removing it.

A fork inherits the same architecture. The engine is still bundled, the app still does not update itself, and the security posture still depends on someone rebuilding. What a fork adds is a newer Electron at build time and fixes for whatever broke since 2023. What it asks in return is trust in a single maintainer's continued attention, plus a rebuild cycle owned by the person who installed it.

That is a reasonable trade for someone who enjoys maintaining tooling and a poor one for someone who wrapped six sites to stop losing them in tabs. The honest test is whether a calendar reminder to rebuild every app twice a year sounds like a plan or like a thing that will not happen.

What to change first

Take an inventory of what is already wrapped, and split it: sites that only needed a window and an icon, and sites that needed an injected script or a separate session. Move the first group to a browser installed app today, because those update themselves and cost nothing to maintain. For the second group, decide who owns the rebuild, and if the answer is nobody, move to a tool that owns it instead, starting with Kagemusha.