OpenAssistant
iPhone
Archived
⚠️ Legacy Application: OpenAssistant targeted the OpenAI Assistants API. The project is archived and maintained for reference and support only. OpenResponses is the active successor line.
OpenAssistant
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.
Project Overview
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.
It managed the objects, not just the chat
Assistants, threads, messages, runs and vector stores were all created and edited from the phone. Everyone else was doing this in a browser.
It asked the server, over and over, whether the run had finished
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.
It converted the files the API would have rejected
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.
OpenResponses replaced it
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.
Legacy Capabilities
Creating and editing assistants
You could make an assistant, change its instructions, switch its model, attach files to it, and delete it, without opening a browser.
- Assistant creation and editing
- Instruction and model configuration
- Attachment and vector-store linking
- Native mobile management UI
Threads, messages, and runs
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.
- Thread creation and reuse
- Run polling and state updates
- Persistent conversation history
- Message rendering in native chat UI
Vector stores and files
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.
- Vector-store lifecycle management
- File uploads and file status views
- Knowledge-base linking
- Assistant-to-store associations
Converting files before they went up
The formats a phone actually produces were converted on the device first, rather than sent as-is and rejected.
- HEIC to compatible image conversion
- RTF to text normalization
- Temporary local preprocessing
- Upload-failure avoidance for mobile file types
A real chat screen, not a web view
Answers rendered as Markdown, history stayed on the device, and switching assistant or thread took a tap. No browser anywhere.
- Rich Markdown rendering
- Persistent local history
- Assistant and thread switching
- Native mobile conversation management
Where it stops
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.
- Legacy API dependency
- Polling-driven mobile lifecycle
- Archived status
- Replaced by OpenResponses
Architecture Overview
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.
View Layer (SwiftUI)
Native screens for assistants, vector stores, chat, and settings
ChatView AssistantManagerView VectorStoreDetailView SettingsView
↕️
ViewModel Layer (State Coordination)
Coordinates polling, selection state, and message updates
ChatViewModel AssistantManagerViewModel VectorStoreManagerViewModel ContentViewModel
↕️
Service Layer (API and Persistence)
Handles Assistants API requests, file preprocessing, and local storage
OpenAIService FileUploadService MessageStore @AppStorage
↕️
Model Layer (Remote Object Shapes)
Codable structures mirroring assistants, messages, threads, runs, and stores
Assistant Message Thread VectorStore
Legacy App Flow
The old workflow centered on stateful remote objects rather than the direct Responses API model used by OpenResponses.
App Initialization
OpenAssistantApp initializes view models, local state, and API configuration before presenting assistants and threads.
@StateObject private var assistantManagerViewModel = AssistantManagerViewModel()`
API Key Management
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 = ""`
Main Navigation
MainTabView separates assistants, vector stores, chat, and configuration into a native tab-based workflow.
TabView { ForEach(Tab.allCases, id: .self) { tab in ... } }`
Remote object operations
ViewModels call OpenAIService to fetch assistants, create stores, upload files, post messages, and launch runs.
assistantManagerViewModel.fetchAssistants()`
Polling and notifications
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)`
Technical Profile
Assistants API v2
The app is built around assistants, threads, messages, runs, files, and vector stores instead of the newer Responses API request model.
SwiftUI and Combine
SwiftUI plus Combine handle the native UI layer and view-model update pipeline.
Local preprocessing
HEIC photos and RTF exports are converted on the device, so what reaches the API is something it will accept.
Archive status
OpenAssistant remains documented here for reference, but the active direct-API client is OpenResponses.
What Carried Forward
Two things from this app are still in use. One of them is not.
Managing it all from the phone worked
Assistants, stores and conversation state could all be handled from a phone. That was not obvious at the time, and OpenResponses assumes it now.
The file conversion was worth keeping
Converting HEIC and RTF on the device before upload survived into later apps, because the problem never went away.
Why it stopped
Four API objects and a polling loop became one request. Nothing about this app was worth carrying across that.
Why Keep This Page Live?
People still have it installed
It is still on their phones. Support, privacy and terms have to keep working whether or not anyone is building on it.
The code still shows how it worked
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.
It makes the handover obvious
Deleting this page would leave OpenResponses looking like it appeared from nowhere.
Support routes still have to work
Archiving an app does not archive the people who installed it.
Legacy Access
Review the archived app
The App Store listing has been removed; the last release was v3.2, from June 2025.
Read the source
The repository is the honest version: assistants, threads, runs and vector stores, as they were actually implemented.
Use OpenResponses for current work
If you are starting something now, start with OpenResponses. Nothing here is maintained.
This one is finished
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