Electron App Development

A team that ships a React application every week already owns the components, the design tokens and the testing habits an Electron build needs. The desktop shell adds a process model and a packaging step; it does not ask anyone to learn a new way of describing an interface. That is the strongest argument for Electron, and it is the first thing we test. When the front-end work sits with an outside vendor and the program is a thin form over a database, the same argument disappears and a lighter stack deserves the job.

The second question is whether the interface depends on the browser. A product that leans on canvas charts, rich text editing or drag-and-drop layouts is expensive to rebuild in a native toolkit. Electron keeps that work intact, which shortens the schedule and reduces the number of regressions a rewrite would introduce.

Electron runs two kinds of process. The main process owns windows, menus, files and updates; each window runs a renderer that behaves like a browser page. Everything crossing between them is a message, and every message is a place where a careless design leaks authority. We keep the renderer away from the file system, expose a small named API through a preload script, and validate arguments on the main side. Context isolation stays on, and Node integration stays off in any window that loads remote content, because one injected script would otherwise reach the whole machine.

Typed channels make the boundary easier to review. When each command has a name, a parameter shape and a return shape, a reviewer can see exactly what the page is allowed to ask for. That list is also the document a security tester will want before an internal release.

Windows users expect a menu bar inside the window; macOS users expect it at the top of the screen and a dock icon that behaves. Close buttons, minimise behaviour, single-instance rules and file associations all differ. None of this is difficult, but each item is a decision that has to be made deliberately, and the defaults are wrong for at least one platform. We write the platform conventions into the acceptance list before build, then check them on real machines in the final week.

Keyboard shortcuts deserve the same treatment. A shortcut that reads naturally on a Windows keyboard can collide with a system gesture on a Mac, and a tray icon that looks fine in a screenshot may disappear behind a notification area setting. These are the details that decide whether staff describe the program as software or as a website in a frame.

An unsigned installer triggers warnings that no internal rollout survives. Windows needs an Authenticode certificate, and SmartScreen reputation accumulates only after a track record. macOS needs a Developer ID certificate, hardened runtime settings and notarisation before Gatekeeper opens the program quietly. Those steps belong in the schedule, not in a handover note. We prepare the pipeline to sign automatically, keep private keys under your organisation control, and document what happens when a certificate approaches expiry.

Signing also affects updates. The feed that delivers a new version must be signed with a key the installed application already trusts, or the update is refused. Rotating that key is a planned operation with a published path, not an emergency performed on a Friday evening.

An installed program needs a way to receive fixes without a support call. We use a signed update feed with a stable channel for staff and a test channel for internal verification. The application checks in the background, downloads quietly and asks before restarting. A bad release needs an exit: the previous installer remains available, the feed can be pointed back, and the support note says who may trigger a rollback.

Machines behind a proxy or an inspection appliance are a common obstacle. We test the update path on that network rather than assuming office broadband, because a download that stalls at ninety per cent is worse than no update mechanism at all.

Electron installers commonly land between eighty and two hundred megabytes depending on dependencies, and idle memory reflects the Chromium processes underneath. On a recent laptop that is unremarkable. On a four-year-old office desktop with a mechanical disk, startup time is the number users notice. We measure cold start, idle memory and installer size on the oldest supported machine, then decide whether the interface needs trimming.

A large table rendered eagerly will cost more than the runtime ever does. Virtualised lists, lazy routes and a smaller icon set often recover more memory than a framework change would, and they carry less risk.

When installer size is a product requirement, when the program must run on modest hardware, or when the team already writes Rust, Tauri is the more honest choice. It uses the system webview instead of bundling one, which changes the dependency profile and the debugging story. We compare the two on the actual target machines rather than on a feature grid. If the program is mostly a local file utility with two screens, neither framework is needed and a smaller tool would do.

An inherited Electron project is worth reading before it is extended. We look for remote content loaded into a privileged window, disabled context isolation, update feeds without signatures, and a renderer that writes files directly. Those findings explain most of the security work in a takeover. The review produces a short list with effort attached, so a buyer knows whether the codebase is a foundation or a liability before committing to a roadmap.