Nativefier on a Mac in the years after it stopped

Nativefier still installs and still builds Mac apps, but it is no longer maintained. The GitHub repository was archived by its owner on September 29, 2023, the last release is v52.0.0, and every app that release builds carries Electron 25.7.0 with Chromium 114. On a Mac in October 2026, the practical questions are whether existing builds are safe to keep, what to do on Apple silicon, and what to move to. This page answers those three in that order.

This site is published by the developer of a site to app tool for macOS, which appears later as one option among several. The facts below were checked against the official sources linked in each section on October 18, 2026.

Where Nativefier stands in 2026

The npm registry lists 52.0.0 as the latest version, published on August 25, 2023. Its package metadata asks for Node.js 16.16.0 or newer and npm 8.11.0 or newer. The project's own source sets the default engine as Electron 25.7.0 and Chromium 114.0.5735.289.

The maintainers explained the archive in issue #1577, pinned on the repository:

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 same note gives a second route for a different reader: anyone building a bespoke wrapper for distribution should use Electron directly.

The gap to current software is the number that matters. According to the Electron release list, the newest stable release on October 17, 2026 was Electron 44.9.0, built on Chromium 152. The Chromium dashboard showed Chrome 155 as the current stable channel on macOS the same week. A Nativefier build from 2023 sits about 40 major versions behind the browser installed next to it, and that distance grows with every Chrome release.

Electron's support timeline states that the Electron team supports the latest three stable major versions. Security fixes go to those lines only. Electron 25 left that window long ago, and nothing inside an existing build will ever pull in a newer engine.

What a Nativefier build still does well

The command still produces a working app in a couple of minutes, and the reasons people chose it have not gone away. The API documentation lists the options that made it useful:

• --name and --icon set the app name and its Dock icon.
• --internal-urls takes a regular expression. Matching links stay in the app window and everything else opens in the default browser. By default, URLs that share a base domain, such as foo.com and app.foo.com, are treated as internal.
• --counter reads an "(X)" style count from the page title and shows it as a Dock badge on macOS, which is how a wrapped mail client gets an unread number.
• --tray keeps the app in the menu bar, and --single-instance stops a second copy from opening.
• --inject applies a CSS or JavaScript file to every page load. This is the option many people stay for, because it can hide a banner or add a shortcut the site does not offer.
• --widevine builds against a Widevine enabled Electron from castLabs for DRM playback. The documentation adds that some services still refuse to play video unless the app is also signed through castLabs' EVS service.

Each build also keeps its own cookies and storage. Two accounts on the same service can live in two apps without a profile switcher, and for many users that separation is the main reason to wrap a site at all.

None of these features are broken today. The problem is underneath them: the engine that renders the page, handles the login form, and parses every external link is the 2023 one, and it stays that way until the app is rebuilt with a newer Electron. Because the tool itself is archived, a rebuild with the released version only produces the same engine again.

The Apple silicon problem, and the 2027 deadline

Architecture is the issue most likely to break a working setup on a current Mac.

Nativefier builds for the architecture of the installed Node.js, not of the Mac. Its documentation warns that on M1 Macs, unless Node.js was installed through an arm64 build of Homebrew, Node runs as x64 under Rosetta and the result is an x64 app. Passing -a arm64 forces a native build. Many builds made in 2021 and 2022 were made the other way and have been running under Rosetta ever since without anyone noticing.

That now has an end date. Apple's support article on Intel-based apps, Rosetta, and the Apple silicon transition says Rosetta is available on all Apple silicon Macs running macOS 27 or earlier, and that from macOS 28 onward it will remain only for certain older, unmaintained games that rely on Intel-based frameworks. Apple adds that Intel-based apps may show a notice that they will not work in macOS 28.

To check an existing build, select it in the Finder and choose File > Get Info. The Kind line reads Application (Intel), Application (Universal), or Application (Apple silicon). On macOS 27, System Settings > General > About also has a Details button next to Intel-based applications that lists them all.

An x64 Nativefier app has roughly one major macOS release left on Apple silicon. It can be rebuilt as arm64, but that rebuild still ships Chromium 114. Rebuilding solves the architecture problem and leaves the engine problem where it was.

Sign-in, distribution, and other recurring failures

Three other problems account for most forum threads about Nativefier on a Mac.

