Fixing the old build detected message in Nativefier

The "Old build detected" box in a Nativefier app means one thing: the app was packaged more than 90 days ago. Nothing on the website broke, macOS did not block anything, and clicking the box away lets the app run as before. The check is hard coded into every app the tool produces, so the box will return at every launch until the app is rebuilt. There are three ways out: rebuild and reset the clock, rebuild with a flag that turns the warning off, or replace the app with something that updates its own browser engine. This guide explains what the dialog checks, why a plain rebuild is weaker than it looks, and how to pick a route. Every version number below was checked against the project's source, the npm registry, and official documentation on 18 October 2026.

What the dialog actually checks

The warning is not produced by the website or by macOS. It lives in the app's own main process. Every bundle stores the date it was built, and when the main window opens, the app subtracts that date from the current time. In the project's source file app/src/main.ts, the threshold is a named constant, OLD_BUILD_WARNING_THRESHOLD_DAYS = 90. Past that point, the app shows a dialog of type "warning" with the fixed message "Old build detected", unless the app was built with the warning disabled.

The detail text explains the intent. Unless a custom text was supplied at build time, it reads:

This app was built a long time ago. Nativefier uses the Chrome browser (through Electron), and it is insecure to keep using an old version of it. Please upgrade Nativefier and rebuild this app. Source: github.com

Read literally, the message rules out most of the usual suspects. It is not about an expired certificate, a blocked network request, a change on the site, or a new version of macOS. It reports that the copy of Chromium sealed inside this bundle has gone at least 90 days without a patch. A normal browser handles that by updating itself in the background. A packaged wrapper has no updater, so the only thing it can do is interrupt the user.

This also explains why the usual fixes do nothing. Quitting the app, restarting the Mac, clearing site data, or reinstalling the browser leaves the build date untouched. Only a new bundle changes it. The box is also a rough age stamp: an app that has just started warning was built about three months ago, while one that has warned for a year is carrying an engine well over a year old.

Why a rebuild only resets the clock

The dialog says to upgrade Nativefier and rebuild. Rebuilding does silence it, because the new bundle carries today's date. What a rebuild does not do is give the app a current browser engine, and that was the point of the warning.

The tool itself has stopped moving. According to the npm registry, the latest published version is 52.0.0, released on 25 August 2023, and nothing has been published since. The project's GitHub repository was archived by its owner on 29 September 2023 and is now read only. In that final version, the file src/constants.ts sets DEFAULT_ELECTRON_VERSION to 25.7.0 and DEFAULT_CHROME_VERSION to 114.0.5735.289.

So a rebuild run today with default settings produces an app dated today that contains Chrome 114 from mid 2023. The dialog goes quiet for another 90 days, and the risk it was pointing at stays where it was.

For scale, the npm registry lists Electron 44.9.0 as the latest release on the date of checking, with 44.0.0 published on 25 August 2026. Electron's own release policy keeps only a small window of versions under support:

The latest three major versions are supported by the Electron team. Source: electronjs.org

Electron 25 left that window long ago. The archived project says plainly what it recommends instead:

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

That statement names the property that matters. The wrapper idea was never the problem. The problem is a wrapper with a pinned engine and no maintainer, which cannot patch itself.

The build options that change the result

Every relevant option is applied when the app is built, not when it runs. None of them can be switched from the app's own menus. The full reference is in the project's API.md.

--disable-old-build-warning-yesiknowitisinsecure turns the check off. The documentation describes it as disabling the warning shown when opening an app made a long time ago, using an old and probably insecure Electron. It names one legitimate case: a kiosk app exposing an internal site that the builder controls. Using the flag still requires a rebuild, which resets the date anyway, so its real job is to stop the warning from ever coming back for a deliberately pinned build.

-e or --electron-version takes a version number without the leading v and packages that Electron release instead of the default. It is the only way to get a newer Chromium out of this tool. The catch is that the app shell in 52.0.0 was written against the Electron 25 API, and later major versions remove or rename calls it depends on. Some combinations build and run. Others open a window and then fail. Any build made this way needs testing on a real workload before daily use moves onto it.

--upgrade <pathToExistingApp>, added in version 43.1.0, reads the options an existing app was built with and rebuilds it with the current CLI. On macOS the path is the .app bundle itself. The documentation warns that this is an in place upgrade that replaces the current application, and advises making a backup first.

-a or --arch sets the processor architecture. By default it follows the architecture of the installed Node.js, which matters if the build machine and the Mac that runs the app are different.

