Archived · last release v3.2, June 2025 · Requires iOS 16
Archived native client for the OpenAI Assistants API
OpenAssistant let you create assistants, start threads, upload files and watch runs finish, from an iPhone, at a time when doing any of that meant a browser. It is finished. OpenResponses does this work now, against the API that replaced the one this was built on.
The Assistants API kept the conversation on OpenAI's servers. You made an assistant, then a thread, then a message, then a run, and then you asked repeatedly whether the run had finished, because nothing told you. This app did all of that from a phone, and converted the files iOS produces into formats the API would accept. That is the part worth reading.
Assistants, threads, messages, runs and vector stores were all created and edited from the phone. Everyone else was doing this in a browser.
The API had no way to tell the app when a run finished, so the app kept asking. Getting that to stop cleanly when you left the screen, and not leak while it ran, was most of the work.
An iPhone photo is a HEIC and the API would not take one. Notes exports are RTF, same problem. The app converted them on the device first, so an upload that would have failed just worked.
The Responses API does in one call what the Assistants API needed four and a polling loop to do. Once that existed there was no reason to keep this. OpenResponses is where the work went.
You could make an assistant, change its instructions, switch its model, attach files to it, and delete it, without opening a browser.
A conversation was a thread you created, messages you posted into it, and a run you started over the top. The app showed you that run moving from queued to running to done, which was the only way to know anything was happening.
You could create a vector store, upload documents into it, watch each file finish processing, and attach the store to an assistant so it could answer out of them.
The formats a phone actually produces were converted on the device first, rather than sent as-is and rejected.
Answers rendered as Markdown, history stayed on the device, and switching assistant or thread took a tap. No browser anywhere.
It is built on threads, runs and polling, and it cannot be moved off them without being a different app. That is why it stopped rather than being rewritten.
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.
HEIC photos and RTF exports are converted on the device, so what reaches the API is something it will accept.
OpenAssistant remains documented here for reference, but the active direct-API client is OpenResponses.
Two things from this app are still in use. One of them is not.
Assistants, stores and conversation state could all be handled from a phone. That was not obvious at the time, and OpenResponses assumes it now.
Converting HEIC and RTF on the device before upload survived into later apps, because the problem never went away.
Four API objects and a polling loop became one request. Nothing about this app was worth carrying across that.
It is still on their phones. Support, privacy and terms have to keep working whether or not anyone is building on it.
If you want to see what talking to the Assistants API from a phone actually took, it is all here and it still reads clearly.
Deleting this page would leave OpenResponses looking like it appeared from nowhere.
Archiving an app does not archive the people who installed it.
The repository is the honest version: assistants, threads, runs and vector stores, as they were actually implemented.
View GitHub RepositoryIf you are starting something now, start with OpenResponses. Nothing here is maintained.
OpenAssistant is finished. This page stays up so support, privacy and terms keep working for anyone who still has it. Use OpenResponses for anything new.
Archived for reference • Support routes remain live • OpenResponses is the current successor