Electron development: where a desktop application breaks under real workloads
Electron development almost always starts the same way: the application comes together quickly, the demo goes smoothly, and a month into operation the complaints begin.
The user leaves the window open all day — and by evening the process is eating memory, the interface lags, and a restart only helps temporarily.
The cause is not the platform itself, but the fact that no one is watching the lifecycle of windows and background tasks: listeners are not removed, the cache grows endlessly, tabs do not release resources.
The second class of failures is updating the desktop application. If the build is downloaded in full on every start, users on a weak connection get either a long launch or an interrupted download and a corrupted distribution.
Failures on a weak network complete the picture: synchronization with the server fails without retries, local data diverges from server data, and after the connection is restored no one reconciles them back.
A separate story is the corporate environment. Antivirus blocks writing to system directories, policies prohibit autostart, a proxy cuts connections, and an application that worked perfectly on the developer's machine simply does not start for half the employees.
Here errors surface not in the application logs, but in security logs, where the team usually does not look.
The cost of each such failure is not a line in the tracker, but lost working hours and undermined trust in the product: people go back to the browser version or to spreadsheets. We break down how this is closed at the architecture level, rather than with cosmetic patches.
Electron Application Architecture: Operating Modes and Measurable Effect
Desktop Client Operating Modes
The Electron application architecture is built around three layers: the rendering process, the background process, and the data access layer. This separation matters because it determines which classes of failures are eliminated.
If the network layer and the local cache live in the same process as the interface, then a hung request to the server blocks rendering — the window "goes white" and the user closes the application.
Moving server communication into a separate thread eliminates this class entirely: the interface remains responsive, and network errors are handled in the background.
Local cache and synchronization is the second most important layer. Data is written to local storage (SQLite or IndexedDB) and synchronized with the server via a change log.
This enables an autonomous operating mode for the application: an employee works with requests, documents, or reference data without a connection, and when the network appears, changes are sent to the server. Conflicts are resolved by record versions, not by "whoever wrote last is right."
What Goes Away with the Right Architecture
- Data loss during connection drops — the change queue is stored on disk and survives restarts.
- Interface freezing on heavy operations — exports, reports, and synchronization run outside the rendering process.
- Desynchronization between devices — the change log and record versions provide a predictable order of application.
- Fragile updates — client updates go through a separate channel, and rollback to the previous build remains possible.
| Option | When it fits | Limitations |
|---|---|---|
| Online only | Stable channel, office work | Any connection drop halts work |
| Local read cache | Reference data, catalogs, reports | Writing still requires a network |
| Full autonomous mode | Field employees, warehouses, sites without connectivity | Conflict resolution logic is required |
| Hybrid with queue | Mixed scenarios | More complex testing of synchronization scenarios |
Electron provides a single codebase for Windows, macOS, and Linux, but the value here is not in cross-platform capability itself, but in the fact that the listed layers are designed once and carried across platforms without rewriting.
How we run implementation: from task analysis to code handover
Developing a desktop application on Electron starts not with code, but with an inventory of the environment: which platforms users work on, which operating system versions are in use, whether there are corporate policy and proxy restrictions, and how the application will access local files and peripherals.
This determines the process architecture: where the business logic lives, what goes into the main process, what goes into auxiliary ones, and how data exchange with the interface is organized.
A mistake at this step is the most expensive — rewriting the integration layer after the application has already been built will have to be done entirely.
After that, the work proceeds in stages, each ending with a verifiable result.
- Environment and requirements audit. We record the target platforms, offline and online usage scenarios, data sources, and access and permission requirements. The output is an agreed list of scenarios that the application must cover.
- Application design and prototype. We design the separation of processes, the local storage layer, and the mechanics of autonomous operation when the network is lost. We assemble a working skeleton that launches on all target platforms.
- Build and signing setup. We configure the build for each platform and set up application signing and notarization — without this, the operating system blocks installation, and the user sees a warning instead of the product.
- Update policy. We define the update delivery channel, the version release procedure, the application's behavior when rolling back to a previous build, and when updating during active user work.
- Desktop client testing. We check not only the logic but also behavior in real scenarios: clean installation, update over an older version, uninstallation, operation under a restricted account, long session, and recovery after a failure.
- Handover of source code and documentation. We hand over the repository with history, build configurations, version release instructions, and a description of architectural decisions — the client's team can develop the product without us.
- Post-launch support. We handle the first users' requests, fix discovered defects, and, if necessary, adjust the update policy based on the actual operating picture.
This order delivers a predictable result: the application installs without manual workarounds of protection, updates in a controlled manner, and the source code and documentation remain with the client. Describe your task — we will come back with an estimate and a work plan.
How does an Electron app differ from native development for each system?
Electron development is built around a single engineering trade-off: the app is written as a web page, and system calls go through a runtime layer that carries a browser engine and a runtime environment.
Native development for each system means separate projects in different languages and different build tools. From there, everything else diverges: a single codebase versus several, one release pipeline versus three, one shared set of libraries versus three sets.
A single codebase is the main argument. Interface logic, network handling, data parsing, and screen states live in one repository and are built for all target systems from a single commit.
A defect found on one platform is fixed once and goes into all builds; in the native scheme, the same defect has to be reproduced and closed three times, and divergence in behavior between versions becomes a constant background.
The speed of releasing versions differs by a multiple: a fix reaches users in one build cycle rather than three parallel ones.
Access to system APIs is where the decision is made deliberately. Notifications, file system access, clipboard, autostart, tray, global hotkeys, and in-place updates are covered through the runtime.
Whatever is not available out of the box is wrapped in an extension module in a system language, and this is the only part that is written separately for each platform.
Native development provides direct access to everything, including deep integration with hardware and system services, but the price for this is separate implementations.
Weight and resource consumption are the flip side. The app carries its own rendering engine, so the installation package and the amount of memory occupied are higher than those of a native counterpart, and cold start is longer.
For interface tasks, editors, internal system clients, and work panels, this is unnoticeable against the gain in maintenance.
For background services, work with heavy graphics, and strict requirements for responsiveness on weak hardware, the difference becomes decisive — there, a native build is justified.
The cost of maintaining versions is what shows up over the horizon. One pipeline, one set of dependencies, one security update across all platforms versus three parallel branches that must be kept in working order synchronously.
The decision is made not by taste but by the load profile: where platform coverage and speed of change matter more, a single codebase is chosen; where resources and deep system integration are critical, native builds are chosen.
Case study: desktop client for an internal system — metrics before and after
The customer's internal system lived in the browser: operators opened it in multiple tabs, pulled some reference data manually from exports, and long sessions broke when switching networks.
A shift of 40 operators accounted for 15-20 manual reconciliations per day, each taking 5-10 minutes, and 3-4 session drops, after which work had to be started over.
Updates were rolled out via an instruction: close the tabs, clear the cache, log in again — this took up to half an hour of downtime at each workstation.
We built a desktop client on Electron: a local storage layer for reference data, background synchronization with the server, and automatic application updates.
The operator works in a single window, data is not lost when the connection drops — the client sends the changes once the channel is back.
What changed in numbers
- Application launch time — from 25-30 seconds (cold start of the browser with cache warm-up) to 3-4 seconds.
- Session stability: drops requiring re-login are gone — the share of interrupted shifts fell from 12% to zero.
- Manual operations: reference data reconciliations dropped from 15-20 to 1-2 per day, the rest is handled by background synchronization.
- Updates: instead of half an hour of downtime at each workstation — silent delivery on the next launch, downtime of 1-2 minutes.
Why it turned out this way
The key factor was not the move to desktop itself, but the local cache and the deferred-send queue: the client stopped depending on the quality of the channel in the moment.
Auto-update was built on signed builds with rollback to the previous version — if a new build fails the integrity check, the client stays on the working one.
The mechanics of auto-update and build signing were built on the model described in the Electron documentation: a separate update channel, signature verification before installation, and storage of the previous version for rollback.
What if the customer has their own update server? The client is configured to an internal source — no external addresses are needed, all traffic stays within the perimeter.
What if some operators work on weak machines? The local cache is capped by size, heavy exports are streamed, without loading the entire reference dataset into memory.
What the customer received: signed builds for the required platforms, update channel configuration, a synchronization scheme and deferred-send queue, a rollback policy to the previous version, a guide for the support service, and a release process for new versions. Describe your system — we will come back with an estimate and a migration plan.
Doubts before the start: compatibility, migration, rollback, and access
Before the start, the customer usually checks three things: whether the application will take root in their infrastructure, whether an unsuccessful update can be rolled back, and whether they will be left alone with the code after delivery.
These are normal engineering questions, and each has a concrete answer in the form of an artifact, not a promise.
What if the application conflicts with an existing system? We check compatibility before development: we inventory the OS and bitness of work machines, system library versions, corporate proxies, and antivirus policies.
We deliver updates through the mechanism you already use — an internal update server, a corporate repository, or a signed installer. If some machines are offline, we provide a manual package delivery channel.
What if a new version breaks operations? We build the rollback plan at the design stage: every build is signed and retains the previous stable release, updates roll out in stages with the ability to pause the rollout.
Rollback means returning to the previous signed package without losing user data, because the storage schema is separated from the application code.
What about access? We describe permissions with a role matrix: who installs updates, who reads logs, who manages signing keys. We hand the keys over to you rather than keeping them ourselves — that is your area of control.
What exactly do we hand over after delivery?
A complete set: build configurations for your platforms, the update schema and policy, signing and key storage policies, the access matrix, architecture documentation, and support instructions. Plus an incident response policy and the version release procedure.
What the customer receives as a result:
- Build configurations for target platforms and bitness
- An update schema with staged rollout and rollback points
- A package signing policy and key handling procedure
- A role and access rights matrix for builds, logs, and keys
- Architecture documentation and operating instructions
- A support policy: response times, procedure for releasing fixes
- Source code and version history in your repository
Support after delivery does not stop: we establish a maintenance policy and a procedure for transferring knowledge to your team. Describe your task — we will come back with an estimate, a work plan, and a list of artifacts for your case.