SwiftOpenAI: an OpenAI API client for Swift, from iOS apps to Vapor servers

What SwiftOpenAI covers, and who it is aimed at

SwiftOpenAI is a Swift package that wraps OpenAI's public API. The README lists the endpoint groups it exposes: audio (transcriptions, translations, speech, realtime), chat (function calling, structured outputs, vision), responses with streaming, embeddings, fine-tuning, batch, files, images, models and moderations. A separate block marked BETA covers the Assistants family: assistants and assistant file objects, threads, messages and message file objects, runs and run steps, assistants streaming with message and run step deltas, and vector stores with file and file batch objects.

The audience is narrow and clear. This is for people building Apple-platform apps in Swift, and for people running Swift on the server. The README states support for iOS 15+, macOS 13+ and watchOS 9+, plus Linux, where it says the package uses AsyncHTTPClient to work around URLSession bugs in Apple's Foundation framework and can be used with the Vapor server framework. If you are writing Python or TypeScript, this package has nothing to offer you.

How the service layer and provider initializers fit together

The README points at OpenAIServiceFactory for convenience initializers that accept custom URLs. That is the mechanism that makes the provider list work. Rather than a separate client per vendor, the package keeps one service abstraction and lets you point it at a different base URL, which is why Azure OpenAI, Anthropic, Gemini, Ollama, Groq, xAI, OpenRouter, DeepSeek and Tuning Engines all appear in the same section as AIProxy.

That design has a consequence worth stating plainly. Compatibility with those providers depends on how closely each one imitates OpenAI's request and response shapes, not on anything SwiftOpenAI normalises for you. The README says these providers are OpenAI-compatible "including but not limited to" the listed ones, and it does not document per-provider quirks or which endpoints each one supports. So the factory gets you a URL, and the rest is on you to check against the provider's own documentation.

The AIProxy entry is a different kind of support. The README describes AIProxy as a backend for AI apps and links to configuration instructions, framed around OpenAI's own warning that API keys must not be exposed in client-side code and that production requests must be routed through a backend server. SwiftOpenAI does not enforce that. It gives you a supported path to do it.

Installing SwiftOpenAI through Swift Package Manager

The README documents installation through Xcode's package dependency flow rather than a Package.swift snippet. In Xcode, choose File, then Add Package Dependency, and enter the repository URL https://github.com/jamesrochabrun/SwiftOpenAI.

The step that trips people up is version selection, and the README calls it out directly. Xcode defaults an SPM package's upper limit to 2.0.0, and this package is past that limit, so accepting the proposed defaults gives you a range that excludes the current releases. The README's instruction is to enter the lower bound of the release version you want and then tab out of the input box so Xcode adjusts the upper bound, or to select branch main to stay on the bleeding edge.

# In Xcode: File > Add Package Dependency
# URL: https://github.com/jamesrochabrun/SwiftOpenAI
# Version: enter the lower bound of the release you want, then tab out

Before you write any call, generate an API key. The README walks through signing up or logging in at platform.openai.com, navigating to the API key page and generating a key, and then repeats OpenAI's guidance that the key is a secret, must not appear in client-side code, and that production requests belong behind a backend server where the key loads from an environment variable or a key management service. If you intend to call OpenAI directly from a shipped app binary, stop here and plan the backend or AIProxy route first.

The README's Usage section is where the call examples live, and the excerpt available here cuts off at the start of that section. Treat the Examples directory in the repository, which contains RealtimeExample and SwiftOpenAIExample, as the working reference for a first call rather than guessing at initializer signatures.

The beta surface and the version-pinning cost

The README sets the Assistants APIs apart under a BETA heading. That is not a marketing label; it is the project telling you that the assistants, threads, messages, runs, run steps, assistants streaming and vector stores objects are on a different footing from the chat, audio and image endpoints. If your product depends on Assistants, you are building on the part of the package the maintainer has flagged as least settled.

The release cadence reinforces the point. Three releases landed in the weeks before the last push on 2026-09-09: 4.6.0 on 2026-08-23, 4.6.1 on 2026-09-08, and 4.6.2 on 2026-09-09. Frequent patch releases are normal for a client that tracks a fast-moving upstream API, and they are also a maintenance cost: you should expect to bump versions and re-read release notes rather than pin once and forget.

The README does not document a deprecation policy, a support window for older versions, or a rollback procedure for a bad upgrade. The Xcode upper-bound quirk makes this sharper, since a range that Xcode widens on your behalf can pull in a newer minor release than you intended. Pin deliberately.

Where SwiftOpenAI is the wrong choice

The clearest failure mode is architectural. OpenAI's own guidance, quoted in the README, says API keys must not be exposed in client-side code and that production requests must be routed through a backend. A Swift package that runs inside an iOS or watchOS app cannot satisfy that on its own. The package offers AIProxy support as the answer, but the README does not claim to solve key custody for you, and it does not document a keychain integration or an on-device secret store.

A second case is server-side Swift that is not Vapor. The README names Vapor specifically when describing Linux use, and says the Linux path relies on AsyncHTTPClient to work around Foundation's URLSession. If your server stack is something else, that combination is the one the project describes, and anything beyond it is unverified by the documentation.

Third, if you need a provider that only partially mimics OpenAI's shapes, the factory initializer will get you a URL and then leave you alone. There is no compatibility matrix in the README listing which endpoints work against Anthropic, Gemini or Ollama. For a provider whose API diverges on the endpoints you need, a native client for that provider is the better tool.

How it compares with calling URLSession yourself

The realistic alternative is not another Swift package; it is hand-rolling the HTTP layer. Foundation gives you URLSession and Codable, and OpenAI's REST API is plain JSON over HTTPS, so a small internal client is entirely feasible.

The difference is in what you inherit. A hand-rolled client has no BETA-labelled Assistants types, no realtime audio handling, and no factory of provider initializers, but it also has no upstream release cadence to track and no dependency whose version range Xcode can widen under you. The reverse is true of SwiftOpenAI: you get typed coverage of the endpoint list above and the provider initializers, at the cost of a dependency that ships patches as OpenAI's API moves.

The decision usually comes down to how much of the surface you touch. If you call chat completions and nothing else, a thin URLSession wrapper is a few hundred lines and you own all of it. If you need streaming responses, audio transcription and translation, image generation, embeddings, batch and fine-tuning in one codebase, reimplementing that is a project in itself, and that is the case SwiftOpenAI is built for.

Licence, maintenance and what the package asks of you

SwiftOpenAI is MIT-licensed, and the repository carries a LICENSE file at the top level alongside Package.swift, Package.resolved, Sources, Tests, Examples, CONTRIBUTING.md and a rules.swiftformat config. MIT is permissive: it lets you use the package in closed-source apps, and it comes with no warranty. Nothing in the README suggests a commercial support tier or a paid edition, so your support channel is the issue tracker and CONTRIBUTING.md. This is a description of the licence terms, not legal advice; read LICENSE yourself if the terms matter to your organisation.

On maintenance, the evidence is dates. The repository is not archived, and the last push was on 2026-09-09, the same day as the 4.6.2 release. The README also points to two sibling projects, SwiftOpenAICLI and SwiftOpenAIMCP, which means the same author maintains more than one consumer of this package. That is a reasonable signal of attention, but it also means the API you depend on is shared with other tools and can move for their reasons as well as yours.

Your upgrade cost is concrete: bump the version in Xcode, check the release notes for 4.6.x, and re-run your own tests against the endpoints you actually use. The README documents no automated migration path beyond that.

Editorial conclusion

Adopt SwiftOpenAI if you are writing a Swift app or a Vapor service that needs typed access to OpenAI's endpoints and you are willing to pin a version and re-check it against OpenAI's changelog. Do not adopt it if you need a stable, non-beta Assistants integration, because the README itself places those APIs under BETA. Before committing, verify two things in your own project: that Xcode resolved the version you intended rather than its default 2.0.0 upper bound, and that your API key path goes through a backend or AIProxy rather than shipping in client code.

Frequently asked questions

Official sources

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