README.mdView source

OpenResponses

OpenResponses app icon

SwiftUI developer client for the OpenAI Responses API and the successor to OpenAssistant.

Download on the App Store Swift iOS License

Version 2.6 documentation

The complete v2.5 → v2.6 release dossier covers the full source comparison, What’s New, changelog, technical behavior, upgrade steps, validation, and store/reviewer copy. Its 129-file inventory includes committed work and the September implementation changes.

App Store, checked September 8 (evening Pacific): version 2.6 is live. App Store Connect reports 2.6 READY_FOR_SALE with build 41, the Xcode Cloud run 41 archive of commit 5b270d8, uploaded 12:14 Pacific; the public store lookup carries a release timestamp of 2026-09-09T01:59:47Z (18:59 Pacific). Build 41 is the completed 2.6 source plus the CI-only change in 5b270d8; local build 39 was the same app source. The ASC snapshot below/linked predates the release.

Overview

OpenResponses is a native SwiftUI Playground for OpenAI Responses API. It functions as a mobile developer playground and testing workspace, exposing low-level model parameters, tool execution, token-level streaming data, and raw request visibility without hiding the API behind a custom proxy layer.

  • Target Audience: AI engineers, prompt designers, and developers needing direct client-to-API control.
  • Core Problem Solved: Lack of visibility in standard AI interfaces. OpenResponses exposes raw token counters, network statuses, expandable reasoning summaries for supported reasoning models, and outbound/inbound JSON payloads.
  • Technical Characteristics: Direct client-to-endpoint connections, local document parsing (with Vision OCR), and sandboxed browser automation loops.
  • Feature Tiers:
    • Core Playground: Responses API (Chat, Tool Calling, Vision, Models)
    • Developer Lab: Batch API, Fine-Tuning
    • Legacy Migration: retained Assistant JSON imports
  • Product Lineage: OpenResponses is the active evolution of Gunnar Hostetler’s API-tooling work and supersedes the older OpenAssistant Assistants API client.

Product Snapshot

DimensionDetail
PlatformiOS / iPadOS / macOS Catalyst
LanguageSwift
UISwiftUI
ArchitectureMVVM-S
Primary APIsOpenAI Responses API, Notion API, EventKit, Contacts
StorageKeychain, sandboxed JSON files
App StoreDownload
StatusActive
LicenseMIT

Key Capabilities

  • Direct API Connections: Outbound HTTPS traffic routes directly from the iOS client to OpenAI and Notion endpoints without intermediate proxy servers.
  • Asynchronous SSE Streaming: Uses Swift Concurrency (AsyncThrowingStream) to parse Server-Sent Events line-by-line, dispatching UI updates to the @MainActor to avoid layout race conditions.
  • Realtime Voice WebSockets: Includes Voice Mode using wss:// for bi-directional 24kHz PCM16 audio streaming (Direct BYOK WebSocket mode).
  • Retained Assistant Exports: Import saved Assistant JSON and convert it to Responses presets. The Assistants API shut down on August 26, 2026.
  • Developer Labs: Batch job management with complete output/error exports, plus reviewed text-chat JSONL import and validation for eligible fine-tuning accounts. Current-chat export produces a draft dataset example.
  • Secure Keychain Storage: API keys, Notion tokens, and custom Model Context Protocol (MCP) headers are stored inside the secure iOS Keychain. Request inspection/logging includes targeted credential redaction; keys are transmitted to the relevant service when needed for authentication.
  • On-device Browser Automation: Persistent WKWebView with serialized DOM and screenshot actions, precise element references, cancellation, deadlines, and per-turn limits. Pending computer safety checks pause both tool paths. See browser execution.
  • Local Ingestion & OCR: Extracts text from PDFs using PDFKit and recognizes text in image attachments using the native Vision OCR framework locally on-device.
  • Observability Tools: Includes inline collapsible reasoning panels, live connection monitors, and a Request Inspector rendering raw JSON payloads.

How It Works

The following flowchart outlines the request lifecycle, tool branches, and approval gates:

