Skip to main content
The iOS and Android content SDKs are the native client libraries for Metabind content. On iOS, that’s the MetabindContent library in the metabind-apple Swift package; on Android, it’s the ai.metabind:metabind-content-android artifact from metabind-android. Both wrap the GraphQL content API, add a local normalized cache, and integrate with the BindJS runtime so you can render content as native UI without a separate composition step.

iOS SDK

MetabindContent in the metabind-apple Swift package. Install, configure, render with SwiftUI.

Android SDK

ai.metabind:metabind-content-android Maven artifact. Install, configure, render with Compose.

​
The two-layer architecture

The mobile SDKs are a content client (MetabindContent / metabind-content-android) paired with a BindJS rendering layer (bindjs-apple / bindjs-android).
The content layer fetches data; the BindJS layer renders it. They’re decoupled — you can use one without the other — but they’re paired in the templates and sample apps for the simplest case.

​
How rendering works

Both platforms expose a single view that takes a content ID, fetches the content and its components, and renders them as native UI:
  • iOS: MetabindView(contentId:) — a SwiftUI view. See the iOS SDK.
  • Android: MetabindView(contentId =) — a Composable. See the Android SDK.
The view handles loading and error states, resolves the content’s bound components, and renders them through the BindJS runtime (bindjs-apple / bindjs-android) as native SwiftUI or Jetpack Compose — not a WebView.

​
Real-time updates

Each MetabindView accepts an enableSubscription flag. When it’s set, the SDK opens a GraphQL WebSocket subscription and re-renders when the content changes in Metabind — useful for live previews and content that updates without an app release. For finer control, both SDKs also expose direct subscription APIs that stream content changes over the same WebSocket — subscribeToContent(id:) on iOS and subscribeToPreviewByToken(token) on Android. See the per-platform pages for examples.

​
Caching

Both SDKs ship a local cache so content is available instantly on repeat views and across launches:
  • In-memory for hot data during a session.
  • Persistent via a normalized SQLite store.
On iOS, the fetch methods accept a per-call cache policy; on Android, the SDK configures the cache for you (a 10 MB in-memory layer chained to SQLite).

​
Assets

Asset URLs returned with content point at the Metabind CDN, which supports on-the-fly transformations via query parameters:
For 3D models and video, the SDKs handle streaming and progressive loading.

​
When to use the SDK vs. raw GraphQL

The SDK gives you typed content access, cache management, real-time subscriptions, and BindJS rendering integration. If your app needs those, use the SDK. If you only need a single content read for a server-side render or a backend job, raw GraphQL via your platform’s HTTP client is fine — see Querying content.

iOS SDK

Full iOS SDK reference.

Android SDK

Full Android SDK reference.

Querying content

Other ways to read content.

GraphQL API

The underlying GraphQL surface.