Nativefier and the Chrome version it ships with

A Nativefier app cannot update its own Chrome. The Chromium engine is copied into the app bundle when the app is built, and nothing inside the bundle ever replaces it. To change it, the app has to be built again, either with nativefier --upgrade pointed at the existing app or with a fresh build that names a newer Electron through --electron-version. Because the Nativefier project was archived in September 2023, its last release still defaults to Chromium 114, while the Chrome stable channel on macOS was at version 156 on 18 October 2026. This guide shows how to read the version an existing app carries, what each of the three fixes actually changes, and when rebuilding stops being worth the effort.

Why there is no update button

Nativefier is a command line tool that wraps a web page in Electron. Electron is a framework that bundles Chromium and Node.js into a single application. When the build command runs, Nativefier downloads one specific Electron release, places a small wrapper script and the target URL inside it, and writes out a finished .app.

From that moment, the engine version is a fact about the file on disk. Chrome and Safari update themselves in the background, which is why the engine under an ordinary browser tab keeps moving without anyone noticing. A Nativefier app has no such channel. Relaunching it changes nothing. Updating macOS changes nothing. Updating Google Chrome on the same Mac changes nothing either, because the wrapped app never looks at the installed browser. It runs the Chromium that was copied in on the day of the build.

That is why the usual symptoms appear without warning and do not go away:

• A banner on a site says the browser is out of date.
• A sign-in page refuses to continue and says the browser or app may not be secure.
• A feature that works in Chrome on the same Mac silently does nothing inside the app.

None of these is a setting inside the app. All of them trace back to the engine version that was fixed at build time.

The project status matters here. The Nativefier repository on GitHub carries the notice that it was archived by the owner on 29 September 2023 and is now read only. The maintainers explained the decision in a pinned issue:

Nativefier is unmaintained and has been publicly archived. 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

No newer release of the tool is coming, so every fix below works with the last version that exists.

How far behind a Nativefier app is today

The numbers below were checked on 18 October 2026. The default engine comes from the tool's own source, where DEFAULT_ELECTRON_VERSION is set to 25.7.0 and DEFAULT_CHROME_VERSION to 114.0.5735.289. The Electron 25.7.0 release page lists the same Chromium build along with Node.js 18.15.0. The npm registry shows that Nativefier 52.0.0, the final release, was published on 25 August 2023.

Component	Nativefier 52.0.0 default	Current, 18 October 2026
Electron	25.7.0	44.9.0 (released 17 October 2026)
Chromium inside Electron	114.0.5735.289	152.0.7977.167
Chrome stable on macOS	Not applicable	156.0.8078.36
Node.js	18.15.0	Bundled with each Electron release

An app built with the default settings is 42 major Chromium versions behind the Chrome that the same Mac is running. The current Chrome figure comes from Google's public version history service for the Mac stable channel, and the Electron figures come from the Electron release list.

Two things follow from the table. First, even a perfect rebuild with the newest Electron would still trail Chrome by a few versions, because Electron ships each Chromium major some time after Chrome does. Second, the gap only grows. Every month that passes without a rebuild adds to it, and nothing about the app will report that it is happening until a site starts refusing it.

Reading the version an existing app was built with

Before choosing a fix, it helps to know what is actually inside the app. There are three places to look, from fastest to most reliable.

The stored build options

Right click the app in Finder, choose Show Package Contents, and open Contents/Resources/app/nativefier.json. This file records the options the app was built with: the target URL, the app name, any internal URL pattern, and any custom user agent. If someone already worked around a version banner by setting a user agent, it shows up here. Copy this file somewhere safe before trying any of the fixes below, because it is the recipe for rebuilding the app.

The user agent sites receive

Open a page inside the app that echoes request headers and read the Chrome version in the user agent string. This is the number every web server sees. If nativefier.json shows a custom user agent, this check reports the disguise, not the real engine, so read the two together.

The Electron framework itself

Inside the bundle, Contents/Frameworks holds Electron Framework.framework. Its version information tells you which Electron release the app was actually built with. Combined with the release table above, that places the Chromium version precisely.

If all three point to Electron 25 and Chromium 114, the app was built with the default settings of the last Nativefier release, and the sections below apply as written.

Option 1: run --upgrade on the existing app

Nativefier has a built in upgrade path that many people miss. The Nativefier API documentation describes --upgrade <pathToExistingApp>, added in version 43.1.0. It reads the options stored in the old app and rebuilds the app using the Nativefier version that is currently installed.

On a Mac, the path is the .app itself:

npm install -g nativefier
nativefier --upgrade "/Applications/Example.app"

The documentation carries a clear warning: the upgrade happens in place and replaces the current application. Duplicate the app in Finder first, so there is something to fall back to.

