A desktop app
that stays up to date
We build Electron® desktop apps for Windows, macOS and Linux, set up as the security checklist recommends and moved forward one major version at a time, so each release reaches your users signed and tested.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When the app carries its own browser
An Electron app ships with its own copy of the Chromium™ browser engine, which draws each window, and of the Node.js® runtime that runs its code. Their fixes reach your users only when your app updates.
The Electron team supports the latest three major versions, and a new one comes out every eight weeks. So an app that isn’t moved forward leaves support within a few releases, though it keeps running.
And unlike a page in a browser, the app’s code can reach the computer’s files and more, so what each window is allowed to do is part of the design.
So the work that matters is keeping the app moving forward and keeping each window to what it needs. How much that takes depends on the app and how it was built.
What we build
Every change is tested on Windows, macOS and Linux, and a person reviews it before it reaches your users.
Your web app, on the desktop
A web app you already run, brought to the desktop: its pages kept to what the security checklist allows, and anything that needs the computer added through the app.
Signed installers and updates
Installers built in CI, signed for Windows and macOS and notarized for macOS, with updates that reach people the way each platform supports.
Faster starts, less memory
Startup and memory measured first, then each change measured against how the app was before it.
APIs and integrations
The services and APIs behind the app, and the computer’s files and devices reached through the app, with data checked where it comes in.
Checks on every change
Tests on Windows, macOS and Linux in CI, with the installers built there too, so a change merges once they pass.
AI where it helps
Changes drafted with AI coding assistants go through the same tests and the same review as every other change before they merge.
- Other ways we build for the desktop:Flutter Development
- Desktop apps for Windows alone:.NET Development
- The back ends behind an app:Node.js Development
- A review of an app’s security:Application Security
- For the update server and CI:Cloud, DevOps & Security
- Developers in your own team:Developers for Electron desktop apps
The window asks, the app decides
A desktop app’s code can reach the computer’s files and more, which a page in a browser can’t. So in current Electron releases, each window’s page runs in a sandbox by default, kept apart from the app’s own code and without the Node.js runtime.
The page gets a few named functions from the app, never the app’s whole messaging system, and the app checks which window sent each request before it acts.
Links open in the person’s own browser, and only for addresses the app expects. The app limits where its windows can go, and which new windows can open.
Its own pages come from an address scheme of its own rather than straight from the disk, and switches set when it’s packaged turn off what it doesn’t use.
So we set this up window by window, and check it against the Electron team’s security checklist on every release. Below is a quote window from an app of our own: choose a command from its menus, and beside it is what the window asks for and what the app checks.
Choose File or Help in the window, then a command. With a keyboard, Tab to the menu bar, move with the arrow keys, choose with Enter, and close a menu with Escape.
- File
- Help
Open…
The window asks: to open a quote saved on the computer.
The app checks: that the request came from its own window, then shows the system’s own file dialog itself.
Then: The page receives only the file the person picked, never a way to look around the disk.
Save
The window asks: to save this quote.
The app checks: that the request came from its own window, through the one function it offers for saving.
Then: It asks where to save in the system’s own dialog, and writes the file there. The page never reaches the disk itself.
Show in folder
The window asks: to show the saved quote in its folder.
The app checks: that the request came from its own window, and that the file is one it saved.
Then: It asks the operating system to show the file in a file manager, which the sandboxed page can’t do on its own.
Open the online guide
The window asks: to open the online guide.
The app checks: that the address is the guide’s, one the app expects, before anything opens.
Then: The guide opens in the person’s own browser, never inside the app’s window.
Check for updates…
The window asks: to check for a newer version.
The app checks: that the request came from its own window, then asks the app’s own update server.
Then: On Windows and macOS it downloads the update, which is applied the next time the app starts, and on macOS its signature is checked first. On Linux, updates come through the system’s package manager.
{{ bdSay }}
One major version at a time
A new major version comes out every eight weeks, in step with the Chromium project, and the Electron team supports the latest three.
Each one brings a newer version of the Chromium browser engine into the app, and the Electron team lists its breaking changes, the changes that can stop older code working. Fixes from the Node.js runtime arrive in releases along the way.
The Electron team’s own advice is to move an app one major version at a time, reading the breaking changes for each.
So we move one major version at a time, on a branch, with the app’s tests passing on Windows, macOS and Linux before the next, and the update delivered the way each platform supports.
Start with the release and the windows
The review covers the Electron release in use, and how it’s pinned in development, in CI and in builds; how each window is set up: kept apart from the app’s own code, sandboxed, and kept from the Node.js runtime; what each window’s page is offered, and how the app checks each request; where windows may go, which new windows open, which links open in the browser, and which permissions are granted; the Content Security Policy, and where the app’s own pages are served from; the switches set when the app is packaged, and whether its packaged files are checked when it starts; modules written in native code, and how they’re rebuilt for each release; the dependencies that are behind, and the ones no longer maintained; packaging, signing and notarization on each platform; how updates reach people on each platform; crash reports and logs; startup and memory, measured as a baseline for the review; the tests on each operating system, in CI; and where the update server and CI run.
The first step is one of these, each tried on a branch: the app moved forward one major version, with its breaking changes worked through; one window’s page offered only named functions, with each request checked; the packaging switches set, and the app’s files checked when it starts; signed builds and updates in CI for one platform; or the security checklist run against the app, and written up.
What you receive is a written review and a proposal for that first step.
Questions worth asking
Should our app be a desktop app at all?
Where people keep it open all day, or it needs the computer’s files, devices, notifications or menus, often yes. Where it doesn’t, a web app may do the job better, and it’s simpler to run.
The Electron framework, or another way to build for the desktop?
It depends on the app and the team. Where the app already runs on the web, or the team works in web technology, the Electron framework is often a good fit. Where it isn’t, we build for the desktop in other ways too, and suggest the one that fits.
How often do we need to update?
A new major version comes out every eight weeks, and the Electron team supports the latest three. So we plan upgrades to stay within them, one major version at a time, alongside the work you already have planned.
Can our web app become a desktop app?
Often much of it carries over. Its pages keep to what the security checklist allows, and anything that needs the computer goes through the app, one named function at a time.
How do you keep the app secure?
With the security checklist in every window, a supported release, and signed updates, each checked again on every release.
Can it update itself?
On Windows and macOS, yes: the app checks for an update, downloads it, and it’s applied the next time the app starts. On macOS the app must be signed for that. On Linux there’s no built-in updater, so updates come through the system’s package manager.
Will it work offline?
If it’s built for it. What works without a connection, and what waits until one is back, is decided feature by feature.
Can you take over our existing Electron app?
Yes. First we read it: its release, how each window is set up, how it’s built, signed and updated, and its tests. Then we agree on a first piece of work, one person on our side owns it, and we work alongside any developers you already have.
What does it cost?
That depends on the app and on the first step you pick. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can AI assistants help with our desktop app’s code?
Yes. Whatever an assistant drafts is tested on each operating system, and a person reviews it before it merges.
Can we hire developers for our own team?
Yes. Within 48 hours of your request we introduce developers who work on Electron desktop apps, each working in your time zone, and you meet them before you decide who joins.
Which versions get security fixes?
The latest three major versions, each in its latest minor release, as the Electron team’s support policy sets out. The newest gets every fix, and the oldest of the three gets security fixes only.
Electron and Node.js are registered trademarks of the OpenJS Foundation. Webair isn’t affiliated with or endorsed by the OpenJS Foundation. Chromium is a trademark of Google LLC. macOS is a trademark of Apple Inc., registered in the U.S. and other countries and regions.
Let’s build it better
Tell us about the app, who uses it and where it runs, and we’ll suggest a first step in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}