Why Bloated Software Is Finally Becoming Unacceptable

The short answer

Companies are replacing Electron with native Swift or Rust for the same reason they are rethinking SaaS subscriptions: the hidden cost finally got visible. Electron apps idle at 150 to 400MB of RAM and ship 80 to 200MB installers because they bundle a full Chromium browser and a Node runtime just to render a window.¹² Native Swift or Rust equivalents commonly idle at 15 to 80MB and ship installers in the single digits to low tens of megabytes.²³ With AI coding tools now making native development fast enough for small teams, that gap is no longer a cost companies are willing to eat by default.

This isn't a call to rewrite every desktop app tomorrow. It's a comparison of what you actually get, and give up, when you pick native over Electron for the tools your company builds itself.

Why Electron won in the first place

Electron let web teams ship a desktop app without learning a second stack. One codebase, one team, three platforms. That trade was rational when engineering time was the scarcest resource and RAM was cheap. Slack, Discord, VS Code, Notion, and 1Password all shipped this way, and for products with huge cross-platform surface area and small teams, it still makes sense.⁴

But the tax was always there. Slack's own engineers documented the problem publicly: each open workspace ran its own full webview, consuming between roughly 130MB at the 10th percentile and 960MB at the 99th percentile per team, before Slack built a stripped-down background client just to claw memory back.⁵ That was Slack, with a dedicated performance team, in 2017. Most internal tools do not get that investment.

The comparison, by the numbers

The installer and memory gaps are not marketing exaggeration. A team that rebuilt a Mac media-indexing app in Rust with Tauri reported an 83% smaller app (1GB to 172MB) and a 70% smaller installer, plus indexing that dropped from 10 to 14 minutes down to about 3 minutes for the same 38-minute video file.⁷ That is the kind of gain that shows up in support tickets, not just benchmarks.

The bug that made the tax visible

For years, "Electron is heavy" was an abstraction most people tolerated. In late 2025, it stopped being abstract. Electron apps on macOS Tahoe were found to override a private AppKit API used for window corner rendering, and the bug caused system-wide stutter: scrolling and window dragging lagged across the entire OS, in apps that had nothing to do with Electron, as long as one Electron window was visible on screen.⁸ Slack, Discord, Zoom, and other major apps had to ship patches, and Apple ultimately fixed the underlying exposure at the OS level in macOS 26.2.⁸⁹ A single cross-platform framework choice, made for developer convenience, degraded machines it wasn't even running the foreground app on. That is a governance problem as much as a performance one: nobody signed off on private API usage becoming everyone's problem.

Why the switch is happening now, not five years ago

Three things changed at once.

AI coding tools closed the skill gap. Writing a native macOS app in Swift, or a cross-platform tool in Rust with Tauri, used to require specialists most teams didn't have on staff. Coding agents and IDE assistants have made unfamiliar languages tractable for generalist engineers, which is part of why open-source projects like QuillCode (a fully Swift coding agent) and h5i (a lightweight Rust sandbox) have appeared as native alternatives to Electron-based coding tools.¹⁰ The barrier was never really the language. It was the ramp-up time, and that ramp-up time has compressed.

Lightweight frameworks matured. Tauri, the most common Rust-based Electron alternative, wraps the OS's native webview instead of bundling Chromium, which is where most of the size and memory savings come from.¹³ It is not the only path to native, but it is the one most web teams reach for first because it keeps the frontend code they already have.

Build-vs-buy math shifted for internal tools. Companies that once rented a SaaS product because building anything felt too expensive are now weighing "build it ourselves, and build it properly" against a subscription that keeps rising. When you're going to own the tool, you're less willing to also own its resource bloat.

When Electron still makes sense

Native is not a universal upgrade. A solo developer building a menu-bar utility for a small folder-watching job gets real gains from Swift: on-device OCR, Finder tag integration, and idling at 15MB instead of 80 to 150MB.³ But a cross-platform SaaS dashboard that is mostly forms and search over small JSON, shipped by a small web team to Windows, Mac, and Linux at once, is often still better served by Electron or Tauri than by three separate native codebases.⁶ The deciding factor isn't ideology. It's workload: heavy filesystem access, on-device ML, or all-day background running favor native. Simple CRUD over an API, shipped by one team to many platforms, still favors a shared web-based runtime.

What this means if you're evaluating internal tools

If your team is building rather than buying, the framework choice is no longer a footnote. An internal tool that runs on every employee's machine, all day, compounds a bad memory footprint across your whole org. That's the same math that shows up when companies weigh a SaaS subscription against a purpose-built internal app: the sticker price is one number, but the resource cost, whether it's dollars per seat or megabytes per idle window, is the one that actually adds up. Tools like Remy that compile a description into a real backend and frontend are part of the same shift: teams increasingly want software they fully own and can hold to a performance bar, not a black box they just installed.