Nativefier: how to decide what you need

Two hours into comparing site to app tools, the tabs are open and the decision has not moved. That is the normal outcome, and it is not a failure of research. The comparison does not converge because it is being run in the wrong direction: from the tools inward, when the only thing that eliminates options is a set of facts about the situation the app has to live in. Four questions do almost all of the work, and none of them is about features.

Why the comparison does not converge

Every candidate makes the same claim. Enter a URL, get an application with its own icon, its own window and its own place in the switcher. That claim is accurate for all of them, so nothing is eliminated by reading it.

The feature matrices do not help either, for a subtler reason. A row like "supports browser extensions" or "multiple engine choices" is legible as English but not as a decision input. Whether it matters depends entirely on facts that live outside the matrix: which browser extension the daily routine depends on, whether the site in question does anything unusual at login, how many machines the result has to run on. Without those facts, every row reads as a nice to have, and a list of nice to haves cannot be ranked.

So the order has to be inverted. Fix the situation first. Four questions cover it, each answerable in under ten minutes, and each one removes candidates rather than adding them. By the time all four are answered, the shortlist is usually down to one or two, and the feature matrix becomes useful for the first time, because now it is being read with specific rows in mind.

Question one: how long does this app have to keep working

This is the question that decides whether Nativefier belongs on the list at all, and most comparisons skip it entirely.

Nativefier bakes a browser engine into the app at build time. The default is Electron 25.7.0, which carries Chromium 114. That version does not advance. The only way it advances is for a person to run the build again against a newer engine, which means the answer to this question is really a question about staffing.

Electron states its support window plainly:

The latest three stable major versions are supported by the Electron team. For example, if the latest release is 42.1.x, then the 41.0.x as well as the 40.2.x series are supported. Source: electronjs.org

A new major line arrives roughly every eight weeks, so three lines is on the order of half a year. A bundled build is therefore outside the supported window within months of being produced, and the Nativefier default has been outside it since 2023.

There is a legitimate answer that keeps Nativefier in play. If the app wraps an internal tool on one machine, nobody else touches it, and the person who built it is willing to rerun the command a couple of times a year, then the bundled engine is a scheduled chore rather than a defect. The build is a single reproducible command, which suits that pattern well.

The illegitimate answer is silence. If nobody is named for the rebuild, the honest conclusion is that the rebuild will not happen, and every option with a bundled engine should come off the list now rather than in eighteen months. What remains is the set of options where the engine belongs to something that updates itself: the system WebView, or a browser already installed on the machine.

Question two: does the site resist being wrapped

The second question is about the site, not the tool, and it is the one that most often produces a surprise late in the process.

Sign in is the usual source of trouble. A site that authenticates through a separate identity provider sends the browser to another domain and back. Inside a wrapper, that hop can land outside the window, and the app is left staring at a login page it cannot complete. Nativefier addressed this with an explicit list of internal URLs plus a built in set of well known login pages treated as internal, which covers the large consumer services and does not cover a company's own identity provider. Any candidate without a way to nominate extra internal domains fails here.

Protected video is the second. The published option reference notes that some sites using Widevine still refuse to play video inside a Nativefier build, and that making them work involves signing the app through a third party service. If video is the point of the app, that is a real cost and it should be known before the build, not after.

Extensions are the third. A password manager, a translator or a clipper that is part of the daily routine has to come along, and it can only come along on options built around a Chromium browser that accepts extensions. Options built on the system WebKit view have no place to put one.

Notifications and file handling round it out. If the site pushes notifications or the routine involves uploading and downloading files all day, check that the candidate does both. If neither is used, strike both rows from the matrix and stop weighting them.

Question three: what has to be installed before anything builds

The third question is about the machine in front of the decision, and it takes about five minutes.

Nativefier's published requirements are macOS 10.13 or later plus a Node toolchain. The package declares Node 16.16.0 or newer and npm 8.11.0 or newer. Converting a custom icon additionally requires ImageMagick or GraphicsMagick, with either convert and identify or gm available on the path. Producing Windows binaries from a Mac requires Wine on the path as well. None of that is exotic, but it is four installs before the first app exists, and on a locked down work machine some of them may need approval.

