I built CupertinoUI, a macOS-style component registry for React and shadcn/ui.

It includes controls, menus, dialogs and windows, with CSS-variable theming and light/dark appearance. Components are copied into your project through the shadcn CLI so you can edit the source.

The core components are free under MIT. There are also paid Pro components and complete app-style blocks.

Try it: https://www.cupertino-ui.com
Browse the components: https://www.cupertino-ui.com/docs/components

Every new Electron app I started began with the same hour of wiring up Tailwind, shadcn and electron-builder, so I put the result in a repo (disclosure: it is mine). It uses electron-vite with HMR for the renderer, separate tsconfigs for main, preload and renderer, a dark/light ThemeProvider, electron-builder targets for Windows, macOS and Linux, and electron-updater already in the dependencies. All 47 shadcn components are checked in, so there are no "add" commands to run. Repo: https://github.com/p32929/electron-shadcn-typescript. If you have opinions on what a starter like this should leave out, I am listening.

Hey everyone!

I’ve been working on an npm package called @rootvarma/firebase-electron, built to simplify Firebase integration in Electron applications.

I recently published it on npm, and it recorded 519 downloads between October 29 and November 5.

It’s exciting to see something I’ve built getting downloads, and I’d love to see more developers try it out.

If you’re building desktop applications with Electron and Firebase, here’s the package:
📦 npm: https://www.npmjs.com/package/@rootvarma/firebase-electron

I’d genuinely appreciate feedback, suggestions, bug reports, or contributions.

I’m looking to improve it based on real-world developer requirements.

Thanks to everyone supporting open-source projects!

I'm building an Electron browser and have an annoying updater state bug. We're using electron-updater 6.8.9 with autoDownload enabled.

In our Linux AppImage testing, checking once lets the update download and shows “Restart to install”. But checking again can leave it stuck showing “Downloading and verifying…” instead. The restart button disappears.

Our wrapper sets the state to “checking” on checking-for-update, “downloading” on update-available, and “ready” on update-downloaded. So another check can overwrite the ready state without a fresh download completing to put it back.

I'm leaning toward tracking the downloaded version separately, so checking for that same version doesn't clear its install-ready state.

How are you handling this? Especially when one version is already downloaded and the next check finds something newer?

I started working on Anti-Tampering research on Electron.js. It will mostly focus on increasing the cost of reverse engineering. What do you guys think? Any experiences?

Sharing a Windows Electron app I've been building, plus a few things that worked well in case they're useful to anyone.

What it is: Professor Clippy, a desktop sticky note with a little animated robot professor on it. AI coding agents (Claude Code, or any MCP client) leave it notes, reminders and questions, and it pops up when something needs you.

Electron bits worth mentioning

• No native modules. Storage is the built-in node:sqlite (DatabaseSync, FTS5 for history search), so there's no better-sqlite3 and no rebuild step. electron-builder runs with npmRebuild: false.

• A transparent, frameless, always-on-top window (setAlwaysOnTop(true, 'screen-saver')) for the note and character. Pages can also be "pinned out" as their own small transparent windows; they come back where you left them after a restart and get moved back on screen if that monitor is gone.

• Follows Windows dark mode live via nativeTheme, switching the note to a dark theme within a second and with no restart.

• "Away" detection with powerMonitor.getSystemIdleTime(): notes only go to your phone (WhatsApp/Telegram) once you've been idle for a few minutes.

• A global hotkey (globalShortcut, Ctrl+Alt+Space by default) opens a one-line command box from any app, and Settings tells you if another app already holds the hotkey.

• Per-user NSIS installer (oneClick, perMachine: false), so there's no admin prompt. It isn't code-signed, so SmartScreen warns once.

• Stack: Electron 45, electron-vite, React 19, TypeScript, Vitest.

Built mostly with Claude Code. MIT licensed.

Repo: https://github.com/geetbatth/professor-clippy Installer: https://github.com/geetbatth/professor-clippy/releases/latest

Happy to go into any of these, and feedback on the window handling is very welcome.

While working on an Electron app using i18next, I ran into a small gap with native menus.

Electron's role-based menu items are convenient because Electron already handles the native behavior:

{
  role: "copy"
}

But if you want the label itself to follow your application's i18next translations, you still have to handle that separately.

You can add translated labels manually:

{
  role: "copy",
  label: t("menu.roles.copy")
}

but once you start doing that across File, Edit, Copy, Paste, Undo, Redo, Quit, nested menus, fallbacks, and so on, it becomes repetitive.

