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

# Swift SDK for iOS

> Prepare an iOS agent interface with protected server access, microphone disclosure, scene lifecycle, and device acceptance checks.

Prepare your iOS application while the Threetone native client release is pending. There is no verified public Swift package URL, package version, or supported iOS session recipe in this guide.

## Prepare access and permissions

Keep workspace API keys on a trusted server. Authorize the application user for the intended agent before issuing access through the eventual supported session flow. A key included in an app bundle is not a server-held secret.

For a voice interface, provide a meaningful `NSMicrophoneUsageDescription` explaining why the app needs audio input. Review [Apple's microphone usage-description reference](https://developer.apple.com/documentation/bundleresources/information-property-list/nsmicrophoneusagedescription). Design a useful path for permission denial and an explicit user action to start voice capture.

## Define session ownership

<Steps>
  <Step title="Choose the owning model or controller">
    Keep connection ownership separate from a view's repeated rendering. Decide what happens when the user leaves the conversation screen, opens another scene, or signs out. One displayed interaction should not accidentally create multiple sessions.
  </Step>

  <Step title="Observe application state">
    For SwiftUI, review [ScenePhase](https://developer.apple.com/documentation/swiftui/scenephase) when planning active, inactive, and background behavior. State observation does not grant background audio execution; follow the eventual SDK and platform requirements.
  </Step>

  <Step title="Make ending explicit">
    Provide a visible end action and define how it cancels pending work, removes subscriptions, and releases owned audio resources. Handle interruptions and network loss without showing stale connected state.
  </Step>
</Steps>

## Verify on physical devices

After a supported client and runtime are available, test permission denial, lock and unlock, background transitions, incoming calls, Bluetooth changes, network transitions, access expiry, and repeated entry to the screen. Record the iOS version, package version, and session contract used.

Before a public release, verify the package's authoritative source, minimum deployment target, audio configuration, supported concurrency model, and reconnect behavior. Do not infer those requirements from a browser widget or private dashboard component.

See [mobile deployment](/agents-platform/deploy/mobile/overview) and [server resource access](/agents-platform/deploy/server/overview) for the current separation of responsibilities.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Can I add a guessed Swift Package Manager URL?" id="swift-faq-package">No. Use only a verified first-party package and its published installation instructions once available.</Accordion>
  <Accordion title="Does a microphone usage description authorize recording automatically?" id="swift-faq-permission">No. It explains the permission request. The application must still handle the user's permission decision and the supported audio lifecycle.</Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.