The alternatives are not automatically lighter. Building the Tauri based option locally expects Rust 1.85 or newer and Node 22 or newer, which is a heavier toolchain than Nativefier's, not a lighter one. The saving there is in the output, not the input.

The commercial tools invert the problem. They need no toolchain at all, but they do impose an operating system floor, and it is higher than Nativefier's. The Chromium based one requires macOS 13.5 or later. The WebKit based one requires macOS 15 or later. On a Mac that cannot move past an older release, those candidates are eliminated by this question before any of their features are read, which is worth discovering in five minutes rather than after a purchase.

Question four: how many apps, and who rebuilds them

The last question is about scale, and it changes which properties are worth paying for.

One app on one machine is a different problem from twelve apps on nine machines. At a count of one, a graphical tool wins on speed: enter a URL, pick an icon, done, and the whole thing takes less time than reading the option reference. At a count of twelve, the property that matters is that the twelve are identical and can be recreated from a file. That is where a command line build earns its keep, and it is the one place Nativefier still has a genuine structural advantage over the tools with nicer interfaces.

Distribution multiplies this. macOS has required notarization by default since Catalina, and a build that is neither signed nor notarized warns on first launch. On one personal machine that is a single click. Across a team it is a support conversation per person, repeated for each new hire, plus whatever the device management policy has to say about it. Commercial tools carry signing on the vendor's side, and that is a substantial part of what separates a free build from a paid one.

Rebuild frequency is the last piece. If the answer to question one was "twice a year", multiply that by the app count to get the real annual cost of the bundled engine route. Twelve apps rebuilt twice a year is twenty four builds, and at ten minutes each including reinstalling and signing back in, that is four hours a year of work that the self updating options simply do not generate.

Running the four answers against the options

With the four answers in hand, the table reads quickly. Look for the first row where all the answers match.

Engine maintained by	App count	Distributed to others	What survives
A named person, on a schedule	Any	No	Command line builds, Nativefier included
Nobody in particular	One or two	No	Browser install, or a WebKit based tool
Nobody in particular	Several	No	A tool whose engine is a browser already installed
Either	Any	Yes, inside a team	A tool that signs and notarizes on its own side
Either	Any	Yes, outside the organisation	Licence terms and signing decided before features

Question two then acts as a filter on whatever row was reached. If extra internal domains have to be nominated, or extensions have to come along, and the surviving row cannot do it, move down one row. Question three does the same with the operating system floor.

Two candidates left is a good result. At that point the feature pages are worth opening, and the features list is the right level of detail for checking the specific rows question two produced, rather than for browsing.

The cost of getting the answer wrong

Reversing a decision is cheaper than most people assume on one machine and much more expensive than they assume once it is distributed, which is why the two cases deserve different amounts of deliberation.

On one machine, switching costs roughly ten minutes per app: rebuild, sign back in, re grant notification permission, put the icon back in the Dock. Five apps is under an hour. At that price, trying a candidate for a week is a rational way to answer question two, because a week of real use surfaces the login and link routing problems that no feature page mentions.

Once the app has been handed to other people, the same ten minutes happens on every machine, and it happens with an audience. That asymmetry is the argument for answering all four questions before distributing anything, even though it feels slower.

The expensive failure is the silent one. A bundled engine does not announce that it has aged. It works, and then one day a site rejects it or a certificate chain it does not know about breaks, and the tool stops during the working day. If question one was answered with a named person and a schedule, put the rebuild dates in a calendar the same afternoon the decision is made. If it was not, that outcome is the reason the bundled rows were removed. Checking how a given tool handles operating system upgrades is worth doing while deciding, and the FAQ covers that ground for the hosted route.

What to change first

Answer question one out loud, with a name attached or not, before opening another comparison tab. If a name exists, keep the command line build and schedule the rebuilds. If no name exists, delete every bundled engine candidate from the shortlist, and price the remainder, Kagemusha among them, against the app count from question four.