Your web product now needs something the browser cannot comfortably provide.
It may need reliable access to local files, a system tray process, global keyboard shortcuts or a controlled offline workflow. The development team proposes Electron because much of the existing React or JavaScript application can move into a desktop package. That can be a sound way to reach Windows, macOS and Linux without building three products from scratch.
The decision is larger than wrapping a website. You are taking responsibility for a privileged desktop application, its installers and every update that follows.
“One codebase for the desktop” is a fair Electron pitch
Electron gives a web team a familiar renderer and a Node.js main process with access to desktop APIs. Its multi-process model follows Chromium: renderer processes display the interface while the main process owns the application lifecycle and privileged operations.
That separation can let a business reuse interface components, validation rules and API contracts from an existing web product. It also avoids maintaining a full native interface for each operating system. The saving is strongest when the application already has a substantial web codebase and the desktop-only features are clear.
Shared code does not remove platform work. Installers, permissions, file paths, window behaviour and release testing still differ by operating system.
Electron desktop apps ship their own browser runtime
An Electron application includes Chromium and Node.js. This gives the team a known browser engine on each supported machine, but it increases the installer size and establishes a higher memory floor than a small native utility or a browser tab.
Do not accept a generic claim that the overhead is fine. Ask for measurements from the proposed application on the oldest supported machines. A workflow used all day on a managed laptop has a different tolerance from a utility opened once a month. Startup time, idle memory and memory under a representative workload are the figures that matter.
The bundled runtime creates an upgrade obligation as well. Electron tracks Chromium releases so security fixes move quickly. Leaving the desktop app on an old Electron line means leaving a browser engine and Node runtime behind with it.
The Electron security boundary has to be designed
A browser page normally runs inside a tight sandbox. An Electron app can reach the file system, operating-system shell and other privileged services, so the bridge between the renderer and the main process becomes part of the security design.
Electron’s security checklist calls for context isolation, process sandboxing, a restrictive Content Security Policy and careful validation of inter-process messages. It also warns against exposing Electron APIs to untrusted web content. These are architectural constraints, not settings to add during the final review.
Ask the team to show the preload API. It should expose the smallest set of named operations the interface needs. A renderer that can invoke arbitrary Node.js functions or pass unchecked commands into the main process has erased the boundary Electron provides.
Electron code signing and auto-updates are product work
Development can feel quick until the first release. Public distribution brings certificates, macOS notarisation, Windows reputation warnings, architecture-specific packages and a secure place to publish update metadata.
Electron’s code-signing guide explains why unsigned applications trigger operating-system checks. Its update documentation also shows that release metadata and packaging differ across platforms. Test the update path from older installed versions as well as a clean machine.
Put certificate renewal, signing access and emergency releases into the operating plan. If the person who first configured the build leaves, the company still needs to issue a trusted update.
Windows, macOS and Linux remain separate acceptance tests
Electron shares application code. It does not make three operating systems behave alike.
Native menus, tray icons, permissions, deep links, notifications, window controls and keyboard conventions need platform-specific checks. Accessibility tools differ too. An interface that passes keyboard and screen-reader testing on Windows has not proved the macOS build.
Decide which platforms and processor architectures are commercially supported. “It builds on Linux” is weaker than a tested list of distributions, packaging formats and update behaviour. Supporting every combination can consume the saving that justified Electron in the first place.
Questions to ask before funding an Electron desktop app
- “Which requirement cannot be met well in the existing browser product?” Make the desktop need explicit.
- “What percentage of the current interface and business logic will be reused?” Ask for a code-level assessment.
- “What are the startup time and memory targets on our oldest supported device?” Test a production package.
- “Which operations cross from the renderer into the main process?” Review the preload and IPC boundary.
- “Who owns certificates, notarisation and update infrastructure?” Name the operational owner.
- “Which operating systems, versions and processor architectures will we test?” Avoid an open-ended support promise.
- “How will an installed app recover from a failed update?” Include rollback in the release design.
When Electron fits an existing web product
Electron is a strong candidate when a proven web application needs a desktop companion across several operating systems. The team should already understand the web stack, and the product should gain something material from local files, background behaviour, offline work or deeper operating-system integration.
It also suits internal applications where the company controls the devices and distribution route. A narrower hardware baseline makes testing, signing and updates easier to own. The case improves when the interface is complex enough that reusing existing components removes substantial duplicate work.
When a browser or native build is the better spend
Keep the product in the browser when the desktop proposal adds no capability users need. A Progressive Web App may already cover installation, offline caching and notifications without a separate privileged package.
Choose a lighter desktop runtime or platform-native development when installer size, idle memory, battery use or deep native behaviour is central to the product. A single-platform specialist tool may gain more from the operating system’s own UI framework than it saves through shared web code.
And do not promise all three desktop platforms by default. If nearly every paying user is on Windows, fund and prove that route first. Expansion can follow the evidence.
Approve the desktop need first. Electron comes second.
I use Electron when the product needs desktop access and an existing web codebase gives us something worth reusing. I price signing, updates and platform testing from day one because they are part of the product. Packaging a browser-grade product for appearances is work I will not ask a client to fund.
Alexander De Sousa · Founder, Digital Royalty · LinkedIn
The evidence for packaging the product with Electron
The code reuse is attractive. This is the rest of the decision that needs an owner and a test before the desktop budget is approved.
The Electron commitment in six facts
- Role in the product
- A desktop runtime that combines a Chromium renderer with a Node.js main process and operating-system integrations.
- Customer effect
- Installation, offline workflows and local-device access. Customers also inherit a larger application and its update behaviour.
- Adoption cost
- Moderate when a mature web interface can be reused. Signing, packaging and platform-specific edge cases often set the real schedule.
- Ongoing owner
- A product engineering team that owns Electron upgrades, privileged IPC, certificates, release channels and support across each promised platform.
- Exit cost
- Moderate to high. Web-facing code can travel, while desktop integrations, update infrastructure and Electron-specific APIs need replacement.
- Proof required
- A signed production package tested for startup, memory, accessibility and updates on representative Windows, macOS and Linux machines.
Other credible routes to a desktop product
-
Keep the browser product
Right when: Installation, offline caching and notifications cover the need without broad access to the local operating system.
Watch for: Confirm browser support for the exact file, background and device capabilities the workflow needs.
-
Tauri
Right when: A web interface is useful but application size and a narrower native command surface matter enough to accept a Rust-based desktop layer.
Watch for: System webviews vary by platform. Test rendering and every required plugin on the supported operating systems.
-
Flutter desktop
Right when: The product wants one cross-platform UI codebase and has no valuable web component library to preserve.
Watch for: This is a new application stack. Team skills, platform integrations and the migration of shared business logic need their own estimate.
-
A platform-native application
Right when: One operating system dominates and deep native behaviour, footprint or device integration matters more than cross-platform reuse.
Watch for: Adding another desktop platform later creates a second implementation and a second team capability to maintain.
Research behind this Electron recommendation
-
Official architecture
Electron process model
Documents the Chromium-derived main and renderer processes. The boundary is the basis for both code reuse and privileged desktop access.
-
Official security
Electron security checklist
Sets out context isolation, sandboxing, restrictive content policies and IPC validation. It also makes current Electron releases an operating requirement.
-
Official distribution
Electron code-signing guide
Explains the trust warnings around unsigned apps and the platform-specific signing work needed for public distribution.
-
Official operations
Electron application updates
Shows the separate metadata and packaging paths behind auto-updates. Shipping the installer is only the start of the release system.
-
Production case
Visual Studio Code process sandboxing
Microsoft's account of moving a large Electron app into process sandboxing shows that the security boundary can require architectural work.
-
Practitioner question
Stack Overflow: context isolation and renderer access
A recurring renderer question traces back to safer defaults. Convenience code that expects unrestricted Node access conflicts with the intended boundary.
-
Community discussion
Reddit: maintaining a three-platform release process
A maintainer describes signing and packaging as a brittle cross-platform job. The thread is anecdotal, but it identifies work a delivery trial should cover.
Tell us what you need
A few quick questions, then a straight answer from a real person — usually within a few hours.
Tell us what you're working on
Whether it's a new site, a platform, or a process that shouldn't be manual any more — we'll tell you honestly if we can help.