// HACKER NEWS — CYBERSECURITY
Rebuilding our Electron meeting-recording engine in Swift
Our desktop app captures meetings without a bot and streams them to the cloud. For months, the recording engine was the hardest part of the product to make reliable. We'd fix one class of edge case, ship it, and a new one would surface the next week. Different root causes, same pattern.
The engine ran in the render process of our Electron app. We tried the obvious fixes: tighter lifecycle management, moving work off the main thread, isolating it from React's render cycle. Each change helped at the margin, but none addressed the real issue. A render process is the wrong place to do realtime audio and video capture. A capture engine can't tolerate GC pauses, throttling, or any of the other things a browser runtime does to stay responsive.
So we went native: ScreenCaptureKit on macOS, libobs on Windows, and a shared Swift layer tying it together.
Bridging a native runtime to React usually means writing native addon bindings by hand. You serialize every value that crosses the boundary, route events through stringly-typed names, and update three files whenever you add a property: the Swift class, the C++ binding, and the TypeScript wrapper. It works, but it's out of sync the moment anyone forgets a step.
What if every @Published property in Swift automatically became a Jotai atom in React? Fully reactive, type-safe, no glue code. That's what our internal tool Atomic does.
From React's perspective, these atoms are indistinguishable from any other Jotai atom. The fact that the data lives in a Swift runtime on a different thread is invisible.
The @NodeExport macro generates the entire bridge at compile time. Types map automatically (Int → number, String? → string | null). Value changes in Swift schedule callbacks on Node's event loop. Every new property we add on the Swift side is instantly available in React. And because Atomic is built on Swift, not Apple frameworks (we use OpenCombine on Windows), the same bridge runs on both platforms.
On macOS, ScreenCaptureKit gives us hardware-accelerated capture and the native content picker. On Windows, we use libobs through a Swift wrapper we call OBSKit. The two engines have fundamentally different architectures.
On macOS, we receive raw sample buffers from three independent sources and assemble the file ourselves. On Windows, capture, mixing, encoding, and muxing run as a single graph. We configure it and a file monitor streams newly written bytes to our upload session.
Windows capture has its own challenges. We use Windows Graphics Capture (WGC) as the primary method, and if it doesn't deliver frames in time, we fall back to BitBlt. We also detect all-black frames (common with some emulated windows or games) and switch methods mid-recording.