Archived native client for the OpenAI Assistants API
OpenAssistant brought assistants, threads, runs, vector stores, and mobile file preprocessing to iPhone and iPad in a native SwiftUI client. It remains useful as a record of the older Assistants API product line, but new work now happens in OpenResponses on top of the newer Responses API.
OpenAssistant is kept here as the legacy mobile client for the older OpenAI Assistants API workflow. The interesting part is not generic AI marketing. It is the combination of native SwiftUI UI, local file preparation for mobile formats, vector-store management, and polling around a stateful server-side thread-and-run model.
OpenAssistant managed assistant objects, threads, messages, runs, and vector stores from a native mobile client instead of forcing everything through a web console.
Because the Assistants API used queued and in-progress server-side runs, the app relied on memory-safe polling and state sync to keep the UI current.
HEIC images, RTF documents, and other mobile-originating files were normalized on device before upload so the API could accept them.
This line is archived. OpenResponses is the active client for the modern OpenAI Responses API and the place where ongoing product work now happens.
The app could create, edit, inspect, and delete Assistants API objects, along with their instructions, model selections, and attached knowledge resources.
OpenAssistant wrapped the older stateful conversation model, allowing users to create threads, post messages, launch runs, and watch run state transition from queued to completed.
The app exposed vector store CRUD, document uploads, and assistant-store associations so retrieval-backed assistants could be configured from mobile.
Instead of sending raw unsupported mobile formats upstream, the app converted or normalized files on device before transmission.
The front end gave mobile users a native place to talk to their assistants, browse history, and inspect results without dropping into a browser workflow.
The project is useful as a historical reference, but it remains tied to the Assistants API model of threads, runs, and polling, which is why it no longer represents the main product direction.
OpenAssistant used an MVVM-style SwiftUI architecture to bridge native UI state with a stateful remote API built around assistants, threads, messages, runs, files, and vector stores.
Native screens for assistants, vector stores, chat, and settings
Coordinates polling, selection state, and message updates
Handles Assistants API requests, file preprocessing, and local storage
Codable structures mirroring assistants, messages, threads, runs, and stores
The old workflow centered on stateful remote objects rather than the direct Responses API model used by OpenResponses.
OpenAssistantApp initializes view models, local
state, and API configuration before presenting assistants and
threads.
@StateObject private var assistantManagerViewModel =
AssistantManagerViewModel()
The app stores the OpenAI API key locally and prompts the user before any remote API interaction can happen.
@AppStorage("OpenAI_API_Key") private var apiKey: String =
""
MainTabView separates assistants, vector stores,
chat, and configuration into a native tab-based workflow.
TabView { ForEach(Tab.allCases, id: \.self) { tab in ... }
}
ViewModels call OpenAIService to fetch assistants,
create stores, upload files, post messages, and launch runs.
assistantManagerViewModel.fetchAssistants()
Polling plus NotificationCenter are used to keep
the UI in sync with queued and in-progress run state.
NotificationCenter.default.post(name: .settingsUpdated,
object: nil)
The app is built around assistants, threads, messages, runs, files, and vector stores instead of the newer Responses API request model.
SwiftUI plus Combine handle the native UI layer and view-model update pipeline.
Mobile-originating file formats are normalized locally before upload so the API receives compatible inputs.
OpenAssistant remains documented here for reference, but the active direct-API client is OpenResponses.
The main value of OpenAssistant now is what it demonstrated and what the next product generation learned from it.
OpenAssistant proved that assistants, stores, and chat state could be managed from a mobile-native interface instead of a web-only workflow.
The local preprocessing pipeline for HEIC, RTF, and other mobile formats carried forward as a useful design lesson.
The old Assistants API lifecycle was heavier and more stateful than the newer direct Responses API model, so the active line moved to OpenResponses.
Support, privacy, and App Store history still matter for users who installed the legacy app.
The page still documents how a native SwiftUI client handled the stateful Assistants API model on mobile.
It makes the difference between OpenAssistant and OpenResponses visible instead of hiding the product transition.
Existing users still need working support, privacy, and terms routes even after a product line is archived.
The App Store listing remains part of the public record for the older OpenAssistant line.
View on App StoreThe GitHub repository is the clearest place to inspect the old assistants, threads, runs, and vector-store implementation.
View GitHub RepositoryIf you are evaluating current API-tooling work, start with OpenResponses rather than building on this archived line.
OpenAssistant remains online as a support and reference surface. OpenResponses is the active path for current OpenAI API tooling.
Archived for reference • Support routes remain live • OpenResponses is the current successor