Nativefier and the Chrome version it ships with

The app opens, the page loads, and a banner across the top says the browser is out of date and some features may not work. Or the sign-in screen refuses to continue and reports that this browser or app may not be secure. Or a video plays without sound and a support page suggests updating Chrome. The obvious next move is to find the update button inside the app, and there is not one, because there is no Chrome in there to update. Understanding what is actually in the bundle is what makes the next decision straightforward instead of a week of guessing.

There is no Chrome inside the app

A Nativefier app is an Electron application. Electron is Chromium plus Node.js, packaged as a library that an application carries with it. When the build command runs, it downloads a prebuilt Electron binary of a specific version, drops a small wrapper and the target URL inside, and renames the result. From that moment the engine version is a property of the file on disk.

This is the difference that catches people out. Chrome and Safari update themselves in the background, so the engine under a web page moves forward without anyone thinking about it. An Electron app has no such channel. Nothing in the bundle checks for a newer engine, nothing downloads one, and relaunching the app or updating macOS changes nothing at all. The engine is patched when someone runs the build again against a newer Electron and replaces the bundle. Never, if nobody does.

The published tool makes the numbers concrete. Version 52.0.0, released on 25 August 2023, bundles Electron 25.7. Electron 25 carries Chromium 114 and Node.js 18.15. Chromium 114 reached the Chrome stable channel in May 2023. Every app built with the released tool is running a browser engine from the first half of 2023, and no amount of restarting will change that.

The reason no newer version exists is that the project was archived on 29 September 2023, five weeks after that release. The archival notice states the position directly.

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

Reading the version an existing app carries

Three checks, in increasing order of effort.

The build options are stored inside the bundle. Right click the app, choose Show Package Contents, and open Contents/Resources/app/nativefier.json. That file holds the target URL and the options the app was built with, including any custom user agent string. It records what was asked for at build time, which is the fastest way to tell whether someone already applied a workaround.

The user agent is what sites are reacting to. Load any page inside the app that echoes the request headers back and read the Chrome version out of the string. If the number is far below the current stable channel, that is the number every server sees. If nativefier.json shows a custom user agent, this check reports the disguise rather than the engine.

The framework is the ground truth. Inside the bundle, Contents/Frameworks contains an Electron Framework.framework, and its size and modification date reflect the Electron version the app was built with. Combined with the tool version that produced it, that is enough to place the engine on a timeline.

For context while reading those numbers: 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 month. A gap that was already large is now widening about twice as fast.

The three ways to change it

Approach	What actually changes	Effort	Holds up over time
Rebuild with a newer Electron	The engine, genuinely	One command, plus testing	Only until the next rebuild is due
Override the user agent	The string sites see, nothing else	One flag or one file edit	No
Move off the wrapper	The whole update model	Migration of each wrapped site	Yes

Rebuilding is the only one of the three that changes the engine. The tool takes --electron-version, so a build can be pointed at something newer than the bundled default. The catch is real: the wrapper code was written against Electron 25 APIs and was last touched in 2023, so a large jump forward can produce an app that builds cleanly and then fails at runtime on a window option or a session API that changed. Move in steps, test the actual site including sign-in, and expect a ceiling somewhere short of the current Electron release.

Overriding the user agent changes the label on the box. It is the right tool for exactly one problem: a site that gates on the version string alone and works fine once it stops complaining. It is the wrong tool for anything else, for the reasons in the next section.

Moving off the wrapper is the only approach with no recurring maintenance, because the engine then belongs to software that updates itself.

Why changing the user agent is not an update

A user agent override edits one HTTP header and one JavaScript property. Everything else about the engine stays where it was.

Feature detection sees through it immediately. Modern sites test for capabilities rather than version strings, so a page that needs a web platform API added after Chromium 114 will still fail, and it will now fail in a confusing way, because the diagnostics reported the browser as current. A version banner is a clear error message. Silent breakage in a feature-detected code path is not.

Sign-in flows see through it too. Google blocks sign-in from embedded browser frameworks, and that detection does not rest on the user agent alone. Spoofing the string often gets a login through and it can stop working after any change on the provider's side, which turns a wrapped app into something that breaks on a schedule nobody controls.

Security is unaffected in either direction. Every vulnerability patched in Chromium since version 114 is still present, and the header says nothing about it. This is the part worth being blunt about: the version banner is not the problem. The version banner is the notification about the problem.

What decays, and in what order

Frozen engines fail in a predictable sequence, which is useful for judging how long a given wrapper has left.

Cosmetic breakage comes first. A layout that assumes a newer CSS feature renders slightly wrong. Annoying, not disqualifying.

Blocked sign-in comes next, and it is usually the moment people go looking for an update button. Identity providers move faster than anything else on the web and treat old or unrecognised clients as a risk signal.

Missing platform features follow. Notifications, file handling, clipboard behaviour, and media codecs are added and changed continuously. A site that quietly requires one of them stops working in the wrapper while working in the browser on the same Mac, which makes the fault hard to attribute.

Transport failures arrive last and are the hardest to diagnose. TLS configurations and certificate handling change over time, and a sufficiently old client eventually cannot complete a connection that every other application on the machine completes without comment.

Underneath all of it sits the unpatched vulnerability surface, which does not produce a symptom until it does.

Doing the rebuild properly

For anyone who has decided the rebuild is worth it, a few things make the difference between an afternoon and a fortnight.

Start from the recorded build options rather than memory. Contents/Resources/app/nativefier.json holds the target URL, the name, the internal URL pattern, and any user agent override the original build used. Copy those out before touching anything, because reproducing an app from a half remembered command line is where most of the time goes.

Move the Electron version in steps rather than jumping to the newest available release. The wrapper was written against Electron 25 APIs and last updated in 2023, so each major version forward is a chance for a window option, a session API, or a permission handler to have changed underneath it. A build that completes without an error is not evidence of anything until the app has been opened.

Test the parts that actually fail, in this order. Sign in from a cold start with the app's stored session cleared, because a session that was already valid will hide an authentication problem for weeks. Follow a link that should leave the app and confirm it opens in the browser. Follow one that should stay inside and confirm it does. If the build injects CSS or JavaScript, check that it still applies, since selectors written against a 2023 version of a site are frequently the first casualty.

Keep the old bundle until the new one has survived a full week of normal use. Rolling back is trivial when the previous app is sitting in a folder and impossible once it has been dragged to the trash.

Then write the command down somewhere it will be found again, next to a note about when the next rebuild is due. The rebuild is not the hard part. Remembering that a rebuild is owed, eight months later, is the hard part, and it is the reason frozen wrappers accumulate rather than get replaced.

When a rebuild is the wrong answer

Rebuilding fixes today and schedules the same work again. Before committing to it, it is worth asking what the wrapper is being kept for.

If the answer is a Dock icon, a window that does not get closed with forty tabs, and a place in the application switcher, the browser already does that, and it does it with an engine that patches itself. If the answer includes injected CSS or JavaScript, a separate session per account, or a menu bar presence, that is a real requirement a plain shortcut does not meet, and the question becomes who owns the rebuild cycle rather than whether one is needed.

A maintained tool answers that question by owning the engine on the user's behalf, which is the whole of the difference. The Features page is the short list of what that covers, and the Guide walks through the setup for a single site, which is enough to compare against the effort of maintaining a build script.

What to change first

Open nativefier.json in the app that is complaining and check whether a user agent override is already hiding the engine version. Then decide the maintenance question honestly: if nobody is going to rebuild every app twice a year, a newer Electron is a postponement rather than a fix, and moving the site to a tool that updates its own engine is the cheaper end state. Kagemusha is one place to start that comparison.