Google sign-in. Google's help page on signing in with a supported browser lists the cases where it may stop a sign-in, including browsers that are embedded in a different application. An Electron wrapper fits that description. Nativefier sends a preset Chrome user agent by default so that sites do not reject it as unsupported, and --user-agent can change that string. Changing what the app reports does not change the engine, and the workaround can stop working whenever Google changes its checks.

Running the app on another Mac. A build opens on the Mac that made it. Sent to another Mac by download or AirDrop, it arrives with no Developer ID signature and no notarization, so Gatekeeper blocks it on first open. Signing and notarizing requires the Apple Developer Program, which Apple lists as a $99 annual membership, plus a notarization step for every build.

Installing the tool itself. The package was last published in 2023 against Node 16 era tooling. Installing it globally on a much newer Node.js is the step most likely to fail before a single app is built, and fixes for those failures will not arrive upstream.

The options compared

The choice comes down to who keeps the browser engine current. The table compares the main routes on a Mac. Electron's own extensions documentation describes its support as a subset of the Chrome Extensions API, aimed mainly at DevTools extensions.

Option	Who updates the engine	Separate login per app	Extensions	Cost
Nativefier v52 build	Nobody, frozen at Chromium 114	Yes	No extension option in the API	Free
Electron written directly	The developer, by rebuilding and shipping	Yes	A subset of the Chrome Extensions API	Free tool; $99 per year to sign and notarize
Chrome, Install page as app	Chrome, automatically	Per Chrome profile	Chrome's extensions	Free
Safari web app (Add to Dock)	macOS and Safari, automatically	Yes, separate from Safari	Safari extensions	Free
Site to app tool built on the installed browser	The installed browser, automatically	Depends on the tool	Depends on the tool	Free to paid

Chrome's route is documented in Google's help page on using web apps: open the site, then choose More > Cast, save, and share > Install page as app. Safari's route is covered in Apple's guide to Safari web apps on Mac, available from macOS Sonoma 14. Apple notes that a Safari web app shares no browsing history, cookies, website data, or settings with Safari, so it keeps its own login.

The two browser routes answer the maintainers' main concern directly, because the engine updates with the browser. What they do not offer is Nativefier's injected CSS and JavaScript, or a one regex rule for which links stay inside the window.

When a site to app tool is the better fit

There is a middle route between a browser shortcut and a frozen Electron bundle: a tool that turns a website into a standalone Mac app but uses the Chromium browser already installed, instead of shipping its own engine. The engine then updates whenever the browser does.

One such tool describes this on its Features page. Each app it creates gets its own browser profile, so cookies and sessions are isolated, and Chrome Web Store extensions can be switched on per app. That second point covers much of what --inject was used for, since a user script or user style extension can do the same job inside one app only. The same page explains that the apps follow the browser through symlinks, a background watcher re-syncs them after each browser update, and a health check on launch repairs anything that drifted. Its Guide adds that it runs on macOS 12 or later on both Apple silicon and Intel Macs, that it supports browsers such as Chrome, Brave, Edge, Vivaldi, and Chromium, and that URL rules can limit an app to approved domains, which is the closest equivalent to --internal-urls.

The trade-off is control. A tool like this is not a build system, and it will not produce a signed app to hand to customers. For that case, the maintainers' advice still applies: write the wrapper in Electron and own the release cycle. For personal and team use, where the goal is a window, an icon, and a login that stays separate, depending on the browser's update mechanism removes the work that made Nativefier hard to keep.

Moving existing builds without losing logins

A clean migration takes one afternoon if it is done in a fixed order.

1. List what exists. Open the Applications folder, note every Nativefier app, and record the URL each one opens. Check each one's Kind line in Get Info and mark any that say Application (Intel).
2. Split by need. Sites that only needed a window and an icon can move to Chrome's Install page as app or a Safari web app. Sites that needed a separate login, injected CSS, or extensions need a profile-isolating option.
3. Recreate one app and use it for a week. Sign in again in the new app; cookies do not carry over from an Electron bundle. Confirm that notifications, downloads, and sign-in all behave.
4. Remove the old bundle. Once the replacement has worked for a week, delete the Nativefier app so there is only one window for each site.

Keep any custom --inject files. They show exactly what each old build changed, and that is the specification for the replacement.

What to change first

Start with the Get Info check: any Nativefier app that shows Application (Intel) is on a clock that ends with macOS 28, and those should move first. Then replace the apps that handle a login, because they are the ones most exposed to a three-year-old engine, using a browser web app or a site to app tool such as Kagemusha that runs on the browser already installed.