Nativefier: what the free tier covers
Anyone comparing ways to get a web app out of a browser tab hits the same fork quickly. One route is a command line tool that costs nothing. The other is a Mac application with a price on it. Put like that the comparison looks settled, which is why it is worth working out where the free route actually charges. It does charge, just not at the point of download, and the bill arrives in three places: disk, identity, and time. The figures below are either taken from the vendors' own pages or measured on a Mac on 12 September 2026.
The licence is free, and there is no catch in it
Nativefier is published under the MIT licence. There is no paid tier, no account, no usage limit, no feature held back, and no commercial restriction. An organisation can wrap a hundred internal tools and owe nothing. Unlike products where free means a limited version of something larger, there is no larger version here.
That is worth stating plainly because much of the writing about free tools implies a hidden meter somewhere. There is not one. Everything the tool can do is available to everyone who installs it, and the only thing missing from the free package is the one thing a licence cannot provide, which is someone maintaining it. The last release is version 52.0.0 from August 2023, and the public repository has been archived since September of that year.
So the question is not what the free tier excludes. It is what a zero cost licence does not cover, and that is a different list.
Disk is the first cost, and it does not divide
A wrapped app is not a link to an installed browser. It carries a complete copy of a browser engine, and that copy is not shared with any other wrapped app on the machine.
Measured with the standard disk usage tool, a bundle produced for a single plain page came to 205 MB. A second bundle for a different site came to the same figure, because nearly all of the weight is the engine rather than anything site specific. The archive that gets downloaded during the first build is smaller, at 84 MB for the Apple silicon build of the default engine version, since it is compressed.
The arithmetic is simple and it is what surprises people. Five wrapped sites occupy roughly a gigabyte. Twelve occupy nearly two and a half. On a machine with a 256 GB drive that is not fatal, but it is not free either, and it is a cost that grows linearly with the number of apps rather than flattening out.
There is a second, less visible version of the same cost. Each wrapped app keeps its own storage, which is the property that makes a second account on the same service possible. That storage also accumulates independently, and the tool exposes a disk cache size setting and a flag that stops the cache being preserved between launches, which exist precisely because the default is to keep everything.
The 99 USD line
The finished bundle is signed with an ad hoc signature and no team identifier. That is the normal result of building without a developer account, and on the machine that built it, the bundle opens with no dialog because it never acquired a quarantine attribute.
The cost appears the moment the bundle has to travel. Sent to a colleague by download or AirDrop, it arrives quarantined, and macOS blocks the first launch. Apple states the requirement directly:
By default, macOS Catalina and later also requires software to be notarized, so you can be confident that the software you run on your Mac doesn't contain known malware. Source: support.apple.com
Signing and notarising means a developer account, and the price of that is published:
The Apple Developer Program is 99 USD per membership year. Source: developer.apple.com
There is a separate programme for organisations distributing privately to employees, listed at 299 USD per year on the same site. Neither is a Nativefier charge. They are what it costs to hand an app to someone else on a Mac without asking them to override a security warning.
For a single person wrapping sites for their own machine, this line is genuinely zero and stays zero. For anyone wrapping an internal tool for a team of twenty, it is the first real number in the comparison, and it should be counted on the free side of the ledger rather than assumed away.
The recurring cost is the rebuild
The engine inside a wrapped app never updates. Version 52.0.0 defaults to an engine release from 2023, corresponding to Chromium 114, and whatever version is chosen at build time is frozen into that bundle permanently. The current stable engine release, published 8 September 2026, is built on Chromium 152.
The tool is candid about what follows. Every built app checks its own age at launch, and past 90 days it shows a warning telling the user to rebuild. That sets an implicit schedule of roughly four rebuilds per app per year.
A rebuild is not expensive in isolation. There is a purpose built path for it, a flag that takes the path to the existing app and overwrites it while preserving the options it was originally built with, so the flags do not have to be remembered. Call it a few minutes per app including the download when the engine version changes.
Multiply it out honestly. Six wrapped apps at four rebuilds a year is 24 rebuild events. At five minutes each that is two hours a year, plus the mental overhead of noticing that the 90 days have passed, which in practice is the part that fails. The recurring cost is not the minutes. It is remembering. An app that quietly keeps running a 2023 engine for three years because nobody actioned the warning is the realistic failure mode, not a dramatic one.
Support is the line item with no price on it
Every paid product in this category includes a route to ask someone a question. The free route does not have one any more, and that is a cost even though it never appears as a number.
The public repository is archived, which makes it read only. The 258 issues that were open when that happened are still open and can no longer receive replies. Nobody is rude about it, and nobody is obliged to be helpful: the project was given away under a licence that says exactly that. But a site that changes its login flow next year, or a macOS release that changes how bundles are treated, will not produce a fix. It will produce a thread that stays unanswered.
What that means in practice is that the time budget has a second entry beside the rebuild. Whoever set the apps up owns every future problem with them, including ones caused by changes nobody controls. For a technical person who enjoys that, the entry is close to zero, and may even be negative in the sense that the tool is more interesting than the alternative. For a team where the person who set it up has moved on, the entry is whatever it costs to work out what was built and why.
This is the most common place where a free tool turns out to be expensive, and it is also the easiest to price before committing. Ask how many hours a year the setup can absorb before someone would rather have paid $39.99. If the honest answer is less than two, the comparison is already decided, and it was decided by support rather than by features.
What the alternatives charge
Paid Mac applications in the same category publish their prices, and the comparison is more useful as a table of what the money buys than as a ranking.
| Command line tool | Coherence X6 | Unite Pro | Subscription bundle | |
|---|---|---|---|---|
| Price | 0, MIT licence | from $39.99, buy once | from $39.99, buy once | from $9.99 per month |
| Payment model | none | one purchase, optional paid upgrades | one purchase, optional paid upgrades | recurring |
| Signed for distribution | no, ad hoc | yes, as shipped | yes, as shipped | yes, as shipped |
| Engine updates | manual rebuild | vendor | vendor | vendor |
| Apps per licence | unlimited | per the vendor's terms | per the vendor's terms | per the vendor's terms |
The two named products are both from the same developer and both list a starting price of $39.99 on their product pages, with the same buy once model and optional paid upgrades. Both also appear in a subscription bundle that starts at $9.99 per month and covers a large catalogue of unrelated Mac software, which is a different proposition again: worth it if several of the other titles are already wanted, poor value if the wrapper is the only one.
None of this makes the paid route correct. It makes the shape of the choice visible. A one time purchase converts the rebuild schedule and the signing question into somebody else's responsibility. A zero cost tool keeps both in house, along with the full flexibility to script the whole thing, which a graphical application cannot offer.
How to work out which is cheaper for a given case
Three numbers decide it, and all three are knowable before anything is installed.
The first is the number of apps. Below three, disk barely matters and a quarterly rebuild is a small habit. Above eight, the disk figure passes a gigabyte and a half and the rebuild schedule becomes a recurring calendar item.
The second is whether anything has to be handed to another person. If the answer is no, the signing line is zero and stays zero. If the answer is yes, 99 USD per year enters the comparison immediately, and at that point a one time purchase under half that figure changes the arithmetic.
The third is whether the work is repeatable. A command line tool can be driven from a script, which means fifty machines can be provisioned identically without fifty sets of clicks. That capability has no price on the paid side because it is not offered there.
A fair summary is that the free route is cheapest for one technical person with a handful of apps and a tolerance for a quarterly chore, and it stops being cheapest at the point where apps are distributed to people who did not build them. For readers weighing the middle ground, the Pricing page and the Supported services list are the two places where that comparison can be made with real numbers rather than estimates.
What to change first
Count the sites actually worth wrapping and check whether any of them need to reach another person's Mac. That single answer decides whether the free route stays free, and it is worth settling before spending an evening on flags. Kagemusha is aimed at the case where the apps have to be signed and have to keep working without a quarterly rebuild.
Frequently asked questions
Is Nativefier free for commercial use?
Yes. It is published under the MIT licence, which places no restriction on commercial use and no limit on how many apps are built. There is no paid tier and no feature reserved for payment, so an organisation can wrap internal tools at no licence cost.
Why would anyone pay for a wrapper when a free one exists?
The published differences are signing and maintenance rather than features. Paid Mac applications in this category ship signed and notarised, so they open on any Mac without a security override, and the vendor keeps the engine current. The free tool produces an ad hoc signed bundle whose engine is frozen at build time.
How much does it cost to sign a wrapped app so colleagues can open it?
Signing and notarising requires an Apple developer account, published at 99 USD per membership year, with a separate programme for private distribution inside an organisation at 299 USD per year. That cost is set by Apple rather than by any wrapper tool, and it applies once regardless of how many apps are signed.
How much disk space should be budgeted per wrapped app?
A measurement taken on 12 September 2026 gave 205 MB for a single wrapped site, and a second site produced the same figure because the engine is not shared between apps. Budget roughly a gigabyte for five apps, and note that each one also keeps its own cache and storage on top of that.