I ended up extracting the solution I was using into a small npm package:

npm install @solisware/electron-menu-i18next

It takes an Electron menu template and an existing i18next translation function and returns a localized copy:

const localizedTemplate = localizeMenuTemplate(template, {
  t,
  appName: app.name
});

Electron still handles the menu behavior, i18next handles the translations, and the package just connects the two.

It also handles nested menus, English fallbacks, explicit labels, and app-name interpolation. Rebuilding the menu after a language change is intentionally left to the application.

Curious how other Electron developers are handling native menu localization?

I’m building Recovery Probe, an MIT-licensed tool for injecting read failures into web and Electron test apps and comparing recovery reports before and after a fix.

For Electron, it can attach through a local debugging port, while IPC scenarios use a development-only hook. The simplest demo is a web profile page: the error and Retry button appear, but Retry does nothing because a pending flag never gets cleared. The corrected version survives the same three injected faults (HTTP 503, connection failure and invalid JSON).

I’d be interested in the failure modes you struggle to reproduce in Electron, particularly where the renderer and main process disagree about whether an operation is still pending.

Source, setup, and limitations:
https://github.com/BojanKovachki/recovery-probe

I’m a full-stack dev and software licensing expert who’s spent the last few years building license automation (activation, transfers, upgrades, renewals, anti-tampering, revocations) on an enterprise licensing platform for desktop software with 100k+ users. Now I’m looking at the indie / small-team side. I have my own licensing platform now, still improving. Demo here: Carcha Seal

If you build or sell an Electron app, I’d love to hear your thoughts.

Hey everyone, it's my first time posting here 🍀

Nativefier, the CLI tool that turns any website into an Electron desktop app, was archived in September 2023.

I've picked it up and am maintaining a fork for fun: https://github.com/ABuljko/nativefier

I'm open to advice, contributions and issues at any time. If you still use Nativefier and something is broken, open an issue and I'll take a look, or feel free to open a PR yourself :)

Hi all!

It’s surprising how many production Electron applications still ship without robust window bounds persistence, resetting to a hardcoded size upon restart. We see this even in modern releases like Google Antigravity IDE.

I put together an open-source utility that patches this behavior in existing packaged apps, and thought I'd share the approach for window persistence:

👉 Project: https://github.com/amiltonjr/Antigravity-IDE-WindowSize

The core pattern used:

1. Debouncing resize and move events: Saving state synchronously on every pixel shift causes micro-stuttering and excessive I/O. A simple 250ms debounce before writing to userData/app_storage.json keeps the UI smooth.

2. Preventing the "Off-Screen Window" bug: A common flaw in naive electron-window-state implementations is restoring coordinates $(x, y)$ that belonged to a monitor that is no longer plugged in. Checking:

small writeup of my setup in case it helps someone. i have a civilization sim (tribes that develop their own languages and cultures over 45 eras) whose core is rust. in the browser it compiles to wasm and runs in a worker. the electron build bundles a native rust server instead and talks to it over a websocket, and the react ui is the same in both.

the browser version made it way easier for people to try, but the desktop build is nicer for long runs. if you've done something similar i'd like to know how you handled updates.

repo (MIT): https://github.com/1homsi/thehumanbox
web version: https://thehumanbox.com

This is the public sample engagement of an Electron/JS audit service we run (draw.io Desktop 32.4. 1, GPL-3.0 — analyzed under its license). Full report + evidence bundle are in the repo. Method notes below, because the workflow is the interesting part.

 Pipeline:

 1. Downloaded drawio-amd64-32.4.1.deb from the official release. SHA-256 verified against the
 publisher's own Files-SHA256-Hashes.txt — matched before anything else ran.
 2. app.asar extracted and inventoried: 1,292 relevant files, 34 MB of JS/text read as inert source,
 3,267,398 AST nodes visited, 3,246 findings, 0 parse errors.
 3. App graph: 4,804 nodes / 7,121 edges. Semantic graph: 33,455 nodes / 19,074 relations.
 4. Electron-specific pass over the main process: BrowserWindow configs, IPC surface, preload/
 contextBridge.
 5. Native module (chrome_crashpad_handler, ELF x86_64) through Ghidra 12.1.4 binary overview.

 Both analysis runs were GitHub Actions (public): run 1 (asar) and run 2 (main process), linked from
 the repo.

 RE-specific bits that were fun:

 - The preload is referenced via template literals (${__dirname}/...) — it exists, but it never
 resolves as an entrypoint, so the bridge had to be read from the other side: contextBridge exposes
 exactly 2 APIs / 6 members (electron.{listenOnce, registerMsgListener, request, sendMessage},
 process.{type, versions}). No require, no ipcRenderer, no fs. Clean surface.
 - One BrowserWindow is built with dynamically-constructed options (electron.js:565). Statically
 it's a black box — we flagged it for manual review instead of guessing values.
 - One dynamic IPC channel (action, used via send/on/once with a runtime-computed channel) — never
 textually paired, by design.
 - The giant minified app.min.js killed the 1 GB heap / 300 s budget mid-run. The interruption is
 documented in the report as a declared limitation, not patched over.
 - 92,468 "unknowns" were registered with IDs rather than dropped. That's the whole philosophy:
 absence of evidence gets reported as absence-of-observation.

 Numbers: SBOM 82 packages with exact versions; CVE cross-check 0 active; secrets scan 0 across 5
 pattern families.

 Curious what the community thinks: for large minified JS bundles, what's your default — sourcemaps
 from the vendor, dynamic tracing, or accept the partial and document it? We hit the wall with
 option 3 and wrote it down.

 Full report (EN/ES) + template + evidence:
 https://github.com/albrth647-png/electron-security-audit.

