> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> Native iOS and Android client libraries for fetching Metabind content and rendering it through BindJS
The iOS (`metabind-apple`) and Android (`metabind-android`) SDKs are the native client libraries for Metabind content. They 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.
Swift Package — `metabind-apple`. Install, configure, render with SwiftUI.
Maven library — `metabind-android`. Install, configure, render with Compose.
## The two-layer architecture
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](/content/mobile-sdks/ios-sdk).
* **Android:** `MetabindView(contentId =)` — a Composable. See the [Android SDK](/content/mobile-sdks/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:
```
https://cdn.metabind.ai/.../image.jpg?w=600&q=80&fmt=webp
```
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](/content/querying/overview).
## Related
Full iOS SDK reference.
Full Android SDK reference.
Other ways to read content.
The underlying GraphQL surface.