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: Screen Capture Kit 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. What if every @Published property in Swift automatically became a Jotai atom in React? That's what our internal tool Atomic does.

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 use Windows Graphics Capture (WGC) as the primary method, and if it doesn't deliver frames in time, we fall back to Bit Blt. We also detect all-black frames and switch methods mid-recording.

A crash at minute 30 loses at most the last second. Segments go to both local storage and the cloud simultaneously. If the network drops, segments persist locally and the upload resumes automatically when connectivity returns. Desktop recording used to be one of our most common sources of support tickets. Now it's a boring part of the app that just works.