The Easy Path vs. The Right Path
When you tell people you're building a remote desktop app from scratch in 2024, the first question is always: "Why not just use Electron?"
It's 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. Native Windows APIs. 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 isn't a luxury. It's a requirement.
The Electron Tax Is Real
Let's start with what Electron actually is: a Chromium browser window pretending to be a desktop app. That's not a criticism — it's architecture. And for many applications, it's perfectly fine.
But for a remote desktop app? You're literally streaming pixels from another computer and rendering them in real time while capturing every input event and sending it back. Latency isn't a nice-to-have. It's the entire product.
Here's what we measured when prototyping both approaches:
That 380MB isn't Electron being "bloated." It's Chromium doing its job — running a full browser engine with V8, a GPU process, utility processes. It's impressive engineering. It's just engineering designed for a different problem.
Startup time told a similar story. Our native macOS app cold-starts in under 200ms. The Electron prototype took 2-3 seconds. For a tool you might launch 20 times a day, that difference compounds into genuine frustration.
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 16ms of input latency and a designer can't draw smooth curves. Add 32ms and a gamer can't play.
With native rendering, we talk directly to the GPU. On Apple platforms, Metal gives us direct access to hardware video decoding. We can take an H.265 frame off the network, decode it in hardware, and display it — all without the frame ever touching main memory. The decode-to-display pipeline can run in under 4ms.
In Electron, that same frame has to travel through Chromium's compositor, through the IPC bridge, get 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 didn't choose native to be purists. We chose it because the physics of our problem demanded it."
Platform Citizenship
Here's something the "write once, run anywhere" crowd rarely talks about: users can tell.
They can tell when an app doesn't respect system dark mode transitions. When scroll physics feel slightly wrong. When the app doesn't appear in Spotlight or doesn't handle macOS window management properly. When the context menu looks like a web page instead of a native menu.
These aren't "nice-to-haves." They're the difference between an app people tolerate and an app people love. On iOS, this is especially critical — the App Store review team will reject apps that feel non-native.
With SwiftUI, we get all of this for free. Dynamic Type, VoiceOver accessibility, system haptics, multitasking on iPad, keyboard shortcuts on Mac Catalyst — we're not reimplementing platform features. We're using them.
The Cost Is Real Too
Let's 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 (written in Go and C), 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've 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's what we've learned: the hardest path and the right path are often the same path. Our users don't know or care about our architecture. They just know that Remio feels fast, feels right, and doesn't 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 <45MB memory footprint instead of 380MB.
Most importantly, it gave us a technical moat. Building native across four platforms is hard enough that most competitors won't do it. That difficulty is our advantage.
The remote desktop category has been dominated by Electron-wrapped web apps and legacy native apps that haven't been meaningfully updated in years. We believe there's room for something that's both modern and native. Something built from scratch with today's hardware in mind.
That's Remio. Built the hard way, because some things are worth doing right.