flowchart TD
    A[Compose request] --> B[Send to Responses API]
    B --> C[Read response events]
    C --> D{Execution owner}
    D -->|Hosted tools| E[OpenAI executes configured tools] --> C
    D -->|Client tool| F[Check enabled handler and execution rules]
    F --> G[Execute and return actual result] --> B
    D -->|Computer safety check| S[Pause for turn-scoped user decision]
    S -->|Allow| G
    S -->|Deny| X[Cancel pending work]
    D -->|Completed| H[Render answer, summaries and artifacts]

Architecture

The codebase separates views from network and system frameworks using the MVVM-S pattern:

flowchart LR
    View[SwiftUI Views] <--->|Observe state| VM[ChatViewModel]
    VM <--->|Request completions| Services[Response runners / OpenAIService / ComputerService]
    Services -.->|Authenticate| Keychain[iOS Keychain]
    Services <--->|API Payload| OpenAI[OpenAI Responses API]

For a detailed layer-by-layer system map and data flow boundaries, see ARCHITECTURE.md.


Core Workflows

The local file conversion and ingestion workflow converts attachments prior to payload transmission:

flowchart TD
    A[Select file attachment] --> B[FileConverterService evaluates extension]
    B --> C{Format?}
    C -->|PDF| D[PDFKit extracts text] --> G[Pack into prompt payload]
    C -->|Image| E[Vision OCR recognizes text] --> G
    C -->|Text| F[Read raw content] --> G
    G --> H[Transmit request payload to OpenAI]

Data Flow

Data boundaries separate on-device storage, Keychain secrets, and third-party APIs:

flowchart TD
    Keychain[(Keychain)] -.->|inject headers| API
    Disk[(Local Disk JSON)] <--->|load/save history| UI[User Interface]
    UI -->|direct HTTPS request| API[OpenAI / Notion APIs]
    API -->|SSE Stream| UI

File Entry Points

ConcernFilesResponsibility
App EntryOpenResponsesApp.swiftInitial bootstrapping and startup migrations.
DI ContainerAppContainer.swiftService locator for dependency injection.
Main UIContentView.swiftNavigation shell and tab container.
Chat ViewChatView.swiftChat rendering and text/attachment inputs.
Chat ViewModelChatViewModel.swiftSession state management, settings, and tool approvals.
OpenAI ClientOpenAIService.swiftPayload assembly and SSE stream parsing.
Keychain StorageKeychainService.swiftSecure credentials management.
Browser AutomationComputerService.swiftSandboxed browser automation and capture loops.
File ExtractionFileConverterService.swiftOn-device file conversions and OCR text recognition.
Notion ClientNotionService.swiftDirect Notion workspace database integrations.

Configuration

The configurations map to UserDefaults (for preferences) or the secure Keychain (for keys).

SettingStorageDefaultRequiredPurpose
OpenAI API KeyKeychain (openAIKey)NoneYesAuthenticates all OpenAI network requests.
Notion TokenKeychain (notionApiKey)NoneNoAuthenticates Notion integration requests.
Model SelectionUserDefaultsgpt-6-astraYesResponses model; Astra, Sol, Terra, and Luna are available in the current catalog.
Reasoning EffortUserDefaultsmediumNoConfigures model-aware effort choices; current models also expose higher efforts where supported.
Web SearchUserDefaultstrueNoToggles OpenAI web search capabilities.
Code InterpreterUserDefaultstrueNoToggles OpenAI sandboxed Python containers.
Computer UseUserDefaultsfalseNoToggles local browser automation tool.
Notion IntegrationUserDefaultstrueNoToggles Notion tool access.
Apple IntegrationsUserDefaultstrueNoToggles Calendar, Reminders, and Contacts access.

September 2026 API refresh

The playground now includes a shared current-model catalog, Astra-compatible reasoning controls, GPT Image 2, current Realtime transcription and voices, opt-in automatic compaction, persisted reasoning, pro reasoning, hosted shell, and deferred function/MCP loading through tool search. Saved presets and earlier supported models remain usable.