On requirements, the project README lists macOS 10.13 or later, Node.js 16.9 or later, and npm 7.10 or later. The package metadata for 52.0.0 on npm declares stricter engines: Node 16.16.0 or later and npm 8.11.0 or later. On a current Mac this rarely matters, but it explains install errors on old Node versions.

Rebuilding an existing app, step by step

When the decision is to keep the app for now, the shortest safe sequence on macOS looks like this.

1. Quit the app and copy its bundle out of the Applications folder, for example to the Desktop, as a backup.
2. Install the CLI with npm install -g nativefier. This installs 52.0.0, the final release.
3. Run nativefier --upgrade "/Applications/Example.app" with the real path. The tool reads the original options and replaces the bundle.
4. To try a newer engine, add --electron-version with a specific version and test the result carefully.
5. Open the rebuilt app. Because it is not signed by an identified developer, macOS may refuse it on first launch. Open System Settings, go to Privacy and Security, scroll down, and click Open Anyway.
6. Check sign in, notifications, and file downloads before deleting the backup.

The backup step is important. Sessions and cookies live in the app's own data folder, and a rebuild can change the folder name if the app name changes. If anything goes wrong, the old bundle still opens with the old session, warning included.

Two older details are also worth checking. An app built years ago may be Intel only. On Apple silicon it runs through Rosetta, and Finder shows "Application (Intel)" as its kind in the Get Info window. Activity Monitor shows the same in its Kind column for running processes. Rosetta adds a second dependency on top of the engine question.

Comparing the routes

The decision is easier to see side by side. The engine column is the one that shows how seriously the dialog should be taken.

Route	Effect on the dialog	Engine in the app	Ongoing effort
Rebuild with defaults	Quiet for 90 days	Chrome 114, unchanged	Rebuild every quarter
Rebuild with the disable flag	Quiet permanently	Chrome 114, unchanged	None after the rebuild
Rebuild with a newer Electron	Quiet for 90 days	Newer, if the build works	Rebuild and retest each time
Install the site from Chrome	Never appears	Chrome's own, updated with Chrome	None
Use a maintained site to app tool	Never appears	Kept current by the tool	Depends on the tool

The first two rows are reasonable only when the site is internal, trusted, and unlikely to load third party content, such as a dashboard on a private network. For any site that handles logins, payments, or external links, an unpatched engine is the weakest point, and those rows only hide it.

Replacing the app with a browser install

The route the archived project recommends is the browser's own install feature. On Chrome, the menu wording has changed in a way that catches out people who learned the old path. A Chrome Developers post updated on 23 July 2024 describes the change:

From Chrome 128, More > Save and Share > Create Shortcut creates a bookmark on the user's desktop or homescreen. Source: developer.chrome.com

The same post explains that the old windowed behaviour moved to a separate item, Install Page as App. The current path, as described in Chrome Help, is the More menu at the top right, then Cast, save, and share, then Install page as app. The result has its own icon, its own Dock entry, and its own window without a tab strip. There is no build date to expire, because the engine is the browser's own and updates with it. Installed apps can be managed at chrome://apps.

Safari offers a similar feature on macOS Sonoma 14 and later through File, then Add to Dock. Safari web apps keep their cookies and website data separate from Safari, so each one needs its own sign in, and Chrome extensions are not available inside them.

The trade off with Chrome is coupling. An app installed this way belongs to the Chrome profile that created it and shares that profile's cookies, extensions, and signed in account. Using two accounts on the same service means two Chrome profiles, and removing the profile removes its apps. For one person using one account per service, this coupling is invisible. For someone moving between a work account and a personal account on the same service all day, it is the main problem, and it is often the reason a separate wrapper was built in the first place.

Where a separate wrapper still makes sense

The browser install covers the common case and is the right default. The gap it leaves is an app that keeps its own session, separate from whichever browser profile happens to be active, and that still runs on a patched engine. A maintained site to app tool can fill that gap without bringing back a frozen engine, as long as each app it creates runs on the browser already installed on the Mac rather than on a copy sealed into the bundle. The test for any such tool is simple: after the next Chrome update, check whether the apps it made are running the new version without a rebuild.

Before choosing one, check three things: which browsers it can use as the engine, whether each app gets its own isolated profile, and whether existing apps keep working after a browser update without manual steps. A list of supported services shows whether the sites in question are covered with ready made icons.

What to change first

Start by listing every Nativefier app on the Mac and noting which ones handle logins or payments. Move those to a Chrome install or to a tool that runs on the system browser, such as Kagemusha, and keep a pinned rebuild with the warning disabled only for trusted internal pages.