Overview

Embed the Loops AI assistant in any mobile app without our SDK — load the chat in a WebView and wire the message bridge yourself.

The iOS and Android SDKs are the fastest way to put the assistant inside a native app. This section is for every case where adding them is not an option — React Native, Flutter, Cordova / Capacitor, Kotlin Multiplatform, Unity, an in-house framework, or simply a strict dependency policy.

You do not need the SDK. The assistant is a web runtime, and both SDKs are thin native containers around it: a WebView, a message bridge, and a small session store. Any platform that can (1) display a WebView and (2) exchange strings with the page inside it can host the same runtime with the same features.

What you build

Three pieces, and that is the whole integration:

A WebView that loads the chat URL with mode=sdk.
A bridge object named loopsAIBridge that the page can call to send you messages, plus a way for you to push messages back into the page.
Your own handling of the two messages that need a native decision: closeChat (dismiss the container) and openExternalUrl (route a product link).

Everything else — the conversation UI, product carousels, size flows, virtual try-on, localization, theming — is already inside the runtime and driven by your agent's configuration.

Two transports, one contract

The action names and payloads are identical in both cases. Only the envelope and the delivery mechanism differ.

Your app is…	Transport	Page is	Read next
Native (Swift, Kotlin, React Native, Flutter, Unity…)	Native WebView + a `loopsAIBridge` object	The top-level document in the WebView	Quickstart
A web app inside a container (Capacitor, Cordova, Ionic, an in-app HTML screen)	Real `<iframe>` + `window.postMessage`	An iframe inside your own page	The message bridge → iframe transport

Pick the native transport when you can

A native WebView gives you real navigation control (a product tap becomes a native route push) and one less layer. Use the iframe transport when your app's screen is already a web page and you cannot register a native message handler.

Feature parity with the SDK

Everything the runtime does is available. What you give up is the native convenience the SDKs add on top.

Capability	Without the SDK	Notes
Chat, product carousels, recommendations	✅ Identical	Comes from the runtime
Size suggestion, body-type size guide	✅ Identical	Flow modes
Virtual try-on, voice mode	✅ Identical	Needs camera / mic permission wiring
Product & user context	✅ Identical	Sent over the bridge
Product tap → your native product screen	✅ Identical	Links & navigation
Canonical analytics events	✅ Forwarded to you	You route them to your provider
Session survives app relaunch	⚠️ You own it	Persist two ids — Session
Warm WebView for instant reopen	⚠️ You own it	Keep your WebView alive instead of recreating it
Typed native API, delegates, availability check	❌	You call the bridge directly

Nothing is gated

There is no separate "custom integration" plan, API key, or client secret. The runtime is addressed by your public agentId in the URL path, and access is resolved server-side per agent. Your integration uses the same endpoint the SDKs use.

Start here

Quickstart

A working container in one page — React Native, Flutter, Swift, Kotlin, or an iframe.

The chat URL

Every query parameter: mode, platform, locale, session, and flow entry points.

The message bridge

Envelope, handshake, and the complete action tables in both directions.

Flow modes

Open size suggestion, the size guide, try-on, or AI search from your own buttons.

Links & navigation

Product taps, closing the chat, and keeping attribution intact.

Checklist & troubleshooting

What to verify before you ship, and the failure modes worth knowing.

Already on iOS or Android native?

Use the SDKs — they ship the container, the session store, the warm-WebView pool, and typed callbacks. This section describes what they do internally, so it is also a useful reference if you are debugging an SDK integration.