💡 Target Audience: Founders and tech leads weighing whether to build native iOS, native Android, web, AND a desktop app — and dreading the duplicate integration work.

The "platform tax" most chat APIs charge

Modern apps almost always span multiple runtimes:

• A web app (React/Next.js)
• A mobile app (React Native, Flutter, or native Swift + Kotlin)
• Sometimes a desktop client (Electron) or a backend integration (Node)

With most chat APIs, every additional platform is essentially a new integration project: separate auth flows, different data shapes, sometimes a different feature set, and always a different bug surface. Some vendors don't even ship a native iOS or Android SDK — they hand you raw WebSocket docs and wish you good luck.

HyperBabel ships six first-party SDKs that share the same API key, the same data contracts, and the same feature parity. Pick the stack your team already knows.

Same call, six runtimes

Here's how you create a chat room with three members in each official SDK. Note the structural identity — the SDK names mirror the platform, but the shape never changes:

JavaScript / TypeScript (web, Node):

import { HyperBabel } from '@hyperbabel/client';

const hb = new HyperBabel({ apiKey: process.env.HYPERBABEL_KEY });
const room = await hb.chat.createRoom({
  type: 'group',
  name: 'Global Team',
  members: ['user_a', 'user_b', 'user_c']
});

React (with hooks):

import { useHyperBabel } from '@hyperbabel/react';

function CreateRoomButton() {
  const { chat } = useHyperBabel();
  return <button onClick={() => chat.createRoom({
    type: 'group', name: 'Global Team', members: ['user_a', 'user_b', 'user_c']
  })}>Create Room</button>;
}

React Native:

import { HyperBabel } from '@hyperbabel/react-native';

const hb = HyperBabel.init({ apiKey: API_KEY });
const room = await hb.chat.createRoom({
  type: 'group', name: 'Global Team', members: ['user_a', 'user_b', 'user_c']
});

Swift (iOS/macOS):

import HyperBabel

let hb = HyperBabel(apiKey: apiKey)
let room = try await hb.chat.createRoom(
    type: .group,
    name: "Global Team",
    members: ["user_a", "user_b", "user_c"]
)

Kotlin (Android):

import com.hyperbabel.client.HyperBabel

val hb = HyperBabel(apiKey = apiKey)
val room = hb.chat.createRoom(
    type = RoomType.GROUP,
    name = "Global Team",
    members = listOf("user_a", "user_b", "user_c")
)

Flutter (Dart):

import 'package:hyperbabel/hyperbabel.dart';

final hb = HyperBabel(apiKey: apiKey);
final room = await hb.chat.createRoom(
  type: RoomType.group,
  name: 'Global Team',
  members: ['user_a', 'user_b', 'user_c'],
);

Switch any of these to send a message, start a video call, kick off a live stream, or trigger AI translation — the shape stays consistent. Read the spec once, ship six clients.

Feature parity matrix

No "iOS only" features. No "we'll add it to React Native next quarter". The same surface lands on every platform at the same time.

A single API key across everything

The web client, the iOS app, and the Android app all use one HyperBabel API key. Messages sent from the iOS client appear in the web client's chat history immediately. The same channel ID works across runtimes. No federation glue, no cross-platform sync layer to maintain.

For multi-environment safety, you can also issue separate keys per platform (Web, iOS, Android, Server) so a leak on one platform doesn't compromise the others. Live keys and Test keys are strictly isolated — Test traffic never touches production data, never bills, and never leaks across.

What about Go, .NET, Python?

First-party SDKs for these are planned for late 2026 into 2027 — contact us for timelines. In the meantime, every SDK is a thin wrapper over the public REST + WebSocket APIs at api.hyperbabel.com/api/v1, so any HTTP client works for backend integrations today.

Pick the stack and ship

Clone any of the six sample apps — they all integrate chat, video, live streaming, AI translation, and file uploads end-to-end. Drop in your API key and run. Chat, translation and 1:1 video work on any paid key; group video and live streaming need Scale, so those screens return plan_upgrade_required until the plan covers them.