Carry voice from an iOS or Android app into TeleQuick Voice over the same QUIC / WebTransport plane the browser uses. This page describes the intended native mobile path and the workarounds you can ship today — because the native mobile SDKs are on the roadmap, not in your hands yet.
Native iOS (Swift) and Android (Kotlin) SDKs are plan-only. There is no Swift or Kotlin client source today. If you need voice in a mobile app right now, use one of the two workarounds below. Everything in the “Planned native path” section is roadmap and may change.

​
Why mobile is different

The browser path leans on the browser: a loopback capture pipeline runs Opus encode, echo cancellation, and jitter buffering, and a WebRTC diversion taps the encoded frames onto QUIC. A native app has no browser to borrow, so it needs a QUIC/MoQT client compiled for the device — plus mic capture, Opus, and playback wired up by hand. The server-side engine reactor is a Linux, kernel-bypass runtime — it physically will not run on a phone. So the mobile client is built on a separate, portable QUIC event loop (the same one the non-browser SDK cores use), not the engine.

​
What works today

Run the browser SDK in a WebView

Host the JavaScript SDK inside a system WebView and let the WebView’s WebTransport stack carry audio. Fastest to ship; constrained by WebView capability (below).

Embed a native-core SDK

Bundle a non-browser SDK core (Go or Rust) into a cross-platform mobile runtime. Gets you the native QUIC→WebSocket fallback ladder that the browser SDK does not have.

​
Option A — WebView + WebTransport

The browser transport works unchanged inside a WebView if that WebView ships WebTransport and the W3C Encoded Transform API. In practice:
Android System WebView is Chromium-backed, so recent versions expose WebTransport and RTCRtpScriptTransform. Load a page that runs browser audio capture, grant the mic permission through the WebView permission callback, and audio flows over QUIC exactly as it does in Chrome. Verify the device’s WebView version — older ones lack the Encoded Transform gate and the SDK will refuse to capture.
The browser SDK has no WebSocket fallback — it is WebTransport-only. On a flaky cellular network with UDP blocked, a WebView session can fail to connect with no automatic retry over TCP. Option B avoids this.

​
Option B — embed a native-core SDK

The non-browser SDKs (github.com/telequick/telequick-sdk/go, telequick, telequick, plus Java and .NET) reach WebTransport/MoQT through a shared native transport core — a portable C++ QUIC engine wrapped for each language. That core carries a QUIC → WebSocket fallback ladder: when QUIC can’t establish (UDP-blocked networks, TCP-only proxies) it sticks to a WebSocket rung so audio still flows. You embed one of those cores in a cross-platform mobile framework (for example, a Go or Rust core compiled for arm64 and bridged into your app) and drive the same AudioBridge surface documented in the SDK reference: 
// Same AudioBridge surface as server + browser; here the client core
// is embedded natively, not the browser transport.
const bridge = await voice.audioBridge.attach(callSid, {
  codec: "opus",            // app legs are Opus on the wire
});
bridge.onDownlink((frame) => player.enqueue(frame)); // agent → device
mic.onFrame((pcm) => bridge.publishUplink(pcm));     // device → agent
You are responsible for mic capture, Opus encode/decode, and playback on the device; the SDK core owns the transport. See the SDK cores for the exact method names.

​
Planned native path (roadmap)

The intended long-term shape gives you real Swift and Kotlin packages so you never touch C directly:
1

One shared transport core, compiled per platform

The portable QUIC/MoQT core is compiled to a per-ABI native library for Android and a static library for iOS, so both platforms share one audited transport implementation.
2

Thin platform bridges

A Kotlin layer over the Android library and a Swift layer over the iOS static library expose an idiomatic AudioBridge — publishUplink / onDownlink — matching the other SDKs.
3

Native fallback ladder included

Because the mobile client is built on the same core as the other native SDKs, it inherits the QUIC→WebSocket fallback ladder — the resilience the browser path lacks — which matters most on cellular.
4

Unity / game-engine target alongside

The same core also backs a Unity/native-FFI target (per-ABI library on Android, static archive via [DllImport("__Internal")] on iOS) for game and XR clients.
Track the roadmap status in status quick-reference. Mobile native clients are aspirational — no Swift/Kotlin source exists yet. The Unity target and the native cores you’d embed today are the concrete precursors.

​
Audio on the app leg

However you connect, the wire contract for an app is the same as the browser:
  • Codec — Opus on the app leg (AudioCodec = "opus"). The engine transcodes to and from its internal 8 kHz PCM16 bus and to G.711 on any phone leg, so your app never has to match the caller’s codec.
  • Framing — 20 ms Opus frames, mono. The RTP clock stays at 48 kHz even though the encoder’s internal rate is narrowband — you don’t manage this.
  • No on-device echo cancellation from us — the runtime relies on the platform’s own AEC. Enable the OS voice-processing audio mode (VoIP category on iOS, voice-communication mode on Android) so the mic is echo-cancelled before Opus encode. See voice isolation for what the engine does and does not do.

​
Status

PathStatus
WebView + WebTransport (Android)Works where the WebView supports WebTransport
WebView + WebTransport (iOS)Not available (no WKWebView WebTransport)
Embed a native-core SDK (Go/Rust)Available — carries the QUIC→WebSocket fallback
Native Swift SDKRoadmap — plan only
Native Kotlin SDKRoadmap — plan only
Unity / FFI targetPlanned, precursor to native mobile

WebRTC diversion

How the browser taps encoded Opus onto QUIC — the model a WebView reuses.

WebTransport

The single-port QUIC plane every client dials.

Rust SDK

A native-core SDK you can embed in a mobile runtime today.

Transport to Web & Apps

Where mobile fits in the overall client-transport picture.