The limit of this option is easy to overlook. --upgrade moves an app forward to whatever the installed Nativefier uses by default, and the final release defaults to Electron 25.7.0. An app built in 2021 with an older Nativefier will gain two years of engine updates. An app built with 52.0.0 will gain nothing, because it is already on the newest default that exists.

So --upgrade is the right first move for old apps whose original build command has been lost. It is not a way to reach a 2026 engine.

Option 2: rebuild with a newer --electron-version

The only way to get a newer Chromium into a Nativefier app is to name a newer Electron at build time. The API documentation lists -e, --electron-version <value>, which takes an Electron version number without the leading v.

A rebuild starts from the stored options in nativefier.json:

nativefier "https://example.com" \
  --name "Example" \
  --electron-version 28.3.3

Add any other options the original build used, such as an internal URL pattern or an injected stylesheet.

This changes the engine for real, but there is a cost. The wrapper code inside Nativefier was written against Electron 25 and has not been updated since 2023. Electron changes its window, session, and permission interfaces between major versions, so a large jump can produce an app that builds without an error and then fails at launch or during sign-in. The practical approach is to move a few major versions at a time and test after each step:

1. Clear the app's stored session and sign in from a cold start, so an old session does not hide a broken login.
2. Click a link that should open in the default browser and confirm that it does.
3. Click a link that should stay inside the app and confirm that it stays.
4. If the build injects CSS or JavaScript, confirm the changes still apply.

Expect to stop somewhere short of the newest Electron. The point at which the wrapper stops working is not documented, because nobody is maintaining it, so it has to be found by testing.

Keep the previous app until the new build has survived a normal week of use. Write down the exact command next to the date, because this rebuild will be due again.

Option 3: --user-agent changes the label, not the engine

The API documentation also lists -u, --user-agent <value>, and since version 44.0.0 it accepts the short codes edge, firefox, and safari to generate a matching string. Setting a newer user agent is the fastest way to make a version banner disappear, and that is the whole of what it does.

A user agent override edits one request header and one JavaScript property. The engine underneath stays at Chromium 114. Most modern sites test for features rather than reading the version string, so a page that needs an interface added after Chromium 114 still fails. The difference is that the failure is now silent, because the app claims to be current.

Sign-in is where this breaks most visibly. Google's help page on sign-ins from browsers that may not be secure lists the cases where Google may stop a sign-in, including browsers that are embedded in a different application. That detection does not rest on the user agent alone, so a spoofed string may get a login through one week and fail the next after a change on Google's side.

Security is not affected by the label at all. Every vulnerability fixed in Chromium since version 114 is still present in the app, whatever the header says. The version banner was never the problem. It was the notice about the problem.

Use --user-agent only for a site that checks the version string and nothing else, and treat it as a temporary measure.

Comparing the three fixes

Fix	What changes	Reaches a 2026 engine	Maintenance afterwards
--upgrade	Engine, up to Electron 25.7.0	No	None, but nothing improves later
--electron-version rebuild	Engine, as far as the wrapper tolerates	Partly	A rebuild every few months
--user-agent	The string sites see	No	Breaks on the provider's schedule

All three leave the same structural fact in place: the engine belongs to the app bundle, and the bundle only changes when someone rebuilds it. That is fine for one app used once a week. It becomes a chore with five apps used every day, because each one needs its own rebuild and its own round of testing.

When rebuilding is the wrong answer

Before committing to a rebuild schedule, it is worth naming what the wrapper is for.

If the goal is a Dock icon, a separate window, and a place in Command Tab, the installed browser can already do it. Chrome can install a site as an app from its menu, and Safari on macOS Sonoma and later has File, Add to Dock. Both follow the browser's own updates.

If the goal also includes a separate sign-in per app, browser extensions, or several sites in one window, a different kind of site to app tool fits better: one that builds each app on top of a browser already installed on the Mac rather than bundling its own copy of Chromium. In that design the app points at the installed browser, so when Chrome updates, the app runs the new version on its next launch. The trade-off moves from "who rebuilds every app" to "does the tool keep its apps in step after each browser update." The Features page describes one tool built that way, including how it re-syncs its apps when the browser updates. The Guide walks through creating a single app from a URL, which is a useful comparison against maintaining a build script.

The question to settle is ownership. A frozen engine is acceptable only if someone is responsible for rebuilding it on a schedule. If nobody is, the app is quietly getting older every week.

What to change first

Open nativefier.json in the app that is complaining, copy it somewhere safe, and check whether a user agent override is already hiding the real engine. If the app predates Nativefier 52.0.0, run --upgrade on a duplicate; if it is already on Electron 25, decide whether a rebuild every few months is realistic, and if it is not, move the site to a wrapper that follows the installed browser, such as Kagemusha.