Ich habe Traverba entwickelt – einen Echtzeit-Übersetzer, der zu 100 % lokal auf dem Smartphone läuft, ohne Cloud-APIs. Spracherkennung, Übersetzung in 108 Sprachen, Kamera-OCR in 92 Schriftsystemen, eine Bildschirmübersetzungsebene, Dateitranskription und Offline-Gruppenchat über Bluetooth für bis zu 7 Personen.
Die gesamte App ist mit Flutter gebaut, wobei nativer Plattformcode die rechenintensiven Aufgaben übernimmt. Hier erkläre ich, was die App leistet, warum Flutter die richtige Wahl war und welche Herausforderungen beim Veröffentlichen auf iOS und Android aufgetreten sind.
Was die App kann
Traverba bietet fünf Kernfunktionen, alle offline:
Live-Sprachübersetzung – Sprich eine Sprache, höre und lies die Übersetzung in einer anderen. Drei Modi: In-App, schwebendes System-Audioabgreifen (übersetzt Audio aus Zoom/Teams/Meet) und schwebendes Mikrofon. Automatisches Vorlesen in der Zielsprache.
Kameraübersetzung – Richte die Kamera auf ein Menü, ein Schild, ein Formular oder ein Dokument. Zwei OCR-Motoren: Basic Modus (ML Kit) für schnelle Scans, Professional Modus (PaddleOCR) für komplexe Schriftsysteme wie CJK, Arabisch, Kyrillisch und Devanagari. Unterstützt 92 Sprachen. Die App ersetzt fremden Text direkt im Bild durch die Übersetzung.
Bildschirmübersetzung – Eine schwebende Überlagerung, die Text in jeder App übersetzt. Anime schauen, koreanische Nachrichten lesen, ein japanisches Spiel spielen oder eine WeChat-Nachricht empfangen? Tippe auf die Schaltfläche der Überlagerung und der Text wird direkt übersetzt. Kein App-Wechsel nötig.
Dateitranskription – Importiere Audio- oder Videodateien (mp3, m4a, wav, mp4) und erhalte zeitgestempelte, nebeneinandergestellte Abschriften in Original- und Zielsprache.
Offline-Gruppenchat – Bis zu 7 Personen verbinden sich über ein Bluetooth-Mesh. Jede Person spricht ihre eigene Sprache. Jede Nachricht wird in Echtzeit in die Sprache aller Teilnehmer übersetzt. Kein Internet. Kein Server. Jedes Telefon kümmert sich selbstständig um seine eigene Spracherkennung und Übersetzung.
All dies läuft lokal auf dem Prozessor des Smartphones. Keine API-Schlüssel, keine Serverkosten, keine Daten, die das Gerät verlassen.
Warum Flutter
Am Anfang habe ich Flutter, React Native und vollständig native Entwicklung (separate Swift- und Kotlin-Codebasen) gegeneinander abgewogen.
Eine plattformübergreifende Codebasis war unverzichtbar. Als Einzelentwickler zwei native Codebasen für eine so komplexe App zu pflegen, war schlicht nicht realistisch. Der Dart-UI-Layer – Einstellungen, Chat-Blasen, Transkriptansichten, Onboarding-Tour, Download-Sheets, Sprachauswahl – macht etwa 60 % des gesamten Codes aus. Das zweimal zu schreiben hätte den Projektzeitplan verdoppelt.
Flutters Plattformkanal-System machte die native Integration praktikabel. Die KI-intensiven Aufgaben (ASR-Inferenz, LLM-Übersetzung, OCR, Bluetooth-Mesh, schwebende Überlagerungen) laufen in nativem Swift/Kotlin über Plattformkanäle und Methodenkanäle. Flutter dient nicht als KI-Laufzeitumgebung – es ist der UI- und Orchestrierungslayer, der die nativen Engines verbindet.
Die Leistung war ausreichend. Die Befürchtung bei Flutter für diese Art von App ist der Overhead – jede Millisekunde zählt, wenn man ASR → Übersetzung → TTS in einem Gespräch verkettet. In der Praxis fügt der Flutter-Layer vernachlässigbare Latenz hinzu, da die schwere Berechnung in nativem Code stattfindet. Der Dart-Layer verwaltet den Zustand, das Routing und UI-Updates – und das macht er gut.
Hot Reload hat die UI-Iteration drastisch beschleunigt. Mit fünf verschiedenen Funktionsbereichen (Sprache, Kamera, Bildschirm, Datei, Gruppenchat), jeweils mit mehreren Zuständen und Modi, war die Möglichkeit, die UI ohne Neubau zu iterieren, ein erheblicher Produktivitätsmultiplikator.
Die Architektur: Flutter als Orchestrator
Die App folgt einer klaren Trennung:
Flutter/Dart-Layer übernimmt:
- Die gesamte UI (Material 3, adaptive Layouts für Telefon und Tablet)
- Zustandsverwaltung und Feature-Routing
- Sprach- und Gebietsschemaauswahl sowie Benutzereinstellungen
- Download-Verwaltung für optionale Modelle
- Münzökonomie und Abonnement-Gating
- Geführte Onboarding-Tour
Nativer Layer übernimmt (über Plattformkanäle):
- ASR-Inferenz (sherpa-onnx / whisper.cpp)
- LLM-Übersetzung (Gemma über On-Device-Laufzeit)
- Traditionelle ML-Übersetzung (ONNX NMT-Modelle)
- Kamera-OCR (ML Kit + PaddleOCR)
- Text-to-Speech
- Bluetooth-Mesh für Gruppenchat
- Schwebende Überlagerung (Bildschirmübersetzung + System-Audioabgreifen)
- Speicherbudgetverwaltung und Modellladen/-entladen
Die Brücke zwischen diesen Layern ist ein Satz von Plattformkanälen mit klar definierten Schnittstellen. Die Dart-Seite sendet Befehle ("Starte ASR für Kantonesisch", "Übersetze diesen Text vom Japanischen ins Englische", "Erfasse Bildschirm und führe OCR durch"). Die native Seite gibt Ergebnisse asynchron zurück.
Drei ASR-Modelle, automatisches Routing
Kein einzelnes Spracherkennungsmodell deckt alle Sprachen gut ab. Anstatt für manche Sprachen schlechte Qualität zu akzeptieren, liefert die App drei spezialisierte Modelle:
- Parakeet Optimiert für Englisch. Im App-Paket enthalten für sofortige englische Spracherkennung ohne Download.
- Whisper.cpp Breite mehrsprachige Abdeckung über 30+ Sprachen.
- Qwen3-ASR Optimiert für CJK mit dedizierter Unterstützung für Kantonesisch.
Wenn der Nutzer eine Quellsprache auswählt, wählt der Dart-Routing-Layer das beste Modell aus und teilt der nativen Seite mit, welche Engine aktiviert werden soll. Der Nutzer sieht die Modellauswahl nie und muss sie nicht verwalten.
Der schwierige Teil ist der Speicher. Diese Modelle belegen zwischen 500 MB und 1,9 GB RAM. Alle drei gleichzeitig zu laden würde die meisten Telefone zum Absturz bringen. Ein Speicherbudgetplaner (in Dart geschrieben, der native Speicherstatistiken abfragt) verfolgt, was geladen ist, und entlädt das zuletzt verwendete Modell, wenn ein neues geladen werden muss. Ein Backend-Präferenzspeicher merkt sich, welches Compute-Backend (NPU, GPU, CPU) auf jedem spezifischen Gerät funktioniert hat, sodass nachfolgende Ausführungen fehlgeschlagene Backends überspringen.
108 Sprachen über zwei Übersetzungsstufen
Übersetzung erfolgt über zwei Wege:
Stufe 1 – Traditionelle NMT-Modelle (61 Sprachen): Schnell, geringer Speicherbedarf, gute Qualität für ressourcenreiche Sprachpaare. ONNX-Modelle, die über sherpa-onnx auf beiden Plattformen laufen.
Stufe 2 – On-Device Gemma LLM (47 zusätzliche Sprachen): Für Sprachen ohne dedizierte NMT-Modelle (Yoruba, Amharisch, Laotisch, Birmanisch und andere) übernimmt ein quantisiertes Gemma-2B-Modell die lokale Übersetzung. Langsamer als Stufe 1, erweitert aber die Abdeckung auf Sprachen, die traditionelle Modelle schlecht bedienen.
Der Dart-Layer verwaltet, welche Stufe basierend auf dem Sprachpaar verwendet wird. Der Nutzer erlebt eine einheitliche Oberfläche.
Kamera-OCR: Dual-Engine, 92 Sprachen
Die Kameraübersetzung bietet zwei vom Nutzer wählbare Engines:
Basic Modus verwendet Googles ML Kit für On-Device-Texterkennung. Schnell, bewältigt Latein, Kyrillisch und CJK gut. Gut für den Echtzeit-Sucher.
Professional Modus verwendet PaddleOCR, das auf dem Gerät läuft. Bessere Genauigkeit für komplexe Layouts, gemischte Schriftsysteme, gebogenen Text und geringen Kontrast. Verwendet ein Münz-Gate (5 Münzen pro Aufnahme), da es rechenintensiver ist.
Eine auf die harte Tour gelernte Lektion: iOS bündelt standardmäßig nur das lateinische OCR-Skriptmodell. CJK, Devanagari und Arabisch erfordern das explizite Hinzufügen skriptspezifischer Pods zur Podfile. Der Fehler ist völlig lautlos – ML Kit gibt leere Ergebnisse für nicht unterstützte Schriftsysteme ohne Fehlermeldung zurück. Wenn du mehrsprachige OCR auf iOS mit ML Kit baust, überprüfe deine Podfile.
Schwebende Überlagerung: Nativ, nicht Flutter
Die Bildschirmübersetzungs- und System-Audiofunktionen laufen als native Überlagerungen außerhalb von Flutters Rendering-Oberfläche. Auf Android ist dies ein System-Overlay-Dienst, der in Kotlin geschrieben ist. Auf iOS verwendet es Screen-Capture-APIs in Swift.
Diese Überlagerungen kommunizieren über Plattformkanäle zurück zur Flutter-Übersetzungsengine. Die architektonische Herausforderung ist das Lifecycle-Management – die Überlagerung muss aktiv bleiben, während die Flutter-Activity möglicherweise in den Hintergrund verschoben ist.
Eine wichtige Lektion: Auf iOS müssen native Bridge-Instanzen stark referenziert werden (statisch oder von einem Singleton gehalten). Wenn die Bridge eine Instanzvariable ist, die nichts referenziert, wird ARC sie einsammeln und alle Handler-Closures werden lautlos zu Nichtoperationen. Ich habe Tage damit verloren, dass ein Download-Fortschrittsanzeiger bei 0 % steckte, weil die Bridge eingesammelt wurde. Kein Absturz, kein Fehler, nur stilles Versagen.
Bluetooth-Gruppenchat
Der Offline-Gruppenchat verwendet ein Bluetooth-Mesh-Protokoll. Jedes Telefon fungiert sowohl als Empfänger als auch als Relais. Nachrichten werden an alle verbundenen Geräte gesendet. Jedes Gerät führt seine eigene Spracherkennung und Übersetzung unabhängig durch – es gibt kein "Host"- oder "Server"-Telefon.
Flutter verwaltet die Chat-UI, den Nachrichtenstatus und die Teilnehmerverwaltung. Der Bluetooth-Stack ist vollständig nativ (CoreBluetooth auf iOS, Android Bluetooth API) und über Plattformkanäle eingebunden.
Die gesamte Pipeline-Latenz (Sprache → ASR → Übersetzen → Senden → Anzeigen) beträgt etwa 1 Sekunde. Die Dart-UI verwendet optimistisches Anzeigen (zeigt sofort "wird übersetzt..." beim Senden), damit sich das Gespräch flüssig anfühlt.
Zahlen
- Sprachen: 108 insgesamt (61 ML + 47 KI)
- ASR-Sprachen: 30 On-Device-Spracherkennung
- OCR-Sprachen: 92 Kamera-Texterkennung
- App-Basisgröße: ~150 MB + herunterladbare Modelle
- Plattformen: iOS + Android aus einer einzigen Flutter-Codebasis
- Dart/Flutter-Code: ~60 % der gesamten Codebasis (UI, Zustand, Routing, Geschäftslogik)
- Nativer Code: ~40 % (ASR, LLM, OCR, Bluetooth, Überlagerungen, Speicherverwaltung)
- Teamgröße: 1
Was Flutter bei diesem Projekt richtig gemacht hat
Eine einzige Codebasis für komplexe UI. Fünf Funktionsbereiche, jeweils mit mehreren Modi, Download-Sheets, Onboarding-Tour, adaptive Layouts – das einmal statt zweimal zu schreiben war als Einzelentwickler der Unterschied zwischen Veröffentlichen und Nicht-Veröffentlichen.
Plattformkanäle sind gut konzipiert. Die Brücke zwischen Dart und nativem Code ist sauber, gut dokumentiert und zuverlässig. Für eine App, bei der die schwere Berechnung nativ ist, aber das Nutzererlebnis Flutter-basiert ist, ist das genau die richtige Architektur.
Hot Reload für schnelle Iteration. Layouts anpassen, Zustände testen, UX-Abläufe iterieren – Hot Reload hat die Iterationszeit bei Hunderten von UI-Änderungen von Minuten auf Sekunden reduziert.
Das Ökosystem ist ausgereift. Zustandsverwaltung (Riverpod), Navigation, Lokalisierung (117 Gebietsschemas), adaptives Design – das Flutter-Ökosystem bietet produktionsreife Lösungen für all das.
Was schwierig war
Speicherdruck ist Flutters blinder Fleck. Flutter bietet keine feinkörnige Speicherkontrolle. Wenn man mehrere native ML-Modelle neben der Flutter-Engine gemeinsam lädt, muss man den Speicher auf nativer Ebene verwalten und ihn an Dart weitergeben. Es gibt keine eingebaute Flutter-API für "Wie viel RAM verwendet meine App" oder "Wie hoch ist der Systemspeicherdruck".
Nativer Overlay-Lifecycle. Schwebende Überlagerungen, die außerhalb der Flutter-Oberfläche operieren, sind architektonisch komplex. Die Flutter-Activity kann in den Hintergrund verschoben werden, während die Überlagerung aktiv ist. Die Brücke am Leben zu halten, die Statussynchronisation zu verwalten und plattformspezifische Lifecycle-Ereignisse zu behandeln, erforderte erheblichen nativen Code, den Flutter nicht abstrahieren kann.
iOS-Build-Komplexität. CocoaPods mit ML Kit-Skript-Pods, Entitlements (increased-memory-limit für das gemeinsame Laden von ASR + LLM), App Tracking Transparency Timing, Code-Signing – die iOS-Build-Pipeline hat viele bewegliche Teile, die Flutters Tooling nicht vollständig verwaltet.
Ausprobieren
Traverba ist auf beiden Plattformen kostenlos. Sprach-, Kamera-, Bildschirm- und Textübersetzung sind alle kostenlos und unbegrenzt. Premium ($1.99/Monat) schaltet Gruppenchat, Dateitranskription und Meeting-Zusammenfassungen frei.
Verfügbar bei Google Play und im App Store. Mehr erfahren unter traverba.com.
Ich beantworte gerne Fragen zur Architektur, zu Flutter + nativen Integrationsmustern oder zu On-Device-KI im Allgemeinen.