I believe in native code
Why Xavier and VoxyAI ship native apps on every platform, and why Electron or Flutter would cost more than they save.
Both of my products, Xavier and VoxyAI, ship native apps on every platform they support. Xavier’s device agents are Swift on Mac, Kotlin on Android, and C# .NET on Windows. VoxyAI runs native on every platform it currently lives on, and that list is about to grow.
It’s a specific engineering decision rooted in what each product has to do.
Xavier: agents that have to disappear
Xavier’s agents sit between the operating system and the device management infrastructure. They need to call native APIs that don’t exist in cross-platform frameworks: Endpoint Security on Mac, Device Owner policies on Android, OMA-DM and WinRT on Windows. They need to be lightweight because they run continuously on every managed device. They need to survive OS updates that break abstraction layers.
Electron for a device management agent would be an operational disaster.
An Electron installer ships Chromium with it. That is 150 to 200 megabytes before your code even enters the equation. For a device management agent that IT teams deploy across hundreds or thousands of endpoints, that installer size is a specific problem. Deployment bandwidth, storage on each device, the mental model of “lightweight agent” collapses the moment you ship a browser engine with it.
What’s in the installer
Agent codeBundled browser engine
150–200 GB of Chromium pushed across the network, before a single byte of the agent itself.
Beyond installer size, Electron runs a full Chromium process for a background agent that should be invisible. That is hundreds of megabytes of RAM continuously consumed by your management agent on each device. Multiply by the fleet. Multiply by the fact that each managed device also needs to leave RAM for the actual work the user is doing. Agents that steal resources from users are agents that get uninstalled.
The native helper gets written anyway
Cross-platform frameworks like Electron can reach native OS APIs, but only through specific workarounds that add their own costs. The common pattern is bundling a native helper binary written in Go, Rust, or another language that actually calls the system APIs, then shelling out to that helper from the Electron process. Apple’s Endpoint Security framework, Android’s Device Owner policies, Windows OMA-DM infrastructure. Each of these requires a native component to call correctly. The Electron process coordinates, the native helper does the work, data passes between them through IPC.
Electron + native helper
Native agent
This works, but it means your “cross-platform” agent is actually two or three processes: the Electron process, the native helper, and any supporting daemons. You have paid the Chromium tax for the UI layer and still had to write the native code anyway for the parts that matter. You have added IPC complexity between the layers. You have made debugging harder because failures can originate in any of several processes. You have made the installer larger because you ship both the framework and the native helper binaries. And you have made the agent slower because the critical path now crosses process boundaries that native agents handle in-process.
The honest comparison is not Electron versus impossible. The honest comparison is Electron plus a native helper versus just the native helper, done properly. For device management agents where the entire point is to be lightweight, invisible, and reliable, the simpler architecture wins.
Flutter has the same problem for different reasons. Great framework for mobile apps that need pixel-perfect custom UI. Wrong framework for device management agents that need system-level access and minimal footprint.
VoxyAI: where frameworks fail most visibly
VoxyAI faces similar engineering realities on a different dimension, and the stakes are arguably higher because local AI is where cross-platform frameworks fail most visibly.
Running AI inference locally requires direct access to each platform’s acceleration path. MLX on Apple Silicon talks directly to the unified memory architecture that makes Apple Silicon fast for inference. DirectML on Windows talks to whatever GPU the user has, whether that’s a discrete NVIDIA card, an integrated Intel GPU, or an AMD Radeon. ONNX Runtime provides execution providers that map to specific hardware acceleration available on each platform. These are not APIs with Electron bindings or Flutter plugins that match what the native path offers.
An Electron local AI app typically falls back to CPU inference or to shelling out to a separate inference process. The first means your 27 billion parameter model that runs comfortably on Apple Silicon in native MLX cannot run acceptably at all. The second means you have shipped Chromium plus a separate inference binary plus the model files, and you now have an installer that pushes toward a gigabyte before the user has done anything.
Native · MLX on Apple Silicon
Electron · CPU fallback
Memory pressure is the specific killer for local AI apps built on cross-platform frameworks. If Chromium is consuming 400 megabytes just existing, and you need to load a model that requires 18 gigabytes of RAM for inference, you have burned a meaningful fraction of the user’s available memory on the framework overhead. Native apps that measure in tens of megabytes of overhead leave that memory available for the model and for the user’s other work.
The user experience consequence is specific and visible. Local AI apps built on Electron tend to feel sluggish, consume too much memory, and lose the Apple Silicon or Windows GPU performance that would make the product viable. Native apps on each platform get the full acceleration path and feel like what the hardware can actually do.
The cost, and why I pay it
The tradeoff is real. Native development means writing the same product multiple times in different languages. Initial velocity is slower than a single Flutter or Electron codebase would be.
But I would rather ship fewer platforms done natively and done right than ship everywhere with software that feels wrong on every OS it runs on. Windows users notice when apps do not feel native. Mac users notice. Android users notice.
The native approach is the respect you pay to the people who use your software on the platform they chose.
Chameleon
Something significant is coming for VoxyAI very soon that lives in exactly this philosophy. A new native implementation on a platform VoxyAI has not reached before. Not a port. Not a wrapper. Native from the ground up.
For the first time in my career building products, I gave something a codename. We call it . I started working on it back in July. The codename exists because this one is big enough that I wanted to track it as a specific effort, and because I am honestly not good at keeping secrets. If I called it by its real name, I would have let the surprise slip months ago.
Want to know what Chameleon is? Check back later in the week.