Offline Protocol platforms and bindings
Offline Protocol covers phones, desktop and server hosts, browsers and microcontrollers, at different levels of maturity. As of 0.31.0 (October 2026), this is where each binding runs:
| Platform | Bindings | Status |
|---|---|---|
| iOS 13+ | React Native, Swift, Flutter | React Native stable; Swift and Flutter previews |
| Android 7+ (API 24) | React Native, Kotlin, Flutter | React Native stable; Kotlin and Flutter previews |
| macOS arm64 | Python (macOS 14+), Java, C, Rust, Ruby | Python beta; the others leave transports to your code |
| Linux x86_64 and aarch64 | Python (glibc 2.34+), Java, C, Rust, Ruby | Python beta; the others leave transports to your code |
| Windows x86_64 | Python, Java, C, Rust, Ruby | Python beta, without the Bluetooth LE peripheral role |
| Web browsers | Browser binding | Experimental, built from source |
| ESP32 (IntelligenceMesh node) | Pre-flashed IntelligenceMesh firmware | Shipping mesh relay |
| ESP32 RISC-V, Cortex-M0 and M33, WASI | offline-protocol-leaf | Published, for your own firmware |
Each GitHub release attaches the native library for Linux (x86_64, aarch64), macOS (arm64) and Windows (x86_64), plus the iOS XCFramework and the Android libraries. To pick a package rather than a platform, start with which Offline Protocol SDK to use.
Apple platforms: iOS and macOS
On iOS, React Native is the complete integration, with iOS 13 as the minimum deployment target. The native Swift package also targets iOS 13 or later, but it is a preview with no macOS or Mac Catalyst slice, its storage providers are not public yet, and the app wires the transport managers to the engine itself. The Flutter plugin is a preview on the same iOS floor.
On a Mac, Offline Protocol runs as a host rather than an app framework. Python wheels need macOS 14 or later on arm64, and Java, C, Rust and Ruby use the macOS arm64 native library from the release. There is no Intel macOS wheel or library, so an Intel Mac builds from source.
Android support
Android phones run Offline Protocol from Android 7 (API 24). React Native carries the full bridges, and its Android build needs compileSdk and targetSdk 34 and JDK 17. The Kotlin library on Maven Central is a preview that contains the Bluetooth LE, Wi-Fi Direct and internet transport managers and the storage classes, with native libraries for arm64-v8a, armeabi-v7a, x86 and x86_64; wiring them to the engine is the app’s job. The C API is not available on Android, because the C binding is off in the Android builds. For the platform background, see Android Bluetooth permissions.
Linux and Windows hosts
Linux and Windows run Offline Protocol through Python, Java, C, Rust or Ruby. On Linux, the Python wheels cover x86_64 and aarch64 with glibc 2.34 or later, which means Debian 12, Ubuntu 22.04, RHEL 9 or newer; musl distributions such as Alpine build from source. Python’s Bluetooth LE peripheral serves its Hello characteristic on BlueZ, and the docs report it running between an Android phone and Raspberry Pis, covered in Offline Protocol on a Raspberry Pi.
On Windows x86_64, the Python wheel installs, but the bless peripheral library is not installed there, so a Windows host acts as a Bluetooth LE central only. The C binding ships the DLL with its import library, and Java needs JDK 22 or later on any of these hosts. Offline Protocol on Windows has the details.
Web browser support
The browser build is experimental and runs in Chromium, Firefox and Safari. It is the same Rust engine compiled to WebAssembly, run in a dedicated worker, and it needs a secure context such as an HTTPS page. As of 0.31.0 it links tabs of one origin, devices on one network over WebRTC, and any device by its address over the Nostr transport, through relays the application supplies. Web Bluetooth lets a Chromium page link to a phone or board as a central only; Firefox, Safari and every browser on iOS lack Web Bluetooth. The JavaScript package is not published, so you build it from source. See Offline Protocol in a web browser.
Espressif and Arm microcontrollers
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, needs no Wi-Fi or account, and relays Bitchat traffic at the same time.
For firmware teams building their own peer device, the offline-protocol-leaf crate lets a constrained device join encrypted groups as a member that never issues commits, paired with a phone, host or other full peer. It builds for these targets:
| Chip family | Rust target |
|---|---|
| ESP32-C6, ESP32-H2 | riscv32imac-unknown-none-elf |
| ESP32-C3, ESP32-C2 | riscv32imc-unknown-none-elf |
| Cortex-M33 (for example Silicon Labs xG24) | thumbv8m.main-none-eabihf |
| Cortex-M0 and M0+ (for example RP2040) | thumbv6m-none-eabi |
| WASI | wasm32-wasip1 |
The firmware supplies radio I/O, hardware entropy, time at pairing and durable storage, and on the ESP32-C3, ESP32-C2 and Cortex-M0 it links a critical-section implementation, since those chips have no atomic compare-and-swap. On Arm application processors, Linux aarch64 hosts run Python, Java, C and Rust. Read which microcontrollers can run Offline Protocol and what an ESP32 is for more.
Transports by platform
Which transports you get depends on the binding as much as the device. This table follows the docs’ transport compatibility table:
| Path | Phones (React Native) | Python hosts | Java, C, Rust | Browser |
|---|---|---|---|---|
| Bluetooth LE | iOS and Android native bridges | Central through bleak, peripheral through bless (not on Windows) | Your code | Chromium central to a phone or board |
| Wi-Fi peer streams | Android Wi-Fi Direct and the Wi-Fi network it is on; iOS Network framework over LAN or AWDL | Authenticated TCP over an existing IP network, reaching iPhones and Android phones on it | Your code | WebRTC on one network |
| Internet relay | WebSocket to a configured relay | Client included | Your code | Not built; Nostr reaches the same devices |
| Reticulum | Needs a daemon or gateway the package does not ship | You supply the transport callback | Your code | Not listed |
| Nostr | Needs reachable relays | You supply the transport callback | Your code | Over the application’s relays |
A shared transport name does not mean two platforms interoperate. The iOS peer stream does not reach an Android Wi-Fi Direct group, so an iPhone and an Android phone meet over Wi-Fi only on a shared network that allows multicast. Bluetooth LE is the common path between phones, as iPhone and Android messaging over Bluetooth explains. A device running the leaf moves frames over its own radio; for internet transport, its firmware adds a relay client or pairs with a companion full peer that has one.