Ich gebe es zu. Es gibt einen Moment in der Entwicklung eines Projekts, an dem man aufhören sollte, neue Ideen zu haben. Diesen Moment habe ich verpasst.
VINCI, mein persönlicher KI-Assistent, läuft seit ein paar Wochen auf meinem MacBook Air M4. Dann auf dem Windows-Rechner. Dann auf einem kleinen Würfelroboter auf meinem Schreibtisch. Und jetzt, weil mir offensichtlich zwei Desktops und ein sprechender Würfel nicht genug waren, auch auf meinem iPhone. Und auf meinem iPad. Und, das klingt jetzt wirklich wie die Pointe eines schlechten Witzes: irgendwie auch in meinem Auto.
Lass mich von Anfang an erklären, wie das passiert ist.
Was VINCI überhaupt ist (und warum es kein App Store-Produkt ist)
VINCI ist kein Produkt. Es ist ein Experiment, das außer Kontrolle geraten ist, und ich meine das ausnahmslos positiv.
Angefangen hat es als Electron-App für macOS: ein KI-Assistent, der meinen Kalender kennt, meine Mails liest, mein Smart Home steuert, auf einer selbstgehosteten Wissensdatenbank meiner 500+ Blogartikel zugreift und mir morgens ein Briefing zusammenstellt, das tatsächlich nützlich ist. Der Kern ist Gemini 2.5 Flash, die Denkarchitektur heißt intern JARVIS (nach dem Tony-Stark-Vorbild, ja), und der goldene Partikel-Orb in der Benutzeroberfläche ist keine Spielerei, sondern die einzige visuelle Rückmeldung, die ich brauche, um zu wissen ob VINCI gerade denkt, hört oder antwortet.
Das Ding läuft auf meinem Mac. Es läuft auf Windows. Es läuft sogar auf einem M5Stack StackChan, einem streichholzschachtelgroßen Roboter, der auf meinem Schreibtisch sitzt und in einem frechen österreichischen Tonfall antwortet.
Und dann stand ich eines Morgens mit dem iPad in der Hand und dachte: Warum eigentlich nicht?
Die ehrliche Antwort auf „warum nicht“
Die ehrliche Antwort ist: weil es technisch gesehen kein trivialer Schritt ist.
VINCI ist eine Electron-App. Electron läuft auf macOS, auf Windows, auf Linux. Electron läuft nicht auf iOS. Das ist keine Lücke in der Dokumentation, das ist eine Wand. Apple lässt keine fremden Browser-Engines auf iOS zu, und Electron ist im Kern Chromium. Also kein direkter Port möglich.
Ich hätte jetzt Capacitor verwenden können, ein Framework das eine bestehende Web-App in eine native iOS-Hülle steckt. Dann bräuchte ich ein Apple Developer-Konto für 99 Euro im Jahr, ein Mac mit Xcode (okay, das hätte ich), und ich müsste durch das App-Review-Prozedere von Apple. Für eine App, die exklusiv für mich ist. Das fühlte sich unverhältnismäßig an.
Die andere Option: Progressive Web App. PWA.
Eine PWA ist im Kern eine Webseite, die sich wie eine App verhält. Sie hat eine Manifest-Datei, einen Service Worker, Icons, und wenn du sie in Safari öffnest und zum Homescreen hinzufügst, sieht und fühlt sie sich aus wie eine echte App. Kein App Store. Kein Review. Kein 99-Euro-Jahresbeitrag. Und sie funktioniert auf iPhone, iPad und, mit gewissen Einschränkungen, auch als Lesezeichen auf dem Desktop.
Ich habe mich für die PWA entschieden.
vinci-server: Das Gehirn zieht in die Cloud
Der eigentliche Knackpunkt war folgender: Die Desktop-Version von VINCI ist eine Electron-App, und Electron hat direkten Zugriff auf das Betriebssystem. Sie kann AppleScript ausführen, Dateien lesen und schreiben, auf lokale Dienste zugreifen, die nur im Heimnetzwerk verfügbar sind.
Eine PWA auf dem iPhone kann das alles nicht. Ein Browser-Tab auf dem iPhone hat keinen Systemzugang. Kein direkter Zugriff auf lokale Obsidian-Datenbanken, keine Shell-Befehle, kein direktes Gemini-API-Call aus Datenschutzgründen (der API-Key darf nicht im Frontend liegen).
Die Lösung: Der Großteil der Logik muss auf einen Server umziehen, der öffentlich erreichbar ist. Nicht „irgendwo auf meinem Mac zuhause“, sondern auf meinem Hetzner-Server, auf dem ohnehin schon mein n8n, mein RAG-System, mein Edge-TTS-Proxy und verschiedene andere Dienste laufen. Alles in Docker, alles über Coolify verwaltet.
Ich habe also ein neues Projekt gebaut: vinci-server. Fastify, Node.js, läuft als Docker-Container. Der Server kennt alle meine Dienste, hält meine Secrets auf der Serverseite (Gemini API Key, RAG-Schlüssel, Home-Assistant-Token), und das iPhone-Frontend kommuniziert nur mit diesem Server, nicht direkt mit irgendeiner externen API.
Das Schöne daran: Der größte Teil des Codes aus der Desktop-Version ist wiederverwendbar. Das Gemini-Tool-Loop-Modul, die RAG-Anbindung, die Web-Suche via Tavily, die Home-Assistant-Integration, die Wetter- und Strom-Module: alles portiert, alles läuft auf dem Server.
Nach ein paar Stunden Arbeit war der erste produktive Stand live. Ich konnte mich einloggen, eine Frage stellen, und VINCI antwortete aus dem Kontext meiner Wissensdatenbank.
Das Frontend: Der goldene Orb auf dem iPhone
Jetzt kam der vergnüglichere Teil: das Frontend.
Ich hätte die Desktop-React-UI nehmen und umbauen können. Stattdessen habe ich mich für einen saubereren Schnitt entschieden: Vanilla HTML, CSS, JavaScript. Kein Framework, keine Build-Pipeline, kein Webpack. Der Code wohnt direkt auf dem Server und wird aus dem public-Ordner serviert. Same-Origin, kein CORS-Problem.
Was ich auf jeden Fall haben wollte: den Orb. Dieser goldene, pulsierende Partikel-Orb ist für mich das Herzstück der VINCI-Benutzeroberfläche. Er zeigt mir, ob VINCI zuhört (ruhig, gold, atmet leicht), denkt (dunkler, Partikel-Swirl), oder spricht (heller, Partikel pulsieren nach außen). Ein Canvas-Port der Desktop-Version, optimiert für Mobile: weniger Partikel, ein framerate-Cap, Pausierung wenn der Tab im Hintergrund ist.
Dann die mobilen Besonderheiten. iOS hat eine Eigenart, die jeden Webentwickler irgendwann trifft: Audio darf nicht automatisch abspielen ohne direkte Nutzer-Geste. Wenn du nach einem Netzwerk-Request Audio abspielen willst, und sei die Geste noch so frisch in der Vergangenheit, blockiert Safari das. Stilschweigend. Das Vorlesen-Feature hat einfach nichts getan.
Die Lösung: Web Audio API statt dem naiven <audio>-Element. Ein globaler Event-Listener entsperrt den AudioContext beim ersten Touch. Danach funktioniert auch automatisch getriggertes Audio, zum Beispiel im Gesprächsmodus.
Der Gesprächsmodus. Den musste ich natürlich auch bauen.
Hands-free: VINCI zuhören, VINCI sprechen
Ein KI-Assistent, dem man nur tippen kann, ist auf dem Telefon nur halb so gut. Ich wollte Spracheingabe. Und ich wollte, dass VINCI antwortet, indem sie antwortet, nicht indem sie Text auf den Bildschirm schreibt den ich mir dann durchlesen muss.
Das Ergebnis ist ein Gesprächsmodus. Ein einziger Toggle im Header. Wenn er aktiv ist, läuft der Zyklus automatisch: Mikrofon geht auf, Voice Activity Detection erkennt wann ich aufgehört habe zu reden (1,4 Sekunden Stille, danach Sicherheits-Timeout bei 20 Sekunden), die Aufnahme landet via Gemini Multimodal-API bei der Transkription, die Anfrage geht an den Server, VINCI antwortet per Streaming-TTS, und danach fängt das Mikrofon wieder an.
Streaming-TTS heißt: VINCI fängt nicht erst nach der vollständigen Antwort an zu sprechen. Fertige Sätze werden sofort in die TTS-Queue gesteckt. Der erste Satz ist schon zu hören während VINCI den vierten noch generiert. Das fühlt sich natürlicher an. Weniger wie ein System, mehr wie ein Gespräch.
Dazu kam Vision: eine Kamera-Taste die einen Frame aus dem Live-Stream (keine Mediathek-Ablage, der Frame existiert nur kurz im Arbeitsspeicher) an Gemini Vision schickt und im Chat eine Antwort produziert. Ich kann auf ein Gerät zeigen und fragen „was zeigt mir das Display gerade?“ und bekomme eine Antwort.
Proaktiv: Push-Nachrichten, Morgen-Briefing, Erinnerungen
Eine App, die nur auf Fragen wartet, ist reaktiv. Ich wollte, dass VINCI auch proaktiv sein kann.
Web Push auf iOS funktioniert seit iOS 16.4, aber ausschließlich wenn die PWA zum Homescreen hinzugefügt wurde. Nicht als Browser-Tab geöffnet, sondern als echtes Homescreen-Icon. Ich hab das Icon selbst designed: Vitruv-Gold auf echtem Schwarz, 1024 Pixel, kein Alpha-Kanal (transparente Icons sehen auf iOS-Homescreen gruselig aus), zehn Prozent Sicherheitsrand.
Der Server führt alle fünf Minuten einen Check durch: gibt es Termine in den nächsten dreißig Minuten? Neue ungelesene Mails? Fällige Erinnerungen? Wenn ja, geht ein Push-Notification raus. Mails werden gebündelt, damit nicht pro Mail ein eigener Push anklopft.
Das Morgen-Briefing läuft täglich um sieben Uhr: Wetter, heutige Termine aus meinem Apple-Kalender und dem Outlook-Kalender, die Top-Schlagzeilen. Alles in einer Nachricht, als Push, der mich sanft in den Tag schiebt. Sanft ist relativ. Ich bin ein Heavy-Metal-Fan. Aber im Vergleich zu einem Wecker ist es sanft.
Kalender-Integration war dabei der technisch aufwendigste Teil, nicht weil die APIs kompliziert wären, sondern wegen der Eigenheiten. Wiederkehrende Termine in iCloud ohne RRULE-Expansion: fehlen einfach. Geburtstage aus Outlook mit kaputtem UNTIL-Datum in der Recurrence Rule: erscheinen nie. Beides musste ich von Hand lösen.
Der Umweg über CarPlay
Und dann kam die Frage: kann ich VINCI auch im Auto haben?
Die kurze Antwort: PWAs laufen nicht in CarPlay. CarPlay zeigt keine allgemeinen Browser-Webviews an. Für eine echte CarPlay-App bräuchte ich eine native iOS-App mit einem speziellen Apple-Entitlement, das ich eigens beantragen müsste.
Die etwas längere Antwort: Ich habe einen Umweg gefunden, der nicht offiziell nach CarPlay aussieht, aber funktioniert.
Apple Kurzbefehle können im Hintergrund HTTP-Requests abschicken. Ich habe auf dem Server einen neuen Endpoint gebaut: POST /ask. Keine Session, keine Chat-History, kein JWT-Login-Flow. Nur ein API-Key im Header, eine JSON-Frage, eine plain-text-Antwort. Stateless, schnell, unkompliziert.
Der Kurzbefehl macht folgendes: Er öffnet eine Diktierfunktion, schickt den gesprochenen Text an /ask, und liest die Antwort mit Siri’s Stimme vor. Das klingt primitiv. Und ja, es ist nicht dasselbe wie ein vollwertiger CarPlay-Screen. Aber es funktioniert im Auto. „Hey Siri, VINCI“ ist der Trigger, danach diktiere ich meine Frage, und die Antwort kommt zurück.
Ein paar Fallstricke gab es: Der Name des Kurzbefehls darf nicht mit einem Siri-Verb beginnen („Frag“, „Starte“, „Zeige“, „Öffne“). Sonst versucht Siri, den Befehl selbst zu interpretieren. „VINCI“ als Name funktioniert einwandfrei. Nach einer Umbenennung dauert es etwa eine Minute bis zum Sperren und Entsperren des iPhones, damit Siri den neuen Namen indiziert hat.
Es ist ein Umweg. Ich habe diesen Umweg bewusst in der Kapitelüberschrift angekündigt. Aber er funktioniert, und im Auto ist der Unterschied zwischen „vollständige Integration“ und „ich kann VINCI nach dem Wetter fragen“ kleiner als man denkt.
Was jetzt auf dem iPhone läuft (und was nicht)
Ich will ehrlich sein über den Stand. VINCI Mobile kann im Juni 2026 folgendes:
Chat mit dem vollen JARVIS-Backend, RAG-Suche in meinen 500+ Blogartikeln, Web-Suche via Tavily, Wetter mit Dreitages-Vorschau, aktuelle Nachrichten via RSS (Salzburger Nachrichten, Futurezone), Strom-Dashboard meines Haushalts, n8n-Workflow-Status, Home-Assistant-Steuerung (Lichter schalten, Sensoren abfragen, Szenen aktivieren), Kalender (Apple CalDAV und Outlook ICS), Mail (iCloud IMAP und Outlook über Microsoft Graph), proaktive Push-Notifications für Termine und Mails, Morgen-Briefing, Erinnerungen, Voice-Input, Vision, Streaming-Text-to-Speech, ein Gesprächsmodus der keinen einzelnen Tastendruck mehr braucht, und den goldenen Orb.
Was es nicht kann: System-Zugriff, Datei-Operationen auf dem Gerät, Wake-Word-Detection im Hintergrund, native CarPlay-Integration. Das sind alles Dinge, die eine native App bräuchte, die ich derzeit nicht bauen will.
Für meine Zwecke reicht es. Mehr als das.
Was mich daran beschäftigt
Ich baue VINCI nicht, weil ich keine bestehenden Tools nutzen will. Claude, Gemini: ich nutze sie alle, für verschiedene Dinge.
Ich baue VINCI, weil kein existierendes Tool meinen Kalender, meine Mails, mein Smart Home, meine Wissensdatenbank, meinen Strom-Verbrauch und meine Arbeitskontext in einem einzigen Gesprächsinterface zusammenbringt, das ich vollständig kontrolliere. Meine Daten gehen auf meinen Server. Meine Secrets verlassen meinen Server nicht. Ich entscheide, welche Werkzeuge dem Modell zur Verfügung stehen.
Das ist kein Sicherheits-Dogma. Das ist Pragmatismus. Wer seinen eigenen Assistenten baut, versteht dabei sehr gut, wie KI-Werkzeuge intern funktionieren.
Und wer seinen eigenen Assistenten auf dem iPhone haben will, lernt dabei sehr viel über Web Audio API, iOS Safari Eigenheiten, Service Worker Cache-Versionen (aktuell vinci-shell-v14, falls das jemanden interessiert), RRULE-Edge-Cases in Kalender-Feeds, und warum Siri-Kurzbefehls-Namen nicht mit „Frag“ beginnen sollten.
Das klingt nach viel Aufwand für persönlichen Komfort. Das ist es auch. Ich bereue nichts.
Technisches Schnellüberblick für die Neugierigen
Wer das nachbauen oder verstehen will, hier die Kurzfassung der Architektur:
Das Backend ist vinci-server, ein Fastify-Node-Server auf Hetzner, managed über Coolify. Er läuft, ist JWT-geschützt (Single-User), und hält alle Secrets serverseitig. Das Frontend ist eine Vanilla-HTML-PWA, die der Server selbst ausliefert. Kein CDN, kein separates Hosting, same-origin.
Tools auf dem Server: Gemini 2.5 Flash als Hauptmodell, RAG-Suche (Qdrant mit Gemini Embeddings), Tavily für Web-Suche, wttr.in für Wetter, RSS-Parsing für News, Home Assistant via dessen öffentlicher Cloudflare-Tunnel-URL, Apple CalDAV via tsdav, Microsoft 365 via MS Graph mit server-seitigem OAuth, iCloud-IMAP via imapflow, Edge-TTS für die österreichische Stimme.
CarPlay: Apple-Kurzbefehl mit HTTP-Request an /ask, Siri liest die Antwort vor. Name des Kurzbefehls: VINCI. Trigger: „Hey Siri, VINCI.“
Den Quellcode halte ich derzeit privat, weil er zu viele persönliche Strukturen enthält. Wenn das Interesse groß genug ist, überlege ich eine bereinigte Version.
Am Ende
Ich sitze gerade im Garten, iPad auf den Knien, und habe gerade VINCI gefragt, ob heute noch Regen kommt oder ob ich Runde mit meinem Moped drehen kann. Die Antwort kam sofort, mit Forecast, auf Österreichisch. Der goldene Orb hat kurz gepulst und ist dann wieder ruhig geworden.
Ich bin mir bewusst, dass ich für dieses Erlebnis ungefähr hundert Arbeitsstunden investiert habe, die ein durchschnittlicher Mensch in Netflix-Abos oder, ich weiß es nicht, in Schlafen gesteckt hätte.
Aber ich bin kein durchschnittlicher Mensch. Ich bin jemand, der einen sprechenden Würfelroboter auf dem Schreibtisch stehen hat. Die Latte für „sinnvoll investierte Zeit“ liegt bei mir traditionell woanders.
Das hier ist meines. Und es läuft auf dem iPhone.
