Rebuilding our Electron meeting-recording engine in Swift

Engineering How we rebuilt our Electron recording engine in Swift Arthur GuiotApril 16, 2026 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. Atomic: our Combine-to-Jotai bridge 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…