OpenAI for Foundation Models

Inspiration

Apple's Foundation Models framework gives developers one expressive session API for streaming, tools, and typed generation. OpenAI's Responses API exposes a powerful cloud model surface, but integrating it into an Apple app normally means maintaining a separate conversation and tool stack.

OpenAI for Foundation Models closes that gap. It lets Apple-platform developers use an OpenAI model as a Foundation Models LanguageModel, preserving the framework abstractions they already use.

What it does

The Swift package translates Foundation Models transcripts into OpenAI Responses API input and streams semantic response events back through Apple's generation channel. It supports:

streaming text and response metadata;
client-side function tools through ordinary Foundation Models Tool values;
typed generation through strict Responses Structured Outputs;
reasoning effort and reasoning summaries;
image input and OpenAI-hosted web search;
live OpenAI model discovery with conservative capability profiles;
direct API-key authentication for development and relay authentication for shipping apps.

The included iOS 27 reference app provides persistent SwiftData conversations, transcript rehydration, Keychain credentials, searchable model selection, function-tool and guided-output labs, Dynamic Profiles, privacy controls, and an in-app architecture walkthrough.

How it was built

The project is split into two layers:

OpenAIAPI owns the dependency-injectable /v1/responses and /v1/models transport, semantic SSE decoder, request types, strict tool schemas, and error envelopes.
OpenAIForFoundationModels owns transcript translation, reasoning and capability policy, event translation, endpoint security, model catalog behavior, and the LanguageModelExecutor implementation.

Codex with GPT-5.6 was used throughout Build Week to investigate the reference architecture, validate OpenAI and Apple API surfaces, implement the transport and bridge, build the SwiftUI/SwiftData demo, diagnose compiler and runtime failures, write deterministic tests, improve keyboard and model-selection UX, and prepare the open-source release material.

Important engineering decisions included translating semantic Responses events instead of treating the stream as text chunks, keeping store: false by default, persisting conversation state locally, restricting direct keys to the exact official OpenAI HTTPS host, and making model capabilities conservative rather than assuming every catalog entry supports every feature.

Challenges

The hardest problem was preserving the semantics of two streaming systems. Responses emits typed events for text, reasoning, output items, function arguments, completion, usage, and failures; Foundation Models expects stable transcript entry identifiers and correctly ordered generation-channel actions.

Strict tool schemas were another subtle boundary. Optional Foundation Models arguments must become OpenAI-compatible required-and-nullable properties. Error mapping also needed to distinguish real context-window failures from schema errors whose messages merely contained the word "context."

Swift 6 concurrency and SwiftData introduced additional constraints: network values remain Sendable, UI coordination is MainActor-isolated, and managed model objects never cross actor boundaries.

Accomplishments

A working OpenAI-only Foundation Models bridge rather than a renamed routing client.
Semantic OpenAI Responses streaming, function tools, typed output, reasoning, images, web search, usage, cancellation, and model discovery.
A coherent four-tab iOS app, not only a transport proof of concept.
Local-first conversation history and store: false by default.
Exact-host API-key protection, sanitized relay headers, Keychain storage, and redacted public errors.
37 deterministic offline package tests plus a simulator UI test.
Reproducible open-source release checks covering formatting, secrets, machine-specific metadata, package tests, XcodeGen regeneration, and unsigned simulator builds.

How judges can test it

Supported platforms are iOS, macOS, visionOS, and watchOS 27 for the package bridge, with an iOS 27 demo app. The project requires Xcode 27 and Swift 6.2 or newer.

The repository includes a single release-validation command:

export DEVELOPER_DIR=/Applications/Xcode-beta.app/Contents/Developer
./scripts/release-check.sh

That command performs repository hygiene checks, Swift formatting validation, package build and tests, XcodeGen regeneration, and an unsigned iOS Simulator build. The demo can then be opened from Examples/DemoApp/OpenAIDemo.xcodeproj. A development OpenAI key can be saved in Keychain, or a relay can supply the OpenAI credential server-side.

What we learned

Provider adapters are safest when they translate semantic events rather than provider-specific text chunks. Explicit local transcript persistence also makes privacy behavior visible instead of hiding it behind a provider conversation identifier. Conservative capability inference is essential because the Models endpoint exposes identity and ownership but not a complete feature matrix.

What's next

Complete the public repository and 0.1.0 release.
Provide a judge-friendly signed build or TestFlight path.
Track Xcode 27 and Foundation Models API changes through the beta cycle.
Add explicit capability profiles as OpenAI publishes richer model metadata.
Expand live relay and device validation while keeping automated tests credential-free.

Open-source status

The project is prepared under the Apache License 2.0 with a security policy, contribution guide, Code of Conduct, issue templates, CI configuration, release checklist, and complete setup documentation. It is an independent community project and is not affiliated with or endorsed by OpenAI or Apple.

Built With

apple-foundation-models
codex
gpt-5.6
keychain
openai-responses-api
server-sent-events
swift
swift-testing
swiftdata
swiftui
xcodegen