Which Offline Protocol SDK should I use?

The right Offline Protocol package follows from where your code runs. Every package wraps the same Rust engine, which queues, routes, encrypts with MLS and picks a transport. The difference is whether the package also ships the code that opens the radio or socket, which the SDK calls a platform bridge.

• A phone app for iOS and Android. Use React Native. It is the stable, most complete integration and wires Bluetooth LE, Wi-Fi Direct and peer streams, the relay and storage for you.
• A server, desktop tool or gateway. Use Python, in beta. It ships Bluetooth LE, internet relay, LAN peer-stream and gateway-client bridges, and a service that shares one engine with several local programs.
• A native iOS app without React Native. The Swift package is a preview for iOS 13 and later.
• A native Android app without React Native. The Kotlin library on Maven Central is a preview.
• A JVM service or desktop app. Use the Java binding on JDK 22 or later.
• C, C++, Go, C# or Zig. Use the C API, a header plus the native library from each GitHub release.
• A Rust program. Use the crates from crates.io and write the platform bridge yourself.
• A Flutter app. The Flutter plugin is a preview, used as a path dependency.
• A Ruby script or server. Install the Ruby binding, the offline_protocol gem on RubyGems, with the native library from the release.
• A web page. The browser build is experimental and built from source.
• ESP32 hardware or your own firmware. The IntelligenceMesh node relays Offline Protocol traffic with no setup. For a device of your own, the leaf crate builds for ESP32 RISC-V chips, Cortex-M0 and M33.

As of 0.31.0 (October 2026), React Native is the stable and most complete binding, and Python is in beta. Each release publishes the same version number on every channel it reaches.

The Swift package repository is generated by each SDK release and tagged with the same version as the other channels.

React Native is the package to choose for a phone app you ship, because it is the only binding that carries the full native bridges for both iOS and Android. It needs React Native 0.70 or later, iOS 13 and Android API 24, and TypeScript types ship with it. It is a native module, so a custom dev client or a bare React Native project is required; Expo Go will not load it.

npm install @offline-protocol/mesh-sdk

The quickstart exchanges an encrypted message between two phones over Bluetooth LE with no account or API key. For what the phones need to find each other, see how two phones find each other over Bluetooth.

For code on a server, desktop or gateway, Python does the most for you. Its wheels cover Python 3.10 or later on macOS arm64 (macOS 14 or later), Linux x86_64 and aarch64 with glibc 2.34 or later, and Windows x86_64. There is no wheel for Intel macOS, musl Linux such as Alpine, or an older glibc, so those hosts build from source. The package includes offline-protocol-service, which serves one engine to several local programs over JSON-RPC, and an optional HTTP front so a program that does not import the SDK can call a service on another device.

Java, C and Rust give you the engine with less around it. The Java binding calls the native library through the Java foreign function API and needs JDK 22 or later. The C API takes a JSON configuration, calls any method by name with JSON parameters and returns events as JSON, which suits C++, Go through cgo, C# through P/Invoke and Zig. In both, your process owns the radios and sockets and supplies storage. The Rust crates are I/O-free: they never open a socket or touch a radio for the protocol, so you write the bridge that drains each transport’s outbound queue and feeds inbound bytes back. Ruby, like Java, calls the native library directly, through the ffi gem, and is not on RubyGems yet. Running on a server or in Docker, a Raspberry Pi or Windows each has its own article.

The Swift package, the Kotlin Android library and the Flutter plugin let you skip React Native, at the cost of doing more wiring yourself. All three are built from the same native bridge sources as the React Native module, and their public names may change.

• Swift. iOS 13 or later, iOS only, with no macOS or Mac Catalyst slice. Its storage providers are not public yet, so an app cannot construct them, and wiring the transports to the engine is the app’s job.
• Kotlin. Android 7 (API 24) or later, with the Bluetooth LE, Wi-Fi Direct and internet transport managers and the storage classes inside. The React Native module that ties them to the engine is not included.
• Flutter. Flutter 3.10 or later on iOS 13 and Android API 24. It is not on pub.dev: you check out the SDK at a release tag, build the mobile native libraries with the Rust toolchain, and depend on the plugin by path.

If you need the complete integration on phones today, the docs point you to React Native.

The browser build is experimental. It runs the engine in a dedicated worker and stores identity and groups in origin-private files. As of 0.31.0 it links tabs of one origin, devices on one network over WebRTC, browsers behind one network address through a nearby room, and the Nostr transport over the application’s relays. In Chromium a page can also link to a phone or a board over Web Bluetooth. Its JavaScript package is not published, so you build it from source.

ESP32 hardware runs Offline Protocol as a mesh relay today. The IntelligenceMesh node, an M5StickC Plus2 built on the ESP32-PICO-V3-02, ships pre-flashed with firmware that relays Offline Protocol mesh traffic over Bluetooth LE GATT as both peripheral and central. It works with Offline Protocol apps and SDK projects, and relays Bitchat traffic at the same time.

For firmware teams building their own peer device, offline-protocol-leaf lets a constrained device such as a lock or sensor join encrypted groups as a member that never issues commits, paired with a phone or host that runs a full peer. It builds for ESP32-C6, ESP32-H2, ESP32-C3 and ESP32-C2, Cortex-M0 and Cortex-M33, and WASI, and the firmware supplies radio I/O, entropy and durable storage. Can a microcontroller run encrypted mesh messaging? covers the general constraints.

Every binding is AGPL-3.0-only, with a commercial licence available for products that cannot meet the AGPL obligations; the licensing page explains when you need it. If you would rather let a coding agent choose, the Offline Protocol MCP server answers package questions from the current registry, and the offline CLI can plan and scaffold a project. The platform guide shows which transports each platform can use.