Why we chose native over Electron (and would do it again)

The easy path vs the right path

When you tell people you are building a remote desktop app from scratch in 2024, the first question is always: "Why not just use Electron?"

It is a fair question. Electron powers some of the most successful apps on the planet — VS Code, Slack, Discord, Figma's desktop wrapper. It lets you write once and deploy everywhere. Your web developers become desktop developers overnight. The time-to-market advantage is real.

We looked at the numbers, weighed the tradeoffs, and chose the hardest possible path: fully native on every platform. SwiftUI on iOS and macOS. Jetpack Compose on Android. C++/WinRT on Windows. Metal for rendering on Apple. Vulkan on everything else. A custom Go server at the core.

Not because we enjoy suffering, though some days it feels that way. Because for this kind of app, native is not a luxury. It is a requirement.

The Electron tax is real

Let us start with what Electron actually is: a Chromium browser window pretending to be a desktop app. That is not a criticism — it is architecture. And for many applications, it is perfectly fine.

But for a remote desktop? You are streaming pixels from another computer and rendering them in real time while capturing every input event and sending it back. Latency is not a nice-to-have. It is the entire product.

Here is what we measured when we prototyped both approaches:

• Memory — Native client steady-state: ~45 MB. Electron prototype: ~380 MB. An 8.4× difference at idle, before either app starts decoding a single frame.
• Cold start — Native macOS app cold-starts under 200 ms. The Electron prototype took 2 to 3 seconds. For a tool you launch twenty times a day, that compounds into genuine friction.
• Battery — On a Mac running on battery, the Electron build pulled roughly 3× the wattage during an idle connection. Chromium does not sleep cheaply.

The 380 MB is not Electron being bloated. It is Chromium doing its job — V8, a GPU process, utility processes, an entire browser engine. It is impressive engineering. It is just engineering designed for a different problem.

Frames matter more than features

Remote desktop is one of the few app categories where every single frame matters. Drop a frame and the user feels it. Add 16 ms of input latency and a designer cannot draw smooth curves. Add 32 ms and a gamer cannot play.

With native rendering, we talk directly to the GPU. On Apple platforms, Metal gives us direct access to hardware video decoding. We take an H.265 frame off the network, decode it in hardware, and display it — without the frame ever touching main memory. The decode-to-display pipeline runs under 4 ms on a modern Mac.

In Electron, that same frame travels through Chromium's compositor, through the IPC bridge, gets painted by Skia, then composited again by the OS. Each hop adds latency. Each hop adds jitter. And jitter — inconsistent frame timing — is what makes remote desktop feel off even when average FPS looks fine.

We did not choose native to be purists. We chose it because the physics of our problem demanded it — 8 ms LAN glass-to-glass leaves no room for a browser in the middle.

Native vs web capability ledger

The Electron-vs-native debate often gets stuck in vibes. So we wrote down the seven OS capabilities Remio depends on every second of every session and asked, plainly: how does each one fare under each runtime?

Each row is a feature we ship today. Each — on the web column is a workaround we would have to invent, document, and apologise for. Going native means we treat those capabilities as primitives rather than polyfills.

Platform citizenship

Here is something the write-once-run-anywhere crowd rarely talks about: users can tell.

They can tell when an app does not respect system dark-mode transitions. When scroll physics feel slightly wrong. When the app does not appear in Spotlight or does not handle macOS window management properly. When the context menu looks like a web page instead of a native menu.

These are not nice-to-haves. They are the difference between an app people tolerate and an app people love. On iOS this is especially critical — App Store review will reject apps that feel non-native, and rightly so.

With SwiftUI, we get all of this for free. Dynamic Type, VoiceOver accessibility, system haptics, multitasking on iPad, keyboard shortcuts on Mac. We are not reimplementing platform features. We are using them.

The cost is real too

Let us be honest about the downside: going native is expensive. Not in dollars — in time and complexity.

We maintain four UI codebases. Our networking and codec layer is shared (Go for signaling, C++ for the streaming protocol), but every pixel you see on screen is platform-specific code. A feature that takes one day in Electron takes us three to five days, because we build it four times, tuned for each platform.

We have had weeks where a single animation worked beautifully on iOS, was broken on Android, and was janky on Windows. The debugging matrix is brutal.

But here is what we have learned: the hardest path and the right path are often the same path. Our users do not know or care about our architecture. They know that Remio feels fast, feels right, and does not eat their battery for breakfast.

Would we do it again

Without hesitation.

The native approach gave us performance that Electron fundamentally cannot match for this use case. It gave us apps that feel like they belong on each platform. It gave us a sub-45 MB memory footprint instead of 380 MB. It gave us 8 ms LAN glass-to-glass latency where a browser-wrapped competitor sits north of 60 ms.

Most importantly, it gave us a technical moat. Building native across four platforms is hard enough that most competitors will not do it. That difficulty is our advantage.

The remote desktop category has been dominated by Electron-wrapped web apps and legacy native apps that have not been meaningfully updated in years. There is room for something that is both modern and native — something built from scratch with today's hardware in mind.

That is Remio. Built the hard way, because some things are worth doing right.