What is Electron app development, in simple terms?
Electron app development means building a desktop application with web technologies, where Electron bundles the Chromium browser engine and Node.js so one JavaScript codebase runs as a native-looking app on Windows, macOS and Linux. Your interface is a web page; Electron gives it a window, a menu, a tray icon and access to the computer.
Each Electron app has two sides. The main process runs Node.js, owns the windows and talks to the operating system: files, printers, notifications, menus and updates. The renderer is the web page users see, running your React, Angular, Vue or plain JavaScript interface. A small preload script sits between them and exposes only the specific functions the interface is allowed to call.
Many desktop tools people use daily are built this way, which shows the approach works at scale. The trade-off is also well known: every Electron app carries its own copy of Chromium, so downloads are larger and memory use is higher than a native app. For business software, that cost is usually outweighed by writing one app instead of three, and by reusing your web code.
When should a business choose Electron app development?
Choose Electron when you already have a web app or web team, need the same product on Windows and Mac, and want desktop-only features such as offline work, local files, printers or a tray icon. Skip it when a browser does the job, or when install size and memory must be as small as possible.
The strongest case is a web product that customers keep asking to use offline or to connect to local hardware. A billing screen that must keep working when the internet drops, a design tool that edits large local files, a field app used on laptops in places with weak signal, or a trading dashboard that must stay open all day in its own window all fit Electron well.
The weaker cases are apps that are really websites, apps that must run on very old or low-memory PCs, and Windows-only tools that need deep Windows integration, where .NET is often better. If a small footprint is the priority, Tauri, which uses the system’s own web view, is worth comparing. We walk through that choice on our desktop software page, so this guide stays focused on doing Electron well.
- Good fit: existing web app, Windows and Mac users, offline or device needs.
- Good fit: internal tools where one codebase matters more than install size.
- Poor fit: always-online tools with no desktop features, which a web app covers.
- Poor fit: very old office PCs with little memory, or games needing top performance.
How do you convert an existing web app into an Electron desktop app?
Convert a web app to Electron by loading your built front end into an Electron window, moving anything that needs system access into the main process behind a preload bridge, replacing browser-only assumptions (URLs, cookies, local storage limits), and adding desktop features, packaging, signing and updates.
The first version often runs within days: point an Electron window at your production build and it works. The real work is everything that makes it feel like a desktop product rather than a website in a frame. Routing needs to work without a web server. Logins that rely on browser cookies and redirects may need a different flow. Links should open in the user’s browser, not inside the app. Keyboard shortcuts, native menus, window size memory and a proper “quit” behaviour on Mac all need adding.
We also decide early whether the desktop app loads your interface from local files (bundled, works offline, updated with the app) or from your server (always current, needs internet). For most business apps we bundle the interface and fetch only data from the server, which keeps start-up fast and offline mode possible.
- Bundle the front end into the app rather than loading a live website.
- Put file, printer and device access in the main process, exposed via preload.
- Rework login flows that depend on browser redirects.
- Open external links in the default browser.
- Add menus, shortcuts, tray icon, notifications and window-state memory.
- Package, sign, notarise and wire up auto-updates.
Electron security: the settings that must be right from day one
Electron apps have far more power than web pages, so the renderer must be locked down: context isolation on, process sandboxing on, Node.js integration off for any web content, a strict Content Security Policy, and only a narrow set of functions exposed through the preload script. Electron’s own security checklist lists these among its first recommendations.
The risk is simple to explain. If a web page inside your app can call Node.js directly, then any script injected into that page, through a compromised library or unsafe HTML, can read files or run programs on the user’s computer. The official checklist says the goal is to limit the powers granted to remote content, making it much harder for an attacker to harm users. Context isolation keeps the page’s JavaScript separate from the preload script, and sandboxing uses the operating system to restrict what renderer processes can touch.
Beyond those basics, the checklist warns against disabling webSecurity, enabling allowRunningInsecureContent or switching on experimental Chromium features. We follow it item by item, validate every message passed from the renderer to the main process, and never expose a generic “run this command” function to the interface. Older Electron apps we inherit often have Node integration switched on everywhere, and fixing that is usually the first job in an upgrade.
Offline data in Electron apps: using SQLite and syncing safely
For offline data, an Electron app keeps a local SQLite database, accessed from the main process, and syncs changes with your server when a connection is available. SQLite is a single file, needs no server, handles far more data than browser storage and survives app updates.
Browser storage inside Electron works for small settings, but it is the wrong home for invoices, orders or records that staff create all day. A SQLite file in the user’s application data folder is faster, can be backed up by copying one file, and can be queried properly for reports. We access it only from the main process, so the interface asks for data through the preload bridge rather than opening the database itself.
Sync is where offline apps succeed or fail. Each record gets a unique ID created on the device, a modified timestamp and a sync status. Changes queue locally, upload when online, and the server returns anything changed elsewhere. The hard part is conflicts: two people editing the same record offline. We agree rules with you in advance, such as last edit wins for notes, server wins for prices, and never auto-merge stock counts without a log. Those rules are business decisions, not technical ones, so they are written down before any code.
Schema changes need care too. When an update adds a column, the app migrates the local database on first launch, keeping existing data. We test upgrades from older versions with real sample data before each release.
How do auto-updates work in an Electron app?
Electron apps check an update feed on launch or on a timer, download the new version in the background and install it on the next restart. The feed can be Electron’s free update service for open-source apps, a storage bucket you control, or a small update server; Electron’s built-in autoUpdater module handles the install step on Windows and macOS.
Electron’s documentation describes update.electronjs.org as a free service run by the Electron team, but it requires the app to run on macOS or Windows, have a public GitHub repository, publish builds to GitHub Releases and code-sign macOS builds. That rules it out for most private business apps. The same docs describe update-electron-app as a drop-in module that sets up autoUpdater and prompts users with a native dialog, and it also works with static storage.
For private apps we usually publish signed builds and a small metadata file to a storage bucket or a private release channel you own. That keeps hosting cheap and under your control. We add staged rollouts, so a new version reaches a small group first, and a way to stop a bad release before everyone gets it.
Auto-updates depend on signing. On macOS in particular, an unsigned app cannot update itself properly, and on Windows unsigned updates trigger warnings. So signing is not an optional extra; it is part of getting updates working at all.
Code signing and notarisation for Windows and Mac Electron apps
Signing proves the app came from you and has not been altered; without it, Windows shows SmartScreen warnings and macOS may refuse to open the app. On Mac you sign with an Apple Developer ID certificate and then send the build to Apple for notarisation; on Windows you sign with a code-signing certificate or a cloud signing service.
Electron’s code-signing guide states that preparing a macOS app for release takes two steps: code signing, then uploading the app to Apple for notarisation. It requires membership of the Apple Developer Program, which has an annual fee of US$99. We automate both steps in the build pipeline, so notarisation happens on every release without anyone remembering to do it.
Windows has changed in recent years. Electron’s guide notes that signing keys now have to be stored on certified hardware modules, and many certificate providers offer cloud-based signing instead. It points to Azure Artifact Signing as the cheapest option for Windows code signing and says it removes SmartScreen warnings. We help you choose and set up whichever route fits, with the certificate or signing account always in your organisation’s name.
Linux is simpler: packages such as AppImage or .deb are usually distributed without the same signing requirements, though some repositories and stores have their own rules. We build Linux packages in CI alongside the others.
Does Electron use too much memory, and how do you reduce it?
Electron apps use more memory than native apps because each one runs its own Chromium engine, and badly built ones use far more than they need to. With careful engineering, a typical business Electron app stays comfortable on normal office PCs; the problems usually come from the app’s code, not Electron itself.
Electron’s performance guide lists the usual causes plainly: carelessly including modules, loading and running code too soon, blocking the main process, blocking the renderer, unnecessary polyfills, unnecessary or blocking network requests, and not bundling code. Every one of those is something a developer controls.
Our routine for a heavy Electron app: measure first, then fix the biggest item. We check dependencies for large libraries used for one small function, lazy-load screens and modules until they are needed, move heavy work such as file parsing or report generation off the main process, keep one window instead of several hidden ones, and bundle the code so start-up does not wait on hundreds of file reads. Memory leaks, often from listeners never removed or caches that only grow, get tracked down with Chromium’s own developer tools.
Honesty matters here. If your users run very old PCs with little memory, or the app must sit open alongside many others all day, a lighter framework may suit better. We check your users’ typical hardware before recommending Electron.
How much does Electron app development cost in India?
With our freelance team, Electron app development starts at ₹60,000 (US$900), typically over 6–12 weeks. Quotes from other developers in India vary widely, mainly because “build an Electron app” can mean a thin wrapper around a website or a full offline product with hardware integration.
A conversion of a clean existing web app, with menus, notifications, signing and auto-updates, sits at the lower end. Offline SQLite with sync, printers or scanners, licensing, multiple windows and support for all three operating systems move it up. Rebuilding every screen from scratch, because no reusable web app exists, is the largest single factor.
Remember the running costs outside our fee: the Apple Developer Program at US$99 a year if you ship on Mac, a Windows signing certificate or cloud signing service, and storage for update files. They are modest but recurring, and we list them in the quote.
- Electron conversion or new desktop app: from ₹60,000 · US$900
- AI features such as document reading added to the app: from ₹40,000 · US$600
- Monthly care after 2 free months: from ₹8,000/mo · US$120/mo
How long does it take to build an Electron app?
Converting a solid web app to a signed, auto-updating Electron app often takes 6–8 weeks; a new app with offline sync and hardware integration usually takes 9–12. Setting up certificates and developer accounts can take days of paperwork, so we start it in week one.
A typical plan: week one covers discovery, the list of desktop features, a hardware check and certificate applications. Weeks two to four get the app running in Electron with the security settings correct, routing and login reworked, and a first installer on your machines. Weeks five to eight add offline data, printers or devices, menus and notifications. The last stretch covers signing, notarisation, auto-update testing across versions, and installers for every platform.
We send test builds every week, so staff can try the app on their own PCs early. That surfaces the real-world issues, such as antivirus software, locked-down office machines or unusual printers, while there is still time to handle them calmly.
Distributing your Electron app: installers, stores and a download page that ranks
Most business Electron apps are distributed as signed installers from your own website, with auto-updates handling every later version. Store distribution through the Microsoft Store or Mac App Store is possible, but it adds review steps and sandbox rules, so it only makes sense when customers expect to find you there.
For Windows we typically produce an installer that installs per user without admin rights where possible, which avoids calls to IT departments. For Mac, a signed and notarised disk image. For Linux, an AppImage for easy running and a .deb package for Debian and Ubuntu users. Build tools such as Electron Forge or electron-builder produce all of these from one configuration.
The download page deserves as much care as the app. It should detect the visitor’s operating system and offer the right file, list system requirements, show version notes, and load fast. Clear headings answering questions like “does it work offline?” or “which Windows versions are supported?” help both Google and AI search engines describe the app accurately. If you need that page built or improved, our SEO website developer page covers it.
Keeping an Electron app updated and supported
Plan to move to a new Electron major version a few times a year. Electron’s release timeline documentation says new major versions arrive every 8 weeks and that only the latest three stable majors are supported, so an app left alone falls out of security support within months.
Each Electron release brings a newer Chromium and Node.js, which means browser security fixes reach your users only if you upgrade. Skipping versions makes each eventual upgrade larger and riskier, because deprecated APIs pile up. We recommend a small upgrade every release or two, tested against your app’s main flows and your update path from older versions.
This fits naturally into monthly care. After the 2 free months of fixes, maintenance from ₹8,000/mo covers Electron upgrades, dependency updates, certificate renewals before they expire, and compatibility checks when Windows or macOS release major updates. A lapsed signing certificate is one of the most common reasons an Electron app suddenly starts showing warnings, so we track expiry dates for you.
Printers, files, tray icons and devices: native features in Electron
Electron can do almost anything a desktop app needs: read and write local files, print silently to a chosen printer, show system notifications, sit in the system tray, register deep links, start at login and talk to USB or serial devices through Node.js libraries. All of it runs in the main process and is offered to the interface through the preload bridge.
Printing is the most common request from Indian businesses. Receipt printers at billing counters, label printers in warehouses and A4 invoices at dispatch all behave differently. Electron can print a page silently to a named printer, which is what counters want, but thermal printers often need raw commands through a Node.js library instead. We test with your actual printer models early, because this is where surprises hide.
File handling is the other big area: opening files by double-click, watching a folder for new scans, saving exports to a chosen place, or processing large files locally instead of uploading them. For businesses with Tally or other accounting software, a desktop app can also exchange files or call local APIs; see our Tally API integration page for that side.
- Silent printing to receipt, label and A4 printers.
- File associations, folder watching and drag-and-drop.
- Tray icon, notifications, start at login, global shortcuts.
- USB, serial and barcode devices through Node.js libraries.
Ownership: source code, certificates and update servers
You own the source code, the Apple developer account, the Windows signing certificate or signing service, the update storage and any back-end server. We set each one up in your name and are added as users you can remove whenever you like.
Certificates are the item most often lost in desktop projects. If a developer buys a signing certificate under their own name and leaves, the next release is signed by a different publisher, and users may see new warnings or the update chain may break. Keeping signing in your organisation from day one avoids that entirely.
At handover you get the repository with a README explaining how to build for each platform, how signing and notarisation are configured, how to publish an update and how to pull a bad one, plus a recorded walkthrough of a full release. Payments are per approved milestone: UPI or bank transfer in India, or Wise, bank wire or PayPal in USD from abroad. Confidentiality and similar terms are agreed in your written quote, and our terms cover general conditions.
Worked example: a hypothetical Surat textile wholesaler taking its web order system offline
Suppose a Surat textile wholesaler uses a React web app for orders, stock and dispatch. The shop counter loses internet several times a week, billing stops, and staff fall back to paper that is later typed in with mistakes. They also want invoices printed straight to the counter printer. This is a hypothetical scenario, not a client story.
An Electron app is a strong fit: the React screens can be reused, and the missing pieces are offline data and printing. In week one we would list the screens needed offline (billing, stock lookup, customer list), check the printer models and start the Windows signing setup.
Weeks two to five: the React app running inside Electron with secure settings, a local SQLite database holding customers, products and today’s orders, and a sync queue that uploads bills when the connection returns. Weeks six and seven: silent invoice printing, conflict rules agreed with the owner (server wins on prices, counter wins on new bills), and weekly test builds on the counter PCs. Week eight: signed installer, auto-updates from a storage bucket the wholesaler owns, and a handover session.
The counter keeps billing through outages, invoices print in one click, and head office sees every bill once the link returns. A scope like this starts at ₹60,000; the final quote depends on the screens and printers involved.
Electron app development for businesses across India
We build Electron apps remotely for businesses anywhere in India, working in English or Hindi and replying on WhatsApp seven days a week. There is no office visit; weekly test builds install on your own PCs so you see real progress.
Typical requests come from traders and wholesalers in Surat and Salem who need offline billing, SaaS teams in Bengaluru, Hyderabad and Noida whose customers want a desktop version, manufacturers around Jamshedpur, Aurangabad and Belagavi running shop-floor tools, and design and media businesses in Thane and Kolkata working with large local files. These describe common needs by city, not named clients.
Planning release automation for the desktop app? Our CI/CD pipeline setup page explains how signed builds for all three platforms can be produced on every release.