SwiftOpenAI: A Complete Swift Package for the Full OpenAI API

What SwiftOpenAI Covers and Who Uses It

SwiftOpenAI provides Swift type definitions and async methods for every category of OpenAI's public API: audio transcriptions, audio translations, speech synthesis, and the Realtime API for bidirectional voice; chat completions with function calling, structured outputs, and vision; the Response API with streaming; embeddings; fine-tuning; batch jobs; file management; image generation; model listing; and content moderation.

The beta Assistants API surface is also covered, including Assistants, Threads, Messages, Runs, Run Steps, Vector Stores, and streaming events for assistant interactions. These are stable enough for production use in many apps but carry the beta designation from OpenAI.

The package targets developers building Swift applications on Apple platforms or Linux who want to interact with OpenAI services through a typed API rather than constructing URLSession requests and decoding JSON manually. Release 4.6.2 was published on 2026-09-09, and the repository uses semantic versioning with proper GitHub releases.

OpenAI-Compatible Provider Support

Beyond the official OpenAI API, SwiftOpenAI supports a wide set of OpenAI-compatible providers through the OpenAIServiceFactory's convenience initializers. The README lists: Azure OpenAI, Anthropic, Gemini, Ollama, Groq, xAI, OpenRouter, DeepSeek, and AIProxy.

This means a developer can point the same service interface at a local Ollama instance for development and at the OpenAI API in production, switching only the factory initialization line. The README directs users to check OpenAIServiceFactory for the available initializers, which accept custom base URLs and API keys.

This breadth distinguishes SwiftOpenAI from a narrow OpenAI-only wrapper. A team building a feature that needs to compare outputs from different providers can do so without adopting multiple networking libraries. Anthropic and Gemini support is particularly useful as alternatives to OpenAI when pricing or capability differences matter for a specific task. The Ollama support is particularly valuable during development, because it allows running inference locally without incurring API costs on every test run, then switching to a hosted provider for production by changing a single initializer.

Platform Support: Apple Devices and Linux

SwiftOpenAI targets iOS 15+, macOS 13+, and watchOS 9+ on Apple platforms. On Apple platforms it uses URLSession for networking.

On Linux, URLSession in Apple's Foundation framework has known bugs. The README documents that SwiftOpenAI on Linux uses AsyncHTTPClient to work around these issues. This makes the package usable with the Vapor server framework, allowing server-side Swift applications to interact with OpenAI services using the same package they would use in an iOS app.

The Linux compatibility path is a practical consideration for teams building full-stack Swift applications where both the server (Vapor on Linux) and the client (iOS) need to call OpenAI. A single dependency handles both rather than requiring separate HTTP clients on each platform.

Installing SwiftOpenAI via Swift Package Manager

Installation uses Xcode's built-in Swift Package Manager support:

1. Open your Swift project in Xcode. 2. Go to File, then Add Package Dependency. 3. Enter the repository URL: https://github.com/jamesrochabrun/SwiftOpenAI. 4. Choose a version range. 5. Click Add Package.

The README includes a version note worth reading: Xcode defaults the upper bound of an SPM package to 2.0.0 when first resolving. SwiftOpenAI is beyond that limit (currently at 4.x), so Xcode's default version proposal will be wrong. The README instructs users to enter the lower bound of the release version they want and tab out of the field so Xcode recalculates the upper bound. Alternatively, selecting branch -> main stays on the latest commit. Using a specific release version (such as 4.6.2, the version from 2026-09-09) is the safer approach for production targets, since main can advance between your initial integration and a later build.

Once added, import the module in Swift source files:

import SwiftOpenAI

Initializing the Service and Handling Timeouts

The entry point is OpenAIServiceFactory. The simplest initialization takes an API key:

let apiKey = "your_openai_api_key_here"
let service = OpenAIServiceFactory.service(apiKey: apiKey)

To include an organization ID:

let apiKey = "your_openai_api_key_here"
let oganizationID = "your_organixation_id"
let service = OpenAIServiceFactory.service(apiKey: apiKey, organizationID: oganizationID)

Reasoning models (such as o-series models) can take longer than the URLSession default timeout of 60 seconds to respond. The README instructs users to extend the timeout for these models:

let apiKey = "your_openai_api_key_here"
let organizationID = "your_organization_id"
let session = URLSession.shared
let httpClient = URLSessionHTTPClientAdapter(urlSession: session)
let service = OpenAIServiceFactory.service(apiKey: apiKey, organizationID: organizationID, httpClient: httpClient)

The session.configuration.timeoutIntervalForRequest value should be set before creating the adapter; the README suggests 360 seconds or more.

AIProxy, Security, and Error Handling

The README includes an explicit security warning: API keys must not appear in client-side code, as any user who inspects the app can extract them. SwiftOpenAI has built-in support for AIProxy, described as a backend for AI apps, which routes requests through a server where the key can be loaded securely.

The AIProxy initialization path is documented in the README's AIProxy section. Teams building consumer-facing apps should treat this as a required step before App Store submission, not an optional enhancement.

For error handling, the README shows the APIError type, which includes a responseUnsuccessful case with two associated values: a description and a statusCode. This allows building UI responses around specific HTTP status codes. A 429 response, for example, indicates rate limiting and can trigger a retry or user notification in the app.

The same error type works across all endpoint calls, so error handling logic written for chat completions applies to embeddings, fine-tuning, and other endpoints without modification. This uniform error surface reduces the amount of provider-specific error handling code a developer needs to write when building apps that call multiple OpenAI endpoints within the same user flow.

Comparison with Direct URLSession Calls and License Considerations

The direct alternative to SwiftOpenAI is writing URLSession-based code against the OpenAI REST API: encode request parameters into JSON, fire the request, decode the response, handle streaming via URLSessionDataDelegate, and build types for each API endpoint manually. SwiftOpenAI replaces all of that with generated Swift types and async/await methods.

OpenAI also publishes an official openai/openai-swift package. SwiftOpenAI differentiates itself by covering a wider set of endpoints including the full beta Assistants surface and the Realtime audio API, by supporting Linux via AsyncHTTPClient, and by including built-in AIProxy integration and OpenAI-compatible provider support through OpenAIServiceFactory. Teams evaluating both should check which endpoints they need and whether the official package covers them before deciding.

SwiftOpenAI is also available as a CLI (jamesrochabrun/SwiftOpenAICLI) and as an MCP server (jamesrochabrun/SwiftOpenAIMCP) for teams that need those interfaces alongside the package. The MIT license permits commercial use, modification, and redistribution without restriction.

Editorial conclusion

iOS and macOS developers who need type-safe access to the full OpenAI endpoint surface, including the Realtime audio API and the beta Assistants API, will find SwiftOpenAI the most complete open-source option in this space. The package is actively maintained with release 4.6.2 published on 2026-09-09. Teams who need to protect API keys in client-facing apps should read the AIProxy setup instructions before shipping; the README is explicit that API keys in client-side code are a security risk and AIProxy is the built-in mitigation. Linux support uses AsyncHTTPClient rather than URLSession, which is a compatibility layer worth verifying if you plan to deploy on Vapor.

Frequently asked questions

Official sources

1. Issues
2. jamesrochabrun/SwiftOpenAI on GitHub
3. License: MIT
4. README
5. Releases