On-device SDK

One core does the work. Each platform gets a native SDK around it, so the same call reads the same in every language. The shape is shared, not the code: every SDK hangs the same namespaces off a RunAnywhere entry point, names generation options the same way (model, maxOutputTokens, temperature), and emits the same streaming event kinds. Copying a call across platforms still takes language-specific changes — the porting page lists them. What each platform can actually run differs as well; the backend table below is the compatibility overview.

​

What you can call

​

Install

QHexRT, the Qualcomm Hexagon NPU backend, stops at 0.20.19 on Maven Central, pub.dev, and npm’s React Native package. Electron’s @runanywhere/electron-qhexrt is the exception and publishes at 0.20.31 with the rest of the Electron packages.

​

Backends

MLX runs only on physical Apple hardware, never a simulator. QHexRT is arm64 only. On Windows the Electron lanes are mutually exclusive: x64 gets llama.cpp, ONNX, and Sherpa; arm64 gets QHexRT alone. This table says which backends an SDK can be built against, not which ones a given install can reach: a package you did not add, an engine that failed to register, or hardware that declines it all narrow the set further. Ask the build itself with RunAnywhere.capabilities() and check its unavailable list before offering a feature.

​

Porting between platforms

Each language forces a few differences. Flutter has no method overloading, React Native has no push-shaped streams, and constrained decoding throws everywhere. The porting page has the full list.

​

Pick a platform