Native chat now executes configured function/custom tools, Astra async lookups, programmatic tool calls, and multi-agent responses. Multi-agent uses WebSocket result injection so waiting agents can resume immediately. Read-only calls can overlap; writes run sequentially. Root answers, subagent activity, tool results, and image previews appear in the chat. Interrupted turns preserve known results and mark uncertain outcomes without automatically retrying writes. MCP configuration is available again. These orchestration features apply to current-model foreground requests with Computer Use disabled.

Settings → Model → API Workbench exposes editable requests over HTTP, SSE, and persistent Responses WebSockets. It includes steering, tool-result batches and live injection, full response export, input token counting, standalone compaction, response retrieval/cancellation/input items, and conversation retrieval/items. Examples cover asynchronous functions, custom text tools, programmatic tool calling, hosted shell, image generation, apply patch, and the multi-agent beta. Workbench client tools use actual results supplied by the user; native chat executes its configured tools.

Manual chat compaction preserves the complete returned output window, including opaque items, then replays it on the next turn. It never treats a compaction ID as a response ID. The workbench displays unknown events and exports the complete final response; its on-screen event preview is bounded.

Current API contracts and verification details are recorded in API refresh notes. These are source/build capabilities, not an App Store deployment claim.

Settings coverage: The shared ResponseSettingsRegistry and modern response controls expose saved prompt settings. Request mapping is model-aware: verbosity/reasoning use nested API fields, unsupported sampling is omitted, and preset names remain local metadata. See the technical settings table for current defaults and execution constraints.


Build & Run

Local Setup

  1. Clone the Repository:

    git clone https://github.com/Gunnarguy/OpenResponses.git
    cd OpenResponses
  2. Open in Xcode:

    open OpenResponses.xcodeproj
  3. Requirements:

    • Xcode 16.1 or newer.
    • iOS 17.0+ deployment target.
    • Active OpenAI API key.
  4. Xcode Scheme Variables: Under Xcode Product > Scheme > Edit Scheme... > Arguments, add:

    • OPENAI_API_KEY: API credential.
    • NOTION_API_KEY: Notion token (optional).

Testing

Test TypeCommand / ProcedureExpected Result
Build TargetBuild project in Xcode (Cmd+B)Compilation completes with no errors.
Unit/integration testsUse an available simulator and the command in the validation ledger.Latest implementation run: 294 tests, zero failures.
Secret Scanpython3 scripts/secret_scan.pyCLI tool returns success with no keys detected.
Preflight checkbash scripts/preflight_check.shConfirms Info.plist privacy descriptions are present.

Privacy & Security

OpenResponses operates under a local-first threat model:

  • Network boundaries: The device contacts configured API providers over HTTPS or secure WebSockets. Hosted tools, including MCP, may contact their configured services from OpenAI infrastructure.
  • Keychain Storage: Storing API keys securely in the iOS Keychain.
  • Opt-In Safety Notice: Requires explicit user confirmation prior to sending the first completions payload.

For details, refer to SECURITY.md and PRIVACY.md.


Documentation

DocumentPurpose
2.6 release dossierComplete release documentation and evidence index
ChangelogDetailed categorized 2.5 → 2.6 changes
ArchitectureSystem design, data flow, and service boundaries
SecuritySecret handling, local storage, and release checks
PrivacyData storage, API transmission, and user controls
RoadmapCurrent status, planned work, and known gaps
App Store NotesApp Store metadata, review notes, and release checklist
Case StudyEngineering retrospective and implementation notes
ContributingLocal development setup and contribution guidelines
Release Notes (v2.6.0)Summary of changes, fixes, and updates in version 2.6.0

Roadmap

The completed 2.6 source includes current-model native orchestration, Workbench, voice recovery, hosted MCP discovery, browser/search hardening, full job exports and persistence fixes. Remaining work includes release-candidate distribution, broader physical voice/accessibility/device checks, private MCP OAuth coverage and account-dependent service validation. See the current roadmap and release plan.


License

OpenResponses is released under the MIT License.