Skip to main content
The C++ SDK is a C++17 client built on the same Rust core the Python and JavaScript SDKs bind. It ships as one prebuilt archive per platform rather than through a package manager: the package is useless without its native library, and building that needs a Rust toolchain and a libwebrtc download — which is exactly what a consumer of a C++ SDK should not have to own.

​
Platforms

Every row is checked when the archive is built, not promised: the release refuses one that asks for a newer glibc, or that was built for a later macOS, than its row says. Anything outside the table — musl distributions, glibc older than 2.34, 32-bit, Windows on ARM — has no archive and has to build from source.

​
Install

Download the archive for your platform from the releases page, extract it, and point CMake at it:
One target carries everything: the include directories, the C++17 requirement, nlohmann_json, and the native library. Nothing has to be set to run from your build tree.
A model name is owner/name. A bare name resolves under reactor/, so "helios" works by luck of ownership and answers 403 for anyone else’s model — write the owner out.

​
What is in the archive

On Windows the two halves are separate files: lib/reactor_ffi.dll.lib is what the linker reads and bin/reactor_ffi.dll is what the loader reads. The native library exports 29 symbols, all of them reactor_*. libwebrtc, BoringSSL, abseil and everything else it carries stay inside it, so nothing collides with what your application already links.

​
Shipping your application

libreactor_sdk.a is static and disappears into your binary. libreactor_ffi is shared, so it stays a separate file and has to travel with what you ship. The rpath CMake gives your binary in the build tree is an absolute path on the machine that built it. For an installed application, say it relatively and put the library where it points:
$<TARGET_FILE:reactor::ffi> is the .so, the .dylib or the .dll — the file that runs, on every platform. Windows needs no rpath; the DLL beside the executable is how the loader finds it.

​
Runtime dependencies

libreactor_ffi loads libc, libm, libgcc_s and the dynamic loader on Linux, and that is the whole list — TLS is rustls, so there is no OpenSSL, and libwebrtc is linked statically inside it. The one exception is audio devices, which are an opt-in target.

​
Building from source

Only needed for a platform with no archive, or to work against a local change to the core.
Building the native library is a separate step, not a dependency of the SDK build. On Linux it compiles libwebrtc’s C++ glue with a pinned clang whose sysroot cannot resolve what the resulting .so needs from the system glibc, so the SDK itself is built with the platform compiler. Two compilers, two commands. To build against a library somewhere else — a release archive’s lib/, or another checkout:
Rebuild the native library after pulling changes to the core. A signature that moved in the FFI but not in your build still links, and then corrupts the stack at the call — which looks like a hang, not a version error. The SDK checks reactor_abi_version() at startup and turns that into a message naming both versions, but only if the library on disk is the one you think it is.

​
Next

Reactor

Connecting, commands, uploads, recordings, events.

Track

Pushing frames, receiving them, pausing, bitrate.

Types

Status, ReactorError and its codes, Clip, Subscription.

Audio devices

Speaker and Microphone, in a target nothing links by accident.