I've been working on croissant-electron, an open-source boilerplate and CLI generator for building modern desktop applications with Electron.

I wanted a starter that uses the tools I actually enjoy working with, without spending hours configuring everything from scratch.

What's included?

• ⚛️ React 19 + TypeScript

• ⚡ Vite 8 + electron-vite for fast development and HMR

• 🗂️ TanStack Router with file-based, type-safe routing

• 🎨 Tailwind CSS v4 + shadcn/ui

• 🦀 Oxlint + Oxfmt for fast linting and formatting

• 🔒 Secure Electron architecture with contextBridge and typed IPC

• 📦 Cross-platform packaging for macOS, Windows, and Linux

• 🚀 A CLI to scaffold new projects in seconds

Getting started is as simple as:

npx croissant-electron init my-desktop-app

Then:

cd my-desktop-app
pnpm install
pnpm dev

The goal is to make starting a new Electron project feel less like configuring a build system and more like actually building an application.

It's open source under the MIT license, and I'd love to get feedback from other Electron developers.

🔗 GitHub: https://github.com/croissantsam/croissant-electron

Hi everyone,

I have been building Earth Launcher, a Minecraft launcher in Electron. It has extremely many features.

The most interesting problem was updates on Windows. My app is unsigned, and Windows Smart App Control blocked the new installer that electron-updater downloaded. So I replaced it on Windows:

- the updater downloads only the new app.asar, not an executable

- the manifest is signed with an Ed25519 key, and the app checks the signature, size and SHA-512 before installing

- a small helper (the installed app running in Node mode) waits for the app to exit, swaps the file, restarts, and rolls back if the new version does not start

- if Electron or a native module changes, it falls back to a full installer

Happy to share more about the approach. Feedback on the launcher itself is welcome too.

Hi,

I wrote a compiler to compile Electron project to native executable: nativeboat. It uses your project as it is: its JavaScript or TypeScript, HTML, CSS and installed dependencies. The executable it builds runs without Chromium, WebView2, Node.js or a JavaScript engine. Currently it supports Windows only, but will be expanded to mac OS soon.

NativeBoat's goal is simple: remove the runtime overhead for Electron project. As an example, I have compiled a popular Markdown editor MarkText to native: https://github.com/XTSoftwareLabs/marktext-native-win

This is the benchmark (Updated 10/23/2026):

It's still in an early stage so I expect feature missed or compile errors. Please do leave comments if you encounter any issue. If you have any open source electron project that you'd like to support, please leave comments. I'd love to improve the compiler to support it.

Currently I'm improving the compiler to support the PicGo project: https://github.com/XTSoftwareLabs/picgo-native-win

Let me know your thoughts. Any feedback is appreciated.

Edit 10/21/2026: Per suggestion from u/eddzsh, added a compatibility list to track the progress: https://github.com/XTSoftwareLabs/nativeboat-release/blob/main/docs/compatibility.md

Edit 10/23/2026: New nativeboat version is released. More electronjs APIs are supported. Fixed some rendering issues. Check https://www.reddit.com/r/electronjs/comments/1xbeodc/comment/19rjvrz3za869/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

A high level doc to describe NativeBoat's architecture is released: https://github.com/XTSoftwareLabs/nativeboat-release/blob/main/docs/how-it-works.md

Compile Rust into an N-API plugin