Why I Ditched Electron for Native SwiftUI on macOS

Like almost every web developer building a desktop tool in the early 2020s, I defaulted to Electron. It made sense at first: I already knew TypeScript, CSS, and React, so I could share code between our web dashboard and the macOS client app with minimal friction.

It worked, but it felt sloppy. Every time a user launched our tiny menu bar utility, macOS was forced to spin up a full Chromium browser instance, a Node.js runtime process, and an internal IPC bridge.

Last month, I spent two weekends rewriting the entire application from scratch in Swift and SwiftUI. The results proved why native desktop software still matters.

The Memory and Battery Reality Check

Let us look at the Activity Monitor numbers side by side on macOS Sonoma:

Metric                 Electron Build       SwiftUI Native Build
-----------------------------------------------------------------
Idle RAM Footprint     442 MB               17.8 MB
Launch Time to Interactive 1,280 ms         110 ms
Binary Download Size   84 MB                6.2 MB
CPU Wakeups / Second   14 wakes             0.2 wakes

Our users noticed the difference immediately. On a MacBook Air running on battery power, having a 400MB Electron app running in the background constantly prevents the CPU from dropping into its lowest C-states. The native Swift binary essentially sleeps with zero CPU tax until a user clicks the status item.

Why Native Code Feels Different

It is not just about raw memory numbers. It is about how the application feels under your fingers:

1. Instant Window Displays: In Electron, showing a hidden window requires a compositor frame submission that often stutters by two or three dropped frames. In SwiftUI, the AppKit window server draws instantly.
2. System Accent Colors and Accessibility: VoiceOver, dynamic typography scaling, and macOS system tinting work out of the box with zero CSS monkey-patching.
3. App Store Sandbox Compliance: In Electron, entitlements and notarization scripts constantly break whenever Apple updates Xcode command line tools. In native Swift, codesigning takes five seconds.

// Sample lightweight menu bar item in pure SwiftUI
import SwiftUI

@main
struct DeveloperMenuBarApp: App {
    @StateObject private var monitor = SystemMonitor()

    var body: some Scene {
        MenuBarExtra("LighterLine Dev", systemImage: "bolt.fill") {
            ContentView(monitor: monitor)
                .frame(width: 320, height: 420)
        }
        .menuBarExtraStyle(.window)
    }
}

The Real Cost of Going Native

I will not pretend this transition was free. Writing Swift means giving up the endless npm ecosystem. You do not have 10,000 React component libraries on GitHub to copy and paste from. You have to write your own view state bindings, manage memory references, and read Apple Developer documentation.

Was it worth the extra effort? Absolutely. Great software should treat user hardware with respect.