OpenAI in Swift

Development biography · earlier archive

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

Project biography

OpenAI publishes much of its developer surface as open-source code — the API clients, the Agents SDK, Realtime samples, Codex, Codex Security — but almost all of it is TypeScript, Python, Go or Rust. Swift developers building native Apple apps usually rely on thin community wrappers that cover a slice of the REST API. This project set out to do the opposite: port the whole ecosystem, faithfully.

The work started on 25 September 2026 with the studio’s request to "go through every directory in the openai folder" and convert it to Swift. When asked how literally to take "convert this folder" (tens of thousands of files), the owner chose a pragmatic route: generate what can be generated from specifications, hand-write a small faithful core, and port each sibling project as its own Swift package. The result, consolidated into one Git monorepo on 26 September, now holds 22 packages, each depending on its siblings by relative path so a fresh clone builds without machine-specific setup.

The foundation is OpenAI, a REST client whose models and operations are generated by a Swift code generator from OpenAI's OpenAPI specification (352 operations per its provenance record), plus streaming and a Realtime WebSocket transport. On top sit OpenAIAgents (agents, runner, tools, handoffs, guardrails, sessions, tracing, MCP, realtime agents and voice pipelines), OpenAIGuardrails, the Realtime family (a reference client, a SwiftUI Realtime Console, voice-controlled UI components, the Realtime Agents demo and a voice-agent sample), ChatKit, the Apps SDK widget host, the harmony format and Metal inference engine for gpt-oss, and ports of simple-evals, openai/evals, Swarm, the openai CLI and 19 Cookbook recipes. A second family covers Codex: the app-server and codex exec clients (CodexSDK), the Codex plugin for Claude Code, the Codex GitHub Action and Codex Security.

What makes the project distinctive is how faithfulness is proven. Rather than trusting a reading of the source, the larger ports are tested differentially: the published upstream program and the Swift port run against the same inputs and their outputs are compared after normalising run-specific values. Fixtures come from executing upstream code itself — Python oracles for Guardrails and Harmony, Node scripts that call the npm package's own modules, a Go reference for the CLI (942 cases recorded identical), recorded Python runs for Swarm, evals and the Cookbook. Where upstream ships its own test suite (the Codex plugin, the Codex Action), that suite is run against the Swift binary.

Codex Security is the deepest example. Its Swift CLI covers every upstream command of @openai/codex-security 0.1.31 and is checked by 14 differential suites (as of 30 Sept 2026: scan 35, config 40, history 29, severity 27, owners 28, feedback 21, policy 51, compare 43, dashboard 9, patch 124, publish 108, multiscan 70, dedupe 84, serve 63 cases). The same stand-in Codex, real plugin and real workbench sit under both CLIs; command lines, prompts, environment, artifacts, Git state, HTTP traffic and exit codes must match. Interactive features are checked too: a pseudo-terminal driver types keys while a small terminal emulator compares the rendered screens, colours included — covering the scan dashboard's cost-limit prompt and the post-scan patch review screen, which upstream draws with React/Ink and the Swift port lays out itself.

The audience is Swift developers and Apple-platform teams who want OpenAI's agents, voice and Codex tooling natively, and engineers interested in how to verify a large AI-assisted port. A typical journey: add the OpenAI package to an app and call the Responses API with typed Swift models and AsyncThrowingStream; move up to OpenAIAgents for tools and handoffs; or run codex-security scan . on a repository, watch the live terminal dashboard, review findings with scans show, and patch them with scan --patch.

The project is candid about limits. Each package's Provenance/ record names the upstream commit last reconciled and lists deviations: WebRTC is not ported (not in Apple's SDKs); some YAML 1.1 project files are rejected; PDFs are read with PDFKit rather than pdf.js; version strings differ. Upstream moves quickly, so staying current is ongoing work.

Modules (what a visitor could see or try)

Authored (Swift) vs dependency: all package code is authored here; Apple frameworks (SwiftUI, AVFoundation, PDFKit, Metal, Network), the real codex binary, the upstream Codex Security plugin and Python workbench (run unchanged), and Node/Python only for test oracles are dependencies.

• OpenAI — generated REST client, streaming, Realtime transport (library; nothing visual).
• OpenAIAgents / OpenAIGuardrails / Swarm — agent frameworks and CLIs.
• Realtime family — SwiftUI apps: RealtimeConsole, RealtimeAgentsDemo, VoiceAgentSample client, VoiceControl widgets (visual + microphone audio).
• ChatKit — native ChatKitView and a ChatKit.js web view; starter and sample apps.
• AppsSDK — WidgetGallery app hosting Apps SDK widgets.
• OpenAIHarmony / GPTOSS — HarmonyPlayground SwiftUI app; Metal inference engine; chat CLIs.
• CodexSecurity — codex-security CLI with terminal scan dashboard and patch review screen (visual, terminal).
• CodexSDK / CodexPluginCC / CodexAction — libraries and CLIs.
• SimpleEvals / OpenAIEvals / Cookbook / OpenAICLI / GPTOSSSafeguard — CLIs.

Technical foundations

Swift Package Manager, Swift concurrency (async/await, AsyncThrowingStream); code generation from specs/openapi/openapi.json (swift run -c release openai-codegen) and from the Codex app-server protocol schema (CodexCodegen); hand-written ports of JavaScript semantics where outputs must match byte-for-byte (WHATWG URL parser, JavaScript trim/Number()/regex meanings, YAML 1.2 parser matching the npm yaml package, incur/zod argument handling); subprocess management via posix_spawn. Test tooling: differential harnesses in each package's conformance/, tty_session.py (pty key driver) and vtscreen.py (screen emulator) in CodexSecurity/conformance/.

Maturity (by evidence; "unknown" where not established)

Release status: not released. Pushed 30 Sep 2026 to a private GitHub repository (entertrainment/openai-swift); no public release, tag or package registry entry.

Limitations and roadmap

Limitations: unofficial and unaffiliated; AI-assisted authorship; upstream changes weekly, so ports drift (Provenance records each package's reconciled commit — e.g. OpenAI reconciled 26 Sep 2026); WebRTC not ported; Codex Security: some non-ASCII URL hosts, YAML 1.1 project files, PDF text spacing (PDFKit) and version strings differ; Windows unsupported; Provenance/CodexSecurity.json is out of date (lists commands now ported). Roadmap (aspirational, not committed): possible public release of one or two showcase packages (CodexSecurity, OpenAI client) with LICENSE/NOTICE, an "unofficial" disclaimer and possibly renamed packages; a write-up of the differential-testing method; keeping ports reconciled with upstream.

FAQs

• Is this OpenAI's official Swift SDK? No. It is an independent port of OpenAI's open-source projects; OpenAI does not maintain or endorse it.
• How do you know the ports behave the same? The main ports are run alongside the published originals on identical inputs, and outputs (including terminal screens) must match; upstream test suites are run against the Swift builds where they exist.
• Can I use it? Not yet publicly — the repository is private and unreleased.
• What's the licence? Each package keeps its upstream licence (Apache-2.0 or MIT), with SPDX headers; upstream copyright notices are retained.
• Was it written by hand? It was built with an AI coding agent (Claude Code) directed by the owner; the verification harnesses are how correctness is established.