Too many Mac apps are being built with Electron

Electron’s Purpose and Tradeoffs

• Many argue Electron is acceptable or even essential: it enables cross‑platform apps and web versions with shared code, especially for startups and VC‑funded companies.
• Common framing: pick two of three—low price, feature parity, performance. For apps like Slack, Discord, Spotify, WhatsApp, users and businesses have mostly chosen price + parity over performance.
• Others counter that this “good enough” mindset normalizes bloat and poor UX, forcing users to buy ever‑faster machines to keep up.

Native vs Cross‑Platform Development

• Native Mac apps are praised as faster, leaner, and more integrated (BBEdit, iTerm, Transmit, Telegram native clients).
• But building and maintaining separate native apps per platform is described as very costly and organizationally complex; platform churn on Apple (Toolbox/Carbon/AppKit/SwiftUI, Objective‑C/Swift) worsens this.
• Alternative toolkits (Qt, wxWidgets, QML, Avalonia, Flutter, Godot) are mentioned as “middle ground,” with some claiming they can look modern and be highly efficient, others saying they still “suck, just less” than Electron.

Performance, Resource Use, and UX

• Anecdotes range from WhatsApp launching in ~1 second on recent Macs to taking 16 seconds or several minutes to sync large histories. Some blame the app, others the hardware or setup.
• Electron is criticized for multi‑process overhead and high RAM/CPU use; counter‑claims note some native apps are just as heavy and that Electron itself is not always the bottleneck.
• Examples: new Teams perceived as extremely slow; Slack and Outlook seen as acceptable; Apple Music criticized as a laggy, buggy native app compared to Electron‑based Spotify.

Browser Tabs, PWAs, and “Just Use the Web”

• Some prefer running services like Slack/WhatsApp in browser tabs for extensions, tabbed workflow, and avoiding multi‑hundred‑MB app installs.
• Others value desktop apps for dock icons, Cmd‑Tab switching, OS‑level app management, badges, and notifications.
• PWAs divide opinion: concept liked, but some see them as undermining user‑controlled browser environments and gaining exclusive APIs. Firefox dropping PWA support is noted with frustration.

Economics and Business Incentives

• Multiple comments emphasize that Electron apps often “compete with not existing at all,” especially on macOS and Linux.
• Coordinating parallel native teams, keeping feature parity, and handling platform differences are portrayed as major overhead compared to a single Electron/Web stack.
• Some suggest Apple could mitigate this by making Swift/SwiftUI more cross‑platform, but doubt Apple will.

APIs and Third‑Party Native Clients

• One line of argument: services shouldn’t ship native apps at all; they should expose full APIs and let independent developers build native clients.
• Historical example: Twitter’s third‑party app ecosystem flourished before being curtailed by the company.
• Objections: such wrapper apps are “boring,” hard to monetize at scale, and can be undermined when platforms change auth rules or ban unofficial clients. A discontinued lightweight Slack/Discord client is cited as a casualty of both economics and platform policy.

Critiques of the Article and of Apple

• Some see the article as biased “Mac‑native boosterism,” especially given it’s hosted on a Mac‑only app’s blog and compares a local text editor against a rich, cloud‑syncing messenger.
• Others accuse Apple of overpriced, low‑RAM machines that make users unusually sensitive to bloat, and note Apple’s own native apps (e.g., Music, Reminders) often feel slow or poorly engineered.
• Still, a subset insists native UX is meaningfully better, even if market forces mean many apps will never be native.