> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The catalog of every model — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it.
> Fastest path to a working app: `npx create-reactor-app my-app --model=<slug>` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/<model>; Python uses the base reactor-sdk package.
> Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code.
> Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp.

# Installation

> Add the package with Swift Package Manager and link one target

The Swift SDK is a Swift 6 package for macOS and iOS, built on the same Rust core the Python and C++
SDKs bind. Unlike the C++ SDK's per-platform archive, it ships as **one SwiftPM package**: the native
library travels as a binary target the package manifest already points at, so a consumer never
downloads or links it by hand.

## Platforms

| Platform | Requires |
| -------- | -------- |
| macOS    | 13+      |
| iOS      | 16+      |

macOS 13 rather than 11 — reactor-webrtc's prebuilt libwebrtc goes down to macOS 11 on arm64, but its
x86\_64 slice needs 13, and the XCFramework lipo's both architectures into one macOS slice. 13 is the
floor that keeps Intel Macs working.

## Install

Add the repository as a package dependency — the manifest, `Package.swift`, lives at the repository
root, so this is the same URL whichever language you were looking at:

```swift Package.swift theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
dependencies: [
    .package(url: "https://github.com/reactor-team/reactor-client-sdks", from: "1.0.0")
]
```

```swift Target theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
.target(
    name: "YourApp",
    dependencies: [
        .product(name: "Reactor", package: "reactor-client-sdks")
    ]
)
```

In Xcode: **File → Add Package Dependencies…**, paste the URL, and select the **Reactor** library
product.

```swift theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
import Reactor

let reactor = try Reactor(model: "reactor/helios", jwt: token)
try await reactor.connect()
```

<Note>
  A model name is `owner/name`. A bare name resolves under `reactor/`, so `"helios"` works by luck of
  ownership and answers 403 for anyone else's model — write the owner out.
</Note>

## What SwiftPM resolves

The **Reactor** product is the only thing a consumer links. Behind it, the manifest pulls in
`CReactorFFI` — a binary target over a prebuilt XCFramework carrying `libreactor_ffi` and libwebrtc,
resolved and cached by SwiftPM like any other binary dependency. There is no separate download step
and nothing to point CMake or a linker at: adding the package is the whole installation.

There is no source distribution of the native library, on purpose — building it needs a Rust
toolchain and a libwebrtc checkout, which is exactly what a consumer of a Swift package should not
have to own.

## Next

<CardGroup cols={2}>
  <Card title="Reactor" icon="plug" href="/sdk-reference/swift/reactor">
    Connecting, commands, uploads, recordings, events.
  </Card>

  <Card title="Track" icon="video" href="/sdk-reference/swift/track">
    Pushing frames, receiving them, publishing, pausing.
  </Card>

  <Card title="Types" icon="braces" href="/sdk-reference/swift/types">
    `ReactorStatus`, `ReactorError` and its codes, `Clip`, `Subscription`.
  </Card>
</CardGroup>