iOS: Chat-Hosts, die Collection-View und die Outbox

Sie wählen den Agenten, wenn Sie die Session erstellen #

Das Formular für eine neue Session hat eine Agent-Auswahl. SessionAgent hat genau zwei Werte, codex und claude. Der Agent bleibt für die ganze Lebensdauer der Session, deshalb fragt das Formular vor session.create. Das Formular speichert die Wahl in UserDefaults unter session.newSessionAgent, und vor einer ersten Wahl ist Codex vorausgewählt. Die Auswahl ist deaktiviert, solange eine Anfrage zum Erstellen läuft.

Das Formular listet auch die gespeicherten Unterhaltungen des gewählten Agents für den Projektordner, über run.chatExistingSessions, und zeigt eine davon mit run.chatPreviewExistingSession. Ein Wechsel des Agents lädt die Liste neu. Eine Anfrage session.create mit Schlüssel trägt den Agent und, wenn Sie eine Unterhaltung gewählt haben, deren conversationId, und die neue Session setzt diese Unterhaltung fort. Eine Unterhaltungszeile zeigt ein Modell und einen Client-Namen nur für Codex, weil nur Codex-Threads sie melden.

Danach nutzt eine Claude-Session denselben Chat-Host, dieselben Zeilen und dieselben run.chat*-Methoden wie eine Codex-Session. Der Code des Telefons verzweigt nur an wenigen Stellen nach dem Agent.

Die App hält bis zu sechs Chat-Hosts im Cache und zeigt einen #

WorkspaceChatHostCache behält die View-Models kürzlich besuchter Chats, geordnet nach Desktop, Projektordner und Session, und hält höchstens sechs. Die Auswahl eines Chats während eines SwiftUI-Renderings merkt seinen Eintrag nur vor, und die Aufgabe der Auswahl übernimmt ihn danach, sodass der Cache nie mitten in einer View-Aktualisierung eine Änderung veröffentlicht. Nur der ausgewählte Host ist eingehängt.

Jeder Host besitzt einen Scheduler für das neueste Fenster mit einer aktiven Operation und einer ausstehenden Anfrage für sein aktuelles Ziel. Anfragen werden zusammengefasst, und ein Snapshot wird nur angewendet, wenn sein Ziel und die erfassten Zäune noch passen. Ein geparkter Host behält seine Zeilen und sein Live-Overlay, und sein Scheduler startet nichts, bis der Host wieder ausgewählt und aktiv ist. Scroll-Position und Aufdeckungszustand gehören zur nicht eingehängten View, daher kehrt er am Ende hinter einer kurzen Abdeckung zurück. Die iPhone-App hat keinen Batch-Abgleich und lädt keinen Chat, den Sie gerade nicht ansehen.

Ein beendeter, gescheiterter, abgebrochener oder gestoppter Run, eine Desktop-Wiederherstellung, die Rückkehr in den Vordergrund, ein anderer gewählter Desktop, eine ausdrückliche Aktualisierung, die erneute Auswahl des Chats und ein neueres updatedAt der Session markieren das gewählte Ziel als veraltet und können sein Laden einreihen. Solange der Chat auf dem Bildschirm bleibt, lädt er außerdem etwa alle 60 Sekunden das neueste Fenster, oder alle 10 Sekunden, solange ein Run, eine Nachricht oder ein Laden aussteht, und auf jede Wartezeit kommen bis zu 30 Prozent hinzu. Dieses regelmäßige Laden läuft nur, wenn die App aktiv ist, der Desktop eine Anfrage annehmen kann, das Relay sich nicht neu verbindet, kein Laden aktiv ist oder aussteht, keine ältere Seite lädt und die Timeline keine leere ist, die der Desktop noch nicht bestätigt hat. Ein gescheitertes Laden lässt die sichtbaren Zeilen, wie sie sind, und markiert den Host für ein frisches Laden bei seiner nächsten Aktivierung. Subagent-Threads öffnen sich in einem eigenen Viewer mit einem separaten View-Model, das über run.chatLoadThread und run.chatLoadThreadPageBefore lädt.

Die erste Seite hat 12 Zeilen, eine ältere Seite 100. Ein gescheitertes erstes Laden wird bis zu 3 Mal wiederholt. Die Wartezeit beginnt bei 0,75 Sekunden, verdoppelt sich mit jedem Versuch, schwankt um 20 Prozent in beide Richtungen und überschreitet nie 3 Sekunden. Zwei Neuladevorgänge desselben Chats starten mindestens 2 Sekunden auseinander.

Der Verlaufsumschlag wird exakt dekodiert #

WorkspaceChatLoadEnvelope verlangt genau die kanonische Menge an Schlüsseln auf oberster Ebene. Mehrere Felder müssen vorhanden sein, auch wenn ihr Wert null ist. Der Decoder prüft ein nicht leeres boundaryToken und dekodiert Timeline-Blöcke über den gemeinsamen Seitendecoder. Jede Zeile braucht einen type aus user, system, activity, agent-reply und thinking, eine nicht leere id, einen origin von canonical oder live, ein nicht leeres sourceOrder aus vorzeichenlosen Ganzzahlen und einen ganzzahligen timestamp. Live-Zeilen brauchen eine runId, und Live-Nutzerzeilen brauchen eine operationId. Ein doppelter Splice-Schlüssel lässt die ganze Seite scheitern.

boundaryToken: nonblank string
nativeSessionId: string | null
loadState: typed load state
storageFormat: "indexed" | "native"
loadedEntries: integer
hasOlderEntries: boolean
oldestCursor: string | null
timeline: typed blocks[]
liveOverlay: { settlementEpoch, revision, blocks }
runtime: object | null
activeRun: object | null

Der Live-Overlay-Decoder erfordert exakte ganzzahlige Epochen- und Revisionswerte innerhalb des sicheren JavaScript-Bereichs. Eine Revision von null kann keine Blöcke enthalten. Jeder Overlay-Block muss den Ursprung live haben, und typisierte Blockidentitäten müssen eindeutig sein. Das Zurückweisen eines ungültigen Envelopes verhindert, dass fehlerhafte Daten zu einem scheinbar gültigen leeren Verlauf werden.

Ein Snapshot wird auf einen neueren Live-Zustand angewendet #

Ist die Historie nicht verfügbar, bleiben das sichtbare Fenster und die Paginierung erhalten, und nur ein Overlay aus derselben Epoche wird angewendet. Danach werden Outbox-Einträge und Echos mit der bestätigten Historie abgeglichen, die Timeline-Revision steigt, wenn sich etwas geändert hat, und ein Aktualisieren, das ein nicht leeres Fenster durch Zeilen ohne Überschneidung ersetzt, rückt die Darstellungsepoche vor.

Eine UIKit-Collection-View in SwiftUI #

Die Timeline ist eine UICollectionView in einem UIViewRepresentable. Sie nutzt ein Compositional Layout mit einer vertikalen Section und geschätzten Höhen von 80 Punkten, eine Diffable Data Source, deren Elemente Zeilen-ID-Strings sind, und Zellen, deren Inhalt eine UIHostingConfiguration um die SwiftUI-Zeile ist. Die Invalidierung der Selbstgröße schließt Constraints ein, sodass eine wachsende Zeile neu gemessen wird. Der Chat-Tab baut die Anzeigezeilen aus den Zeilen des View Models: Thinking-Zeilen verlassen die Liste, und das Live-Thinking des aktiven Runs wird zum angehefteten Status. Der Desktop sendet keine Zeile für einen Subagent oder einen Workflow. Die Collection selbst fügt nie eine Nachricht hinzu und lässt nie eine weg.

Änderungen am Live-Overlay erreichen SwiftUI höchstens sechsmal pro Sekunde, oder zweimal pro Sekunde, solange der Composer oder eine Vorschau offen ist, und während eines Ziehens bleibt nur die neueste zurückgehaltene Aktualisierung erhalten.

Erste Anzeige, ältere Seiten und das Folgen am unteren Ende #

Die Abdeckung fällt nach etwa zwei Sekunden, auch wenn das Layout nie stillhält, und ein kurzer Verlauf lädt darunter zuerst bis zu zwei ältere Seiten. Die Darstellungsepoche verbindet die Session mit einer Timeline-Identität pro Viewport, parent-chat oder subagent-<thread ID>. Sie rückt vor, wenn ein Aktualisieren das Fenster durch Zeilen ohne Überschneidung ersetzt, wenn ein leerer, unbestätigter Chat ein frisches Laden startet oder wenn der Thread wechselt, sodass Scroll-Annahmen eines Fensters nie in ein anderes übergehen.

Ältere Seiten laden, wenn Sie bis auf 1.800 Punkte an den Anfang scrollen, höchstens alle 0,25 Sekunden, und ein Ladevorgang gilt nach 8 Sekunden als veraltet. Bevor Zeilen vorangestellt werden, merkt sich die Ansicht die erste sichtbare Zeile und ihren Offset, und nach der Aktualisierung scrollt sie diese Zeile zurück an ihren Platz und stellt den Offset wieder her. Live-Zeilen werden bis zu 1,5 Sekunden zurückgehalten, solange die Wiederherstellung läuft, damit eine streamende Antwort die Zeilen, die Sie lesen, nicht verschiebt.

Das Folgen am unteren Ende läuft auf einem CADisplayLink. Die Geschwindigkeit ist die verbleibende Strecke geteilt durch 1,5 Sekunden, begrenzt auf 80 bis 2.200 Punkte pro Sekunde, und mit aktivierter Option „Bewegung reduzieren“ springt die Ansicht stattdessen. Einrastdurchläufe laufen alle 32 Millisekunden, oder 350 Millisekunden nach einem animierten Scrollen, und enden nach zwei stabilen Durchläufen innerhalb von 1 Punkt und einem halben Punkt Höhenänderung oder nach acht Durchläufen.

Die schwebenden Bedienelemente stehen auf einer unteren Linie, in der Haupt-Timeline und im Thread-Viewer: das Menü, Scroll to latest, Stop und Switch desktop. WorkspaceChatBottomChrome besitzt diese Linie. Jedes Bedienelement ist 52 Punkte breit, 16 Punkte vom Bildschirmrand und 10 Punkte von seinem Nachbarn entfernt. Die Unterkante jedes Bedienelements liegt 57 Punkte über dem unteren sicheren Bereich. Die Run-Uhr und der angeheftete Status liegen unter der Linie und nehmen ihr keinen Platz, und die letzte Zeile der Timeline liegt 125 Punkte über dem sicheren Bereich. Das Menü, Scroll to latest und Switch desktop haben eine gemeinsame Fläche, WorkspaceFloatingControlFace: die schwebende Farbe mit 94 Prozent, einen Schimmer im dunklen Modus und einen Schatten. Der geschlossene Menüknopf zeigt ein einziges Badge: die Zahl der wartenden Nachrichten, solange die Warteschlange welche hat, sonst die Zahl der aktiven Sub-Agents. Sein VoiceOver-Label nennt beide Zahlen.

Die Kopie der Outbox auf dem Telefon #

Die Zustellung gehört dem Desktop. Das Telefon hält eine Wiederholungsmenge in UserDefaults unter workspace-chat-local-outbox-v2, wobei jeder Session-Bereich seine Operationsreihenfolge speichert und jede Operation entweder als ausstehend, mit dem vollständigen Eintrag, oder als abgeschlossen. Eine abgeschlossene Operation sperrt veraltete Schreiber für den Rest des Prozesses aus und wird beim nächsten Start, der eine neue Generation beginnt, entfernt.

Outbox-Änderungen einer Session laufen als serielle Kette. Eine Übermittlung wartet 20 Sekunden auf die Quittung des Desktops. Eine endgültige Ablehnung legt den Text zurück in den Composer, wenn sich der Entwurf wiederherstellen lässt.

Anhänge werden vor der Nachricht hochgeladen. Der Desktop gibt eine Upload-ID und eine Blockgröße zurück, das Telefon begrenzt Blöcke auf 1 MiB und kodiert sie in Base64, und die Aufrufe verwenden die Schlüssel <upload key>:begin, :chunk:<n>, :finish und :cancel. Der Upload-Schlüssel ist files.chatAttachmentUpload:<session>:, gefolgt von einem 64-Bit-FNV-1a-Hash aus Session, Projekt, Dateiname, MIME-Typ, Pfad und Größe, sodass ein erneuter Versuch mit derselben Datei dieselben Schlüssel verwendet. Dateien dürfen bis zu 1 GiB groß sein, und ein PNG wird als JPEG mit Qualität 0,88 neu kodiert, wenn sein dekodiertes Bild höchstens 64 MiB braucht.

Das Warteschlangen-Sheet und das Zurückhalten durch den Desktop #

Das Warteschlangen-Sheet listet die Einträge des offenen Chats, die in der Warteschlange stehen, Text oder Anhänge haben und zum Thread auf dem Bildschirm gehören. Ein Eintrag, der gerade gesendet wird, steht nicht im Sheet. Jede Zeile zeigt den Status, die Beschriftungszeile einer Nachricht aus einer anderen Session in den Wörtern des Desktops, den Text, Modell und Reasoning-Effort einer gespeicherten Auswahl, die Anhänge, den Grund des Zurückhaltens und den Fehler.

Die drei Mutationen brauchen einen Idempotenzschlüssel, und run.chatOutboxLoad liest die Warteschlange. Ein Ziehen endet von selbst nach 8 Sekunden, und 2 Sekunden nachdem es die Liste verlassen hat. Ändern sich die Einträge unter einem Ziehen, wird es abgebrochen.

Der Desktop kann einen Eintrag zurückhalten und den Grund in holdReason nennen. Das Telefon setzt dieses Feld nie und behandelt es nicht als Fehler. Die Zeile zeigt den Grund als zweite Beschriftung unter dem Text. Sofort senden ist ein Submit mit dem Intent automatic, und der Desktop wertet jeden Intent außer enqueue als Ihre Freigabe einer zurückgehaltenen Nachricht aus einer anderen Session. Eine Bearbeitung entfernt die Angabe message und den Grund des Zurückhaltens. Der neue Eintrag hat eine neue Operations-ID, und sein Prompt-Text ist der bearbeitete Text, sodass der Agent ihn als Ihre eigene Nachricht bekommt.

Eine angenommene Steuerung und „Stop and send now“ #

Eine Nachricht, die Sie während eines Runs senden, ist eine Steuerung für den aktiven Run, in einer Codex-Session und in einer Claude-Session. Die Abbildung zeigt eine Codex-Session. Der Desktop-Snapshot der Outbox besitzt den Zustand „angenommen“, die lokale Wiederholungsmenge nicht. Das View-Model behält die letzten Desktop-Einträge jeder Session und sucht den Eintrag über die Operations-ID, wenn es die ausstehende Nutzerzeile baut.

Die Aktion wird nur angeboten, solange der angenommene Run der aktive Run ist. Ein Wechsel des aktiven Runs veröffentlicht eine neue Outbox-Revision, wenn ein angenommener Eintrag den alten oder den neuen Run nennt, und so verschwinden Beschriftung und Aktion aus der Zeile. Das Telefon verfolgt den aktiven Turn nicht. Es sendet die Turn-ID, die der Desktop ihm gegeben hat, und der Desktop vergleicht sie mit dem Turn, der wirklich läuft.

Eine Anfrage, der eine ihrer sechs Identitäten fehlt, wird auf dem Telefon abgewiesen, bevor etwas gesendet wird. Die Phase einer Operation bleibt im Speicher. Nach „Not confirmed“ bietet die Zeile keinen zweiten Versuch für diese Operation an. Nach einem Fehler lädt das Telefon außerdem die Desktop-Outbox neu.

Nachrichten aus anderen Sessions #

Ein Agent in einer Session kann eine Nachricht an eine andere Session desselben Desktops senden, und Agenten in einer Session senden einander Nachrichten. Das Telefon kann eine solche Nachricht nicht erzeugen. Es zeigt die Angabe message, die der Desktop an die Zeile hängt. WorkspaceChatMessageBand zeigt jede Nachrichtenzeile: die Beschriftungszeile mit den beiden Enden, zum Beispiel „This session → Fix tests“ oder „API review → This session“, das Signal Sent, Needs approval oder Not sent und den Text als Markdown. Der Desktop entfernt den Umschlag, daher ist der Zeilentext nur die Nachricht.

Der Decoder ist streng. Eine Angabe message mit einem Wert, den dieser Build nicht kennt, oder mit einem leeren Wort lässt das Dekodieren scheitern. Das Telefon erzeugt keine eigenen Wörter: Der Zeilentitel, die beiden Enden und „Untitled session“ kommen vom Desktop. Die Leitung trägt für eine Nachrichtenzeile kein detail. Ein Tippen auf das Band öffnet das Nachrichtendetail, das das Telefon aus dem Zeilentitel, der Angabe und dem Text baut. Das Detail behält die Zeilenumbrüche des Absenders.

Wenn die Angabe einen Link hat und der Chat im Workspace ist, ist der Name des anderen Endes in der Beschriftungszeile der Link. Er hat die Linkfarbe, das Agentenzeichen des anderen Endes und eine Tippfläche von mindestens 44 Punkten. VoiceOver öffnet mit der Standardaktion das Detail, und die benannte Aktion „Go to <peer>“ folgt dem Link. WorkspaceMessageJumpModel zeigt die Session und den Thread des anderen Endes. Der Chat dieser Stelle nimmt den Anker einmal und lädt das Fenster um die Zeile. Die Collection-View setzt die Zeile in die Mitte des Bildschirms und markiert sie. Sie hält die Zeile in jedem Layout-Durchlauf in der Mitte, bis Sie ziehen, auf die Statusleiste tippen oder der Chat einen anderen Scroll-Befehl bekommt. Es gibt kein Zurück-Bedienelement: Der Weg zurück ist der Link auf der Zeile am anderen Ende. Im Nachrichtendetail schließt derselbe Link zuerst das Detail und folgt dann dem Link.

Ein Fenster mit einem newerCursor ist eine Seite in der Vergangenheit. Solange eine solche Seite sichtbar ist, lädt jedes Neuladen der Timeline dieselbe Seite erneut mit einem Zeilenanker an ihrer Zeile, auch nach einem Abgleich, einer Lücke im Relay oder dem Ende eines Runs. Die Aufdeckung bleibt, daher bewegen sich die Zeilen nicht, und keine Zeile bekommt eine neue Markierung. Das Telefon übernimmt das activeRun mit dem Wert null einer Seite in der Vergangenheit nicht, daher bleibt Stop sichtbar, solange ein Run aktiv ist. Ein Hinweis des Desktops, zum Beispiel „This message is not in the saved history.“, erscheint über der Timeline.

Tests, die dieses Verhalten festhalten #

• WorkspaceChatTimelineSnapshotOrderingTests: Nur die aktive Operation darf ihren Snapshot anwenden, und eine geänderte Zielgeneration weist eine frühere ab.
• WorkspaceChatTimelinePaginationReloadTests: Ein Wiederherstellungs-Neuladen behält die Zeilen, bis sein Snapshot angewendet ist, und ein ausstehendes Neuladen übersteht einen vorübergehenden Verbindungsverlust.
• WorkspaceChatLiveTimelineConfirmationTests: Eine Live-Zeile wird nur über eine gemeinsame typisierte Identität abgeschlossen, nie über übereinstimmenden Text oder Zeitstempel.
• WorkspaceChatMessageLinkRoundTripTests: Jeder Link landet genau auf der Zeile in der Mitte einer Seite in der Vergangenheit, zwischen zwei Sessions und zwischen der Haupt-Timeline und einem Agent-Thread.

Diese Suiten liegen in VibeUITests, das in der App gehostet läuft, deshalb brauchen sie ein iOS-Simulator-Ziel. Verhalten auf echten Geräten, etwa die erste Anzeige mit gespeichertem Markdown-Verlauf, wird weiterhin von Hand geprüft.