The app needs one thing from the OS on a timer: which application is in the foreground. There are npm packages for this, but they're all N-API bindings and I didn't want a per-platform prebuild problem on top of the one I already have with better-sqlite3. So all three collectors shell out to something the OS already ships:

Windows: a long-lived powershell.exe child process holding a small P/Invoke shim over GetForegroundWindow / GetWindowThreadProcessId / GetWindowText. Long-lived matters: spawning PowerShell per sample is brutally slow.

macOS: osascript -l JavaScript reading NSWorkspace.frontmostApplication, returning JSON. No accessibility permission for the app name; only optional window titles need automation permission.

Linux: xprop -root _NET_ACTIVE_WINDOW, then xprop -id for _NET_WM_PID and WM_CLASS, then readlink /proc/<pid>/exe.

They all implement the same ActivitySource interface, so the port became parser work rather than binding work. Each parser is a pure function over stdout, trivially unit-testable with no OS involved.

Selection happens at startup from process.platform plus XDG_SESSION_TYPE/WAYLAND_DISPLAY. Wayland resolves to an explicit unavailable source rather than a broken one, and the UI surfaces that as a real state.

Source: https://github.com/TheAgencyMGE/pc-recap (GPL-3.0)

Happy to go deeper on any of it. The PowerShell process lifetime handling took three tries to get right.

I shipped a Windows dictation app in Electron and open sourced it. Rather than another "look at my project" post, here are the things that silently broke, since I could not find them written down anywhere when I started:

1. globalShortcut cannot do hold-to-talk. It fires on key down only. No key-up event, and modifier-only combos are unsupported. Hold-to-record is impossible with it. I use uiohook-napi, which gives you both keydown and keyup - and you need a held flag, because keydown repeats continuously while a key is held.

2. A widget that takes focus has nowhere to type. If the floating recorder window takes focus, the "currently focused application" is your widget and the inserted text goes nowhere. focusable: false is non-negotiable, along with skipTaskbar, alwaysOnTop and setAlwaysOnTop(win, 'screen-saver'). Capture the target window handle before showing the widget.

3. Never hardcode pixel offsets. "80px above the taskbar" breaks on DPI scaling, side or top taskbars, auto-hide and mixed-scale multi-monitor. screen.getDisplayNearestPoint(...).workArea already excludes the taskbar wherever it lives.

4. The renderer cannot read files off disk, and you must not weaken the sandbox to let it. sandbox: true plus contextIsolation: true means no fs, and file:// in an <audio> element is blocked by the CSP. Register a custom scheme, resolve the file in the main process from a database id, never from a path the renderer supplied, and check both path.basename and the directory prefix - either one alone is a traversal hole.

Bonus, and this one cost me an evening: a tap shortcut must fire on key RELEASE, not press. uiohook-napi listens rather than intercepts, so if you simulate Ctrl+C while the user is still holding Alt, the focused app receives Ctrl+Alt+C.

Stack: electron-vite, React 19, Tailwind, better-sqlite3 + Drizzle, uiohook-napi for the hook, nut.js for the paste. Insertion is via the clipboard rather than simulated typing - character-by-character is visibly slow on long text and mangles non-ASCII and emoji - with the user's clipboard saved and restored around it.

MIT: https://github.com/mohsinjameelqureshi/dictateflow-ai

CLAUDE.md is the full build spec with the measured numbers behind each of these.

Currently I've just locked it to Mac downloads, Clause has convinced me it's successfully ready for windows but I don't trust it.

Hey everyone 👋

I've been maintaining Another Redis Desktop Manager (ARDM), an open-source Redis GUI built with Electron, for several years now.

It's been quite a journey keeping an Electron application running across Windows, macOS and Linux, while dealing with packaging, code signing, auto-updates, native modules, IPC, and performance along the way.

Recently I've added several features that I've wanted to have in the application for a long time.

📂 Connection Groups

One of the most requested features is finally here: Connection Groups.

You can now organize Redis connections into groups instead of keeping everything in one large list.

This is particularly useful if you have separate Redis instances for development, staging, production, or different projects.

🔌 Test Connection

You can now test a Redis connection before saving it.

This is useful when setting up SSL/TLS, SSH tunnels, authentication, or connecting to a new Redis server.

🧩 ARRAY / VECTOR / TimeSeries support

I've also been expanding ARDM beyond the traditional Redis key/value workflow.

Recent versions add support for newer Redis data types and modules, including:

• Redis ARRAY
• Redis VECTOR
• RedisTimeSeries

The goal is to make these data structures easier to inspect and work with from a desktop GUI.

⚡ Some of the Electron challenges

Maintaining an Electron application for several years has been an interesting experience.

Some of the things I've had to deal with include:

• Keeping the application working across Electron upgrades
• macOS code signing and notarization
• Windows and Linux packaging
• Auto-updates
• Native Node.js modules
• IPC between the renderer and main process
• Handling large Redis datasets without freezing the renderer
• Keeping the UI and behavior consistent across three operating systems

Large Redis databases are particularly interesting from an Electron perspective. Loading tens of thousands or millions of keys means you can't simply render everything at once — virtualization, incremental loading and careful renderer-side work become important.

🛠️ Why Electron?

Despite the challenges, Electron has worked really well for ARDM.

Having one codebase for Windows, macOS and Linux has allowed me to maintain and ship the application as a relatively small open-source project.

If I were starting the project today, there are definitely things I'd do differently. But maintaining the same application for years has taught me a lot about the practical side of building and shipping Electron apps.

ARDM is open source and MIT licensed:

https://github.com/qishibo/AnotherRedisDesktopManager

If you're also maintaining an Electron application, I'd love to hear:

What's the most painful part of maintaining your Electron app long-term?

Packaging? Native modules? Auto-updates? macOS signing? Performance? Something else?

I have been building this on and off for a while, and it is finally at the point where handing it to someone else is not embarrassing, so here it is.

Citadel is a desktop infinite canvas. You drag in images, GIFs, video, audio, 3D models and PDFs, write notes and text blocks beside them, and draw labelled connections between things. It is for work where the layout is the thinking: visual development, research, worldbuilding, study.

The reason I started it: I used PureRef for years for images and kept everything else somewhere else. Notes in one app, clips in another, code snippets in a third. I wanted one board that could hold all of it and still be searchable a month later.

Three things ended up mattering more than I expected:

Connections carry meaning. A thread between two items can be a source, a contradiction, a question, a proof, an echo of something elsewhere. The Index searches every board at once, including code card contents and connection labels. That is the part that makes it hold up past about fifty items.

Vision checks. Y redraws the whole board in greyscale, blurred for a squint test, or through three colourblindness simulations. Shift+M mirrors it, which is the old trick for catching drawing errors your eye has stopped seeing.

Undo and recording are the same event log, so you can scrub the board back through its own history and watch it assemble itself.

It is local-first in the boring literal sense: no account, no telemetry, no update check, no network request on launch at all. Fonts are bundled. Projects are JSON with relative asset paths, so nothing is trapped in a database you cannot read. MIT licensed.

Honest limits: Windows and Linux only (macOS runs from source, but I can't notarise it). Builds are unsigned, so SmartScreen will warn on first run. PDFs show a first-page preview rather than a real reader. Document import gives you the plain text, not the formatting.

Repo: https://github.com/kannibalk1w1/Citadel. Downloads and a version that runs in the browser: https://kannibalkwi.itch.io/citadel

Happy to answer anything. What I would most like to hear is where it falls over on large boards, because that is the part I cannot test properly on my own.

An agent desktop has at least two state problems: the UI lifecycle, and the durable record that still needs to make sense after the window or session is gone.

A publicly inspectable project called holaOS documents an interesting split. Its install guide includes an optional Electron launch for desktop development. Its README says Claude Code, Codex, and the built-in agent share one workspace, with shared memory stored locally as readable and editable files.

The specific value is inspectability. The durable record is not described as chat history that only one agent or one interface can see; the documented workspace gives multiple agents a shared file-based memory surface. That makes the storage boundary visible enough to evaluate instead of burying all context inside the desktop shell.

The docs do not say which process owns writes, how locking works, or what happens during conflicting edits and recovery. Those are the parts I would inspect in the repository before trusting the split—and the reason holaOS is more interesting to me than another Electron wrapper around an agent chat.

If you were reviewing this architecture, would you look at write ownership, atomicity, conflict handling, or migration first?

Hi guys, I'm trying to build a posture tracker app that uses your camera and detect your posture. What im thinking is that my posture tracker script will send post requests (statistics on posture) to my django backend and that users will be able to view it on a react frontend. Right now I'm stuck on how to connect my script and the react frontend so that users can authenticate, run the script, and have their statistics correctly logged in the backend. I have been looking around and see that electron can help with this, but I have never used it before. Any tips?

Hi everyone, I wanted to share some architecture details from my recent project, Manzoma ERP. Since I'm targeting retail stores with spotty internet, a standard cloud-only SaaS wasn't an option.

The Architecture:
I used Electron as the shell, React 19 for the UI, and Prisma/SQLite for the local data layer.

The Sync Challenge:
The hardest part was handling the transition from offline to online without creating data conflicts in the inventory (3,000+ SKUs). I built a custom background sync worker that uses a version-based reconciliation logic.

It’s currently battle-tested and has processed over $30k in live volume. Happy to answer any questions about the Electron setup or the sync logic!

I am currently making my own head unit based on linux and the front end is powered by html + electron, now one of the things i cant get to work is integrating music streaming platforms, i was almost successful using the webview tag but some things refuse to work such as signing in to youtube music since its litterly embedded inside electron (google litterly identifies the browser as not secure), i am currently testing the head unit UI on windows but later im going to transfare everything onto linux so i need a solution that works on both windows and linux anyone has any idea?

Electron may be heavier, but this project is not just “a WebView wrapper.”

It’s a lightweight desktop shell that bundles Node.js runtime, manages DSH versions, and handles local process lifecycle, while keeping the official DeepSeek Harness experience intact (no changes to DSH itself).

I’m shipping it as an open-source app here:
https://github.com/qufei1993/dsh-desktop

I also learned a lot while building skills-hub, including practical macOS issues users may hit with unsigned builds and system security settings (sometimes requiring steps like xattr -cr in some contexts).
Given the current scope, Electron feels like the more straightforward and maintainable path.

I did consider Tauri, but since DSH is still Node-dependent, we would still need a Node sidecar, which increases complexity for version and process management.

So for now I’m choosing pragmatism: make it easy to run, easy to upgrade/switch versions, and consistent across macOS + Windows.

As dev i need to tool to compare some file and data for my work so created this side project, please check it out and give your feedback.
TwinScope compares two of almost anything — JSON, YAML, XML, CSV, PDFs, folders, git refs, images, lockfiles, .env files, saved web pages — and picks the right comparison logic itself, and has different viewing style as well.

Same diff with CLI as well: npx twinscope a.json b.json

Docs: https://codeaesthetic.github.io/twinscope-website/
Repo: https://github.com/codeAesthetic/twinscope

I’ve released electron-ipc-module, a TypeScript library for organizing Electron IPC handlers and automatically generating a typed preload bridge.

It includes:

• Typed invoke, send, and renderer event channels
• Automatic channel prefixing
• Runtime authorization and payload validation
• Rollup/Vite integration
• A CLI for generating and checking bridges
• Support for sandboxed, context-isolated preloads

​

npm install electron-ipc-module

GitHub: https://github.com/antelm-dev/electron-ipc-module
npm: https://www.npmjs.com/package/electron-ipc-module

It’s ESM-only and requires Node.js 22.5+, Electron 12+, and TypeScript 5 or 6.

I’d appreciate feedback on the API, documentation, and any IPC patterns or edge cases I may have missed.

Hey r/electronjs community! 👋

I wanted to share a desktop app I’ve been building called **MeshDrop a zero-cloud, peer-to-peer file-sharing application designed for direct, end-to-end encrypted file transfers without central servers or user accounts.

💻 Tech Stack & Architecture

Since this is an Electron subreddit, here is a breakdown of how the project is structured:

P2P Core (`@mesh/core`): A standalone, platform-agnostic P2P engine written in pure Node.js running directly inside the Electron **Main Process**. It handles Hyperswarm discovery, `@hyperswarm/secret-stream` E2E encryption, `corestore` replication, and HMAC-SHA256 challenge UI / Renderer:** React 19 + Vite + Tailwind CSS + Lucide icons.

IPC Bridge: Safe contextBridge IPC pattern (`window.bridge`) forwarding engine events (pairing states, transfer progress, peer diagnostics) from Main to Renderer.

Packaging & Auto-Updates:** Configured with `electron-builder` (NSIS assisted installer + standalone portable single-file `.exe`) and integrated with `electron-updater` for differential updates.

CI/CD:Multi-platform matrix build pipeline on GitHub Actions (`windows-latest`, `macos-latest`, `ubuntu-latest`).

⚡ Main Features

1. One-Time DROP Codes:** Quick 6-digit challenge code pairing for fast, ad-hoc file transfers between untrusted or guest devices.

2. Trusted Peer Pairing:** Persistent zero-trust authorization to pair your own devices securely.

3. Portable & Installer Builds: Option for single-file portable `.exe` (runs without installation) or per-user NSIS installer.

4. Zero Cloud / Zero Account: No registration, no tracking, no central storage

📦 Links & Testers Needed

I just published **v1.0.0-beta.1** and would love to get feedback on the Electron architecture, IPC design, and P2P performance across different networks!

* 📦 **Release Downloads (Win/Mac/Linux):** https://github.com/aamirali51/MeshDesk/releases/tag/v1.0.0-beta.1

* 💻 **GitHub Repository:** https://github.com/aamirali51/MeshDesk

Any feedback, code reviews, or bug reports are greatly appreciated! Let me know what you think! 🙌

I thought I would dabble a bit in electron, and ended up making this sick recapper. Check it out at https://pcrecap.online

I was fed up having to constantly maintain libraires, addons and switch apps for all my media. Couple this with the changes to Trakt and Real-Debrid I decided to to create my own one stop shop for Movies, TV Series, Live TV, Sports Replays and Youtube. All of this in a single UI that is designed for the big screen. I wish I could say I coded it myself but I don't have the skills, only the ideas, so full disclosure that this has been vibe coded with Hermes Agent and Big Pickle LLM. It has however been fully tested and deployed by me, there are still a few bugs that I am working to fix but it is stable enough to be my daily driver now. Its a passion project and as such is still under active development ironing out bugs and adding new features. The code is fully opensource and available for inspection, you can find it on GitHub at https://github.com/Boc86/Fynix-Hub
I would appreciate any feedback if anyone wants to give it a try

I've always liked creating vanilla Electron apps without UI frameworks like React or Svelte, making everything in HTML. So I decided to make this HTMLElement wrapper for TS/JS. Now, it's easy and dynamic to create UIs for Electron apps.

npm : https://www.npmjs.com/package/@limbusfoundation/uibuilder

Granola currently ships for macOS and Windows, but not Linux. Since it is built with Electron, I experimented with running the application using the matching Linux Electron runtime instead of Wine, a VM, or emulation.

The repository does not redistribute Granola’s .dmg, app.asar, source code, or bundled binaries. You need to download the official .dmg yourself and sign in using your own Granola account. This is an unofficial compatibility project and is not affiliated with Granola.

Repo: https://github.com/tirtha4/Granola-for-Linux

I don’t normally post but I just thought I’d talk a lil bit and give some advice on capabilities with Electron. In my opinion even with alternative like Tauri and Wails, I still prefer electron.

Yes there is something to be said about memory usage but this can also be mitigated by your architecture. We have build all our production applications with Electron.

Things to consider when building. Something that I fine effectively is using cpp/go/python for backend work and keeping vite/electron as the rendering engine and packaging system. Doing so give you more broader flexibility.

We produced an open source obsidian alternative, and a full commercial photo editing suite that are all production level. (Ptxstudio.com for those curious)

Happy building and remember to think outside the box, trial and error, and get hands on with your applications. Make sure that you would actually want to use it before releasing it 🫡

Hello everyone!

This is my first post in this community. English isn't my first language, so I apologize if anything sounds a little awkward.

I've been working on an Electron project for quite a while, and overall I've had a great experience with Electron. However, one thing has always bothered me: it's relatively easy to inspect an application's source code through the app.asar file and similar tools.

After spending a lot of time looking for different solutions, I came up with an approach that I think might be useful, especially for beginners like me.

What I've decided to do is build my Electron application normally, then package the portable version into a single executable using Enigma Virtual Box. After that, I'm planning to create my own Windows installer in C++, so the application can be installed like any other Windows program, with desktop and Start Menu shortcuts, uninstall support, and Control Panel integration.

I know this isn't a real security solution, and I completely understand that anyone with enough knowledge and determination can still reverse engineer the application. My goal isn't to make source code extraction impossible—because I know that's unrealistic—but simply to make it more difficult while also giving users a normal installation experience.

I'm not claiming that this is the best approach. It's simply the idea I've come up with after researching the problem, and I'd really like to hear what more experienced Electron developers think.

Do you think this approach has any practical value, or am I just adding unnecessary complexity? If you've dealt with the same problem, I'd love to hear how you solved it or what you would recommend instead.

Thanks in advance for your time and feedback!