Wie wir Lispr entwickelt haben — eine Mac-App für Sprache-zu-Text in 21 Tagen
Die Architektur, die Latenzberechnungen und die KI-gestützte Entwicklungsmethodik hinter Lispr – einer 4 MB großen Mac-App für Spracherkennung, die in nur 21 Tagen fertiggestellt wurde. ~300 ms Latenz, 99 Sprachen, kein Account erforderlich.
Was wir geliefert haben. Eine native macOS-Diktier-App, die Text in jeder Anwendung direkt an der Cursorposition einfügt. Eine wahrgenommene Latenz von unter 300 ms in instabilen Mobilfunknetzen. 40 UI-Sprachen vom ersten Tag an. Ein Datenschutzkonzept, bei dem standardmäßig keine Audiodaten gespeichert werden.
Warum dieses Projekt Teil unserer Fallstudien ist. Die komplexen Herausforderungen hinter Lispr entsprechen genau den Problemen, die wir in Kundenprojekten lösen. Latenzoptimierung bei cloudbasierten Pfaden. Mehrsprachige Produktion in großem Maßstab. Edge-Architektur trotz geobedingter Einschränkungen durch Provider. Release-Engineering mit der nötigen Disziplin, um 67 notariell beglaubigte Builds in drei Wochen auszuliefern.
Live in der Produktion. 46.011 Diktate und über 1,1 Millionen Wörter in 29 Ländern innerhalb der ersten drei Wochen – vorwiegend von Nutzern, deren Sprachen von Apple Dictation und Apple Intelligence noch nicht ausreichend abgedeckt werden.
Das Bereitstellungsmodell. Die Ingenieure von Codebridge leiteten jeden Arbeitsbereich gemeinsam mit KI-Agenten, die Code-Reviews, Lokalisierungs-Flotten und Wettbewerbsanalysen übernahmen. Dasselbe Modell, das wir bei Kundenprojekten anwenden, hier durchgängig demonstriert an einem eigenen Produkt.
Strategischer Kontext
Die mehrsprachige Lücke
Die Diktierfunktion von Apple vernachlässigt Nutzer, deren Muttersprache nicht Englisch ist. Apple Intelligence schließt Ukrainisch und die meisten Sprachen, die von der Lispr-Nutzerbasis verwendet werden, aus. Der Datenschutz ist der zweite entscheidende Faktor. Lispr erfasst ausschließlich Audio, ohne Screenshots, ohne Konto und standardmäßig ohne Datenspeicherung.
Warum wir es intern entwickelt haben
1. Eine echte Produktwette auf die mehrsprachige Lücke, finanziert aus unserer eigenen Bilanz.
2. Eine öffentliche Demonstration des KI-gestützten Bereitstellungsmodells von Codebridge an einem Projekt, das wir von Anfang bis Ende selbst verantworten.
3. Eine Testumgebung für technische Praktiken, die wir bei Kundenprojekten anwenden und die wir an unserem eigenen Produkt validieren, bevor wir sie weiterempfehlen.
Erfolgskriterien beim Projektstart
Cursor-Einfügung in jeder Anwendung. End-to-End-Reaktionszeit unter einer Sekunde. Kein Konto, keine E-Mail-Adresse, keine Zahlungsabwicklung. Von Anfang an mehrsprachig. Eine kleine, native, signierte Binärdatei mit automatischer Aktualisierung.
Die Herausforderung
Fünf Rahmenbedingungen bestimmten die architektonischen Entscheidungen.
Die Latenzuntergrenze. Der herkömmliche Weg (Datei aufnehmen, per POST an einen Whisper-Endpunkt senden, auf Antwort warten) dauert 1500 bis 2500 ms. Das Ziel war ein Prozess, der sich durchgehend unmittelbar anfühlt – schnell genug, damit der Nutzer im Redefluss bleibt, anstatt auf die Maschine zu warten.
Keine „Überall-tippen“-API unter macOS. macOS bietet keinen Systemdienst oder eine Erweiterung, die gleichzeitig Audio aufzeichnet und Text in beliebige Anwendungen einfügt. Wir haben die Erfassungsoberfläche aus CGEventTap, Carbon-Hotkeys und synthetisierten Tastatureingaben zusammengesetzt. Es gab keine fertige, integrierte Lösung.
Feindselige Netzwerke. Mobile Hotspots verwerfen QUIC- und UDP-Pakete, ohne eine Fehlermeldung auszugeben. Der ASR-Anbieter blockiert ganze Regionen geografisch. Der Transportweg musste in Netzwerken funktionieren, die zwar verbunden scheinen, aber Pakete verlieren, und Nutzer in Ländern erreichen, die der Anbieter nicht bedient.
Vierzig Sprachen vom ersten Tag an. Der Standardweg über menschliche Übersetzungsverträge pro Sprache kann mit einer Frequenz von mehreren Releases pro Tag nicht mithalten und liefert keine Qualitätsrückmeldungen in den Build-Prozess zurück. Wir benötigten eine breite Abdeckung ab dem Start mit überprüfbarer Qualität und einem geschlossenen Feedback-Kreislauf für die Transkription.
Vertrauen ohne Benutzerkonto. Nutzer laden Lispr herunter und diktieren. Sie müssen sich nicht registrieren. Die Binärdatei enthält keine API-Schlüssel. Standardmäßig speichern wir kein Audio. Das Vertrauensmodell musste technischer Überprüfung standhalten, ohne dass Nutzerdaten erhoben werden.
Umfang der Arbeit
Push-to-Talk-Aufnahme-Engine
Ein „Listen-only“-CGEventTap erkennt gedrückte Modifikatortasten systemweit. Eine Zustandsmaschine für Gesten steuert Interaktionen wie Halten, Doppeltippen mit Einrastfunktion und schnelles Tippen. Die History-Tastenkombination wird über Carbon RegisterEventHotKey realisiert. Lispr läuft als schlanke, native macOS-App mit Dock-Icon und Menüleisten-Präsenz. Da macOS keine Möglichkeit für eine Eingabemethode bietet, die Audio aufzeichnet und in beliebige Apps schreibt, haben wir den Weg über eine Tastaturerweiterung von Anfang an ausgeschlossen. Die Erfassungsoberfläche basiert auf nativen Primitiven.
Pipeline für Streaming-Transkription
Der Client kodiert PCM bei jedem ~64-ms-Puffer in Opus (24 kbit/s, 20-ms-Pakete, Ogg-Framing mit CRC32-Selbsttest) und streamt dies während der Aufnahme über einen chunked URLSession-Upload hoch. TLS wird bei Tastendruck vorgewärmt. Eine gemeinsam genutzte Singleton-URLSession hält die Verbindungen aktiv. Wir haben den gesamten Request-Pfad instrumentiert, bevor wir Optimierungen vorgenommen haben. Cloudflare puffert den Client-zu-Worker-Body vollständig, bevor worker.fetch() ausgeführt wird (der Body ist 0 bis 2 ms nach dem Loslassen der Taste verfügbar, selbst bei 26-sekündigen Clips). Das hat uns gezeigt, dass der Latenzvorteil im clientseitigen Streaming liegt und nicht im Worker.
Geo-basiertes Edge-Relay
Der Worker ruft zuerst direkt das vorgelagerte ASR auf. Bei einem regionalen 403-Fehler erfolgt ein Fallback auf ein Durable Object, das per locationHint an Sydney gebunden und zuvor durch Benchmarks ausgewählt wurde. Wir verwenden cf.colo als Schlüssel für den Trigger, da der Anbieter ausgehenden Datenverkehr anhand von IP-Adressen und nicht nach Nutzerstandorten blockiert. Nutzer in nicht blockierten Rechenzentren haben keinerlei Performance-Einbußen.
Mehrsprachigkeits- und Vokabularebene
Eine zentrale englische Master-Datei speist KI-Übersetzungs-Agenten für jede Sprache. Ein separater Reviewer-Agent pro Sprache bewertet das Ergebnis. Ein Generator erstellt .lproj-Bundles sowie vorgerenderte Marketing-Seiten mit englischem Fallback. Der Worker verarbeitet benutzerdefinierte Vokabulare in einem dedizierten Cloudflare-Container (Python mit lingua, wordfreq und MeCab) außerhalb des kritischen Pfads und wendet diese anschließend auf die Transkription an. Die Sofortübersetzung erfolgt über gpt-oss-120b.
Ebene für Vertrauen, Updates und Observability
Jeder Build durchläuft Apples Notarisierung und Stapling. Updates werden über Sparkle mit einem EdDSA-signierten Appcast und einer SHA-256-Integritätsprüfung für den Download bereitgestellt. Die Analytics Engine erfasst Telemetriedaten, die über ein internes Dashboard hinter Cloudflare Access visualisiert werden. Audiodaten werden zur Transkription temporär weitergeleitet und standardmäßig nicht gespeichert. Es gibt eine Opt-in-Option für das Trainingskorpus; eine Einwilligung ist zweimal erforderlich.
Lösungsarchitektur
Ein nativer Swift-Client streamt Opus-Audio, während der Nutzer noch spricht. Die Audiodaten erreichen einen Cloudflare Worker, der die Schlüsselverwaltung, Telemetrie und das Geo-Relay übernimmt. Der Worker leitet die Daten an einen Cloud-ASR-Anbieter weiter, auf dem Whisper large-v3-turbo läuft. Der Text wird direkt an der Cursor-Position eingefügt. Hinter dem Worker befinden sich ein StatsCounter Durable Object, R2-Buckets und die Analytics Engine.
Sofortübersetzung (integrierte Funktion)
Ein zusätzlicher Modifikator macht aus dem Diktat eine Übersetzung. Halten Sie ⌥ gedrückt, um zu diktieren; halten Sie ⌥+⌃ gedrückt, um während des Sprechens zu übersetzen. Der Benutzer spricht in einer Sprache, und die Ausgabe erscheint an der Cursorposition in einer anderen – in jeder beliebigen aktiven Mac-App.
Die Pipeline nutzt alle oben beschriebenen Ebenen wieder. Der Streaming-Opus-Pfad liefert Audio an den Worker. Whisper large-v3-turbo transkribiert mit automatischer Erkennung der Ausgangssprache. gpt-oss-120b übersetzt das Transkript auf derselben Edge-Route. Die Smart-Insertion-Ebene fügt den Text an der Cursorposition ein. Kein Kopieren und Einfügen, keine separate Benutzeroberfläche, kein zusätzlicher Aufwand für den Benutzer. Der technische Clou ist die Komposition: Eine einzige Benutzergeste steuert eine Multi-Modell-Pipeline (ASR plus LLM) über eine einzige Edge-Route, ohne dass eine neue Benutzeroberfläche erforderlich ist.
Technologie-Stack
Team und Bereitstellungsmodell
Die Ingenieure von Codebridge haben jeden Arbeitsablauf parallel mit KI-Agenten durchgeführt: Übersetzungsteams mit sprachspezifischen Prüfern, Multi-Agenten-Wettbewerbsanalysen, agentengestützte Design-Exploration und Code-Reviews. Diese Kombination ist der Grund, warum ein erfahrenes Team in drei Wochen 67 von Apple notariell beglaubigte Produktions-Releases bereitstellen konnte.
Technologien, die wir in diesem Projekt verwenden
Produktionskennzahlen und Ergebnisse
Seit drei Wochen im Live-Betrieb. Die unten aufgeführten Kennzahlen wurden während des laufenden Betriebs gemessen.
- Wahrgenommene Latenz. ~300 ms auf dem Warm-Pfad. Serverseitiger Median 346 ms.
- p99-Latenz. 1.251 ms bei n ≈ 26.860 Diktaten. Der Geo-Relay-Pfad fängt die stärksten regionalen Schwankungen des Upstream-Anbieters ab.
- Produktionsvolumen. 46.011 Diktate und über 1,1 Mio. Wörter in 29 Ländern.
- Mehrsprachige Abdeckung. 40 UI-Sprachen live, mit vorgerenderten Marketingseiten für jede einzelne Region.
- Worker-CPU pro Diktat. ~1 ms. Die Edge übernimmt das Relay, nicht die Transkription.
- Release-Zyklus. 67 von Apple notarisierte Produktions-Builds innerhalb von drei Wochen.
Vorher und nachher, im Vergleich zum allgemeinen Produktstandard
Top-Länder (erste drei Wochen)
Ukraine 8.590 · Indonesien 7.690 · Deutschland 1.730 · Tschechien 1.700 · USA 1.300 · Portugal 1.260 · Vereinigte Arabische Emirate 780. Die geografische Verteilung bestätigt die Hypothese der sprachlichen Lücke: Nutzer, die von Apples Diktierfunktionen nicht ausreichend bedient werden, machen den Großteil des frühen Traffics aus.
Latenz-Perzentile (serverseitig, live 7 Tage, n ≈ 26.860)
p25: 272 ms · p50: 346 ms · p75: 441 ms · p90: 602 ms · p99: 1.251 ms.
Kostenstruktur
Die Architektur zahlt den Inferenz-Anbieter pro Aufruf. Der Worker übernimmt Relay, Telemetrie und Schlüsselverwaltung zu Edge-Kosten. Die Infrastrukturkosten skalieren linear mit der aktiven Nutzung und nicht mit einer permanent laufenden GPU-Kapazität – genau diese architektonische Struktur ermöglicht es einem kleinen Betreiber, dies in produktivem Maßstab zu betreiben.
Was wir nicht gemessen haben
Der Speicher- und CPU-Verbrauch auf Client-Seite wird zwar erfasst, aber nicht über verschiedene Hardwareklassen hinweg einem Stresstest unterzogen. Die Erfolgsrate bei Wiederholungsversuchen in instabilen Netzwerken wird aus der Telemetrie abgeleitet und nicht anhand eines kontrollierten Datensatzes ermittelt. Wir speichern aus Prinzip keine lebenslangen Audiominuten, wodurch uns eine Kennzahl fehlt, die wir sonst berichten würden.
Zukünftige Pläne
Phase 2 (aktiv)
Windows-Release. „Race Mode“ auf dem Gerät: Lokaler Apple SpeechAnalyzer läuft parallel zur Cloud, das erste nicht leere Ergebnis gewinnt. Gerätebezogene Attestierung.
Phase 3 (geplant)
iOS, implementiert als Tastaturerweiterung mit Container-App. Optionaler KI-Formatierungsschritt. Mögliche Pro-Version für Einzelnutzer.
Phase 4 (geplant)
Android, via Overlay und AccessibilityService.
Willst du ähnliches erreichen Ergebnisse? Lass uns deine Idee entwickeln!
