Most desktop developer tools today are web apps wearing a costume. A bundled browser engine, a remote service doing the real work, and a Mac icon on top so it feels like it belongs. It launches, it runs, and for a while you do not notice what that choice cost you.
Then you do. It feels foreign in small ways you cannot quite name. It drops frames on a machine that should never drop a frame. And it asks you to hand your source code to a download you cannot really vouch for. Native on macOS is not nostalgia or purism. For a tool that holds your code and runs on your machine all day, it is a decision about three things: integration, performance and trust. Those three are the entire case.
Integration: speaking the machine’s language instead of reinventing it
The operating system already solved a long list of hard problems. Where secrets live. How file access is granted and revoked. How windows, notifications, sharing and background work behave. A native app uses those solutions. It stores credentials in the Keychain. It asks for file permissions the way the system asks, so you can see and revoke them. It behaves like every other real app on your Mac because it is using the same machinery underneath.
A web app in a wrapper reinvents all of that inside its own sandbox, usually worse. Its own idea of where secrets go. Its own permission model that the OS cannot see into. Its own half-versions of things macOS does properly. Each reinvention is a place where behavior drifts from what you expect and a place where your data sits somewhere the system’s own protections do not reach. Integration is not polish. It is whether the tool participates in the security and permission model you already rely on, or quietly opts out of it.
Performance: a full day of work is not a benchmark
Performance for a tool you keep open all day is not about winning a benchmark. It is about the accumulated tax of every interaction, every render, every background operation, paid across hours, on battery.
A native app compiled for Apple Silicon runs on the metal. It uses the memory and the cores the way the platform intends. A bundled browser engine carries the weight of a whole rendering stack it did not need, in a runtime that was built to display documents, not to be the shell of a tool orchestrating agents and holding a live view of your work. On a quick demo you will not feel the difference. On the fourth hour, with several sessions running, you feel it in the fans, in the battery, in the small lag on every action that a native app simply does not have.
For a local software factory that is supposed to run locally, this compounds. The whole premise is that real work happens on your machine. If the shell around that work is heavier than the work itself, you have spent your hardware on the wrapper.
There is a second-order cost too. A heavier shell leaves less headroom for the work you actually care about. When several agents are running and the machine is already carrying a browser engine it did not need, the tax shows up as contention: the build that should have been quick, the session that stutters while another renders. Native gives that headroom back to the work instead of the frame around it.
Trust: the app has to prove where it came from
This is the one that matters most for a tool you point at your source code, and it is the one the web-in-a-box model handles worst.
macOS does not let a native app run just because you downloaded it. A distributed Mac app is expected to be signed with a verified developer identity and notarized by Apple, which means Apple has checked it for malware and the system can confirm it has not been tampered with since. Staple that notarization to the app and the machine can verify all of it before the first launch, offline. That is a chain of provenance you can actually inspect. You know who signed it. You know it is unaltered. You know it passed Apple’s check.
A tool that is really a website in a frame does not carry that same weight, because the part doing the real work is not the thing you installed. It is a service somewhere else, and what you are trusting is a connection and a privacy policy, not an artifact the OS can verify. For most software that is fine. For the software you are about to give your private code to, “the OS verified where this came from and that nobody touched it” is not a formality. It is the difference between a trust decision you can reason about and one you are taking on faith.
Native and local-first are the same commitment
Notice these three arguments keep pointing at one thing. Integration means using the machine’s real protections. Performance means running on the machine’s real hardware. Trust means the machine can verify what it is running. They are all statements that the machine is where the work actually lives.
That is why native is the real form of local-first AI development. If a tool’s whole promise is that your code and your data stay on your computer, then the tool holding them should be a real citizen of that computer, not a thin shell around a service running somewhere you cannot see. A local-first product delivered as a browser pointed at a remote backend is contradicting its own pitch. The native app, signed and integrated and running on your silicon, is the pitch kept.
I will be fair about the other side, because it is a real trade and not a strawman. Cross-platform web tech is cheaper to build, faster to ship, and reaches Windows and Linux from one codebase. For a lot of products that is exactly the right call, and I am not going to pretend otherwise. But it is a trade, and the thing you trade away is precisely integration, performance and verifiable trust. For a tool whose entire reason to exist is that you can trust it with local code, those are not the parts to trade. They are the product.
Where PaellaDoc fits
PaellaDoc is a native macOS application, built for Apple Silicon, signed, notarized and stapled. That is not a spec-sheet line. It is the same decision as everything else about it. Your code, your product memory, your decisions and your evidence stay on your machine, so the app that holds them is a real app on that machine, using the system’s own protections, running on its own hardware, provable before it launches.
The engines it calls can be remote, if you bring your own keys, or fully local through Ollama. But the factory itself, the thing that holds the durable context, is native and local by design, because that is the only version of the promise that is actually kept.
Next time a developer tool asks for your source, it is worth asking what it actually is. A real app your machine can verify, or a browser pointed at someone else’s server with a Mac icon on it.
Frequently asked questions
Why do native macOS apps still matter for developer tools?
For a tool that holds your code and runs all day, native comes down to three things: integration, performance and trust. It uses the machine’s real protections — Keychain for secrets, the system’s own permission model — runs on Apple Silicon instead of dragging a bundled browser engine, and can be verified before it launches. A web app in a desktop costume reinvents each of those, usually worse.
What does it mean for a Mac app to be signed and notarized?
Signed means the app carries a verified developer identity, so you know who built it. Notarized means Apple checked it for malware and the system can confirm it has not been tampered with since. Staple the notarization to the app and your machine verifies the whole chain before the first launch, offline. For software you are about to give your source code to, that provenance is a trust decision you can reason about rather than take on faith.
Are Electron or web-wrapped dev tools worse for performance?
On a quick demo you will not feel it. Across a full day, a bundled browser engine carries the weight of a rendering stack it did not need, in a runtime built to display documents. By the fourth hour, with several sessions running, the tax shows up in the fans, the battery, and small lag on every action. A heavier shell also leaves less headroom, so builds contend with the frame around the work instead of the work itself.
Is a web-based tool safe to give my source code to?
It is a different trust decision. When the real work happens in a service somewhere else, what you are trusting is a connection and a privacy policy, not an artifact the OS can verify. A native app your machine has signed, notarized and checked is provable before it runs. For most software the web model is fine; for the tool you point at private code, verifiable provenance is not a formality, it is the product.