„Ist meine Internetverbindung im Haus gerade ausgelastet?“ Diese Frage wollte ich schnell beantwortet haben. Meine App Router Monitor für iOS und macOS, zeigt den aktuellen Internetverkehr meiner FRITZ!Box (kaufen) direkt in der Mac-Menüleiste oder auf dem iPhone an. Eine App nach meinen Vorstellungen fand ich nicht.

Also habe ich sie mit ChatGPT 5.6 Sol gebaut – ohne selbst eine Zeile Code zu schreiben. Denn: Coding ist gelöst weiß auch Nico drüben im Couchblog. Sogar App Store Connect habe ich nicht selbst bedient. Denn ich wollte nicht nur die App bauen, sondern sie end-to-end in den App Store bekommen.

Das Ergebnis heißt Router Monitor

Router Monitor im AppStore iOS, iPad und macOS verbindet sich im lokalen Netzwerk direkt mit der FRITZBox (kaufen). Auf dem Mac stehen Download und Upload ständig in der Menüleiste. Ein Klick öffnet Verlauf und Einstellungen. Auf iPhone und iPad gibt es dieselben Daten als native App. Zugangsdaten landen im Apple-Schlüsselbund; es gibt keinen externen Server, kein Tracking und kein Benutzerkonto. Gleichzeitig weiß ich auch, dass es bereits Alternativen gibt. Aber die hatten als Fokus immer iOS und nicht macOS. Das wollte ich ändern. Außerdem will ich lernen, indem ich eine echte App im Store habe.

Eine App ohne lästige Abhängigkeiten

Mir war wichtig, eine App zu entwickeln, die ohne eigenes Backend auskommt. Mein Vorbild war eine frühe Bier-App für das iPhone: Kippte man das Gerät, sah es so aus, als würde man ein Glas Bier austrinken. Die Idee war damals aus zwei Gründen genial: Sie nutzte die damals noch neuartigen Bewegungssensoren des iPhones – und sie funktionierte vollständig auf dem Gerät, ohne Server oder weitere Abhängigkeiten.

Router Monitor ist zwar auf die lokale Schnittstelle der FRITZ!Box (kaufen) angewiesen. Ich muss aber kein zusätzliches Hintergrundsystem betreiben, absichern und parallel zur App weiterentwickeln. Es gibt für mich keine Serverkosten und keine versionierte API, die über Jahre abwärtskompatibel bleiben muss.

Mein Tool: ChatGPT mit Codex reichte völlig aus

Für die komplette Entwicklung habe ich lediglich mein normales ChatGPT-Plus-Abo mit Codex genutzt. Zusätzliche Tokens oder andere kostenpflichtige KI-Dienste waren nicht nötig. Die regelmäßigen Resets des Nutzungslimits kamen mir dabei sogar ganz gelegen – danach ging es einfach weiter.

Entscheidend war für mich der Full Access auf mein MacBook Pro. Dadurch konnte Codex nicht nur Code schreiben, sondern selbstständig die benötigten Tools lokal installieren, konfigurieren und verwenden. Genau das machte den Unterschied: Ich musste keine Entwicklungsumgebung vorbereiten oder ständig zwischen ChatGPT und meinem Mac vermitteln.

Ich habe Xcode nie selbst gestartet

Begonnen hat alles nicht mit einem ausgefeilten Master-Prompt, sondern mit der Frage: „Kannst du die aktuell genutzte Bandbreite meiner FRITZ!Box auslesen?“ Kurz darauf wurde daraus: „Eine native Mac-App in der Menüleiste, die sich direkt verbindet.“ Danach ging es in vielen kleinen Schleifen weiter: Der Graph sieht falsch aus, die Farben sind nicht barrierefrei, das Fenster wird abgeschnitten, beim ersten Start fehlt das Symbol oder ein Messwert ergibt keinen Sinn. Ich schickte Screenshots und beschrieb das gewünschte Ergebnis; Codex untersuchte den Code, änderte die App, startete Builds und Tests und stellte neue Versionen bereit. Einen großen Plan gab es am Anfang nicht – aber immer klarere Regeln, die wir dauerhaft in einer AGENTS.md festhielten. Xcode habe ich dabei kein einziges Mal selbst gestartet.

Auch Sicherheit war kein Punkt auf einer Checkliste am Ende, sondern Teil dieser Gespräche. Auf meine Bitte „Stelle sicher, dass die Keychain nicht unnötig aufgerufen wird“ wurde der Zugriff auf den Apple-Schlüsselbund überarbeitet und reduziert. Die Zugangsdaten zur FRITZ!Box dürfen nicht im Repository landen und die App läuft in Apples Sandbox. Auch die Schlüssel zum Signieren und Veröffentlichen haben wir gesondert geprüft: Das Repository bleibt privat, die Schlüssel liegen als geschützte GitHub-Secrets vor, werden beim Build nur temporär auf dem GitHub-Runner eingerichtet und anschließend wieder gelöscht.

Codex hatte zwar vollen Zugriff auf meinen privaten Mac, aber gerade deshalb waren klare Grenzen und wiederholte Kontrollen wichtiger als blindes Vertrauen. Das ist für viele, denke ich, der schwierigste Schritt: dass die Agentic AI von ChatGPT vollen Zugriff auf meinen Computer samt Browser hatte.

Datenschutz und Sicherheit sind eingebaut

Beim Datenschutz war die beste Entscheidung, möglichst wenig Datenschutzprobleme entstehen zu lassen. Router Monitor überträgt keine Nutzungsdaten an mich oder an Dritte: kein Tracking, keine Analyse-Software und kein Benutzerkonto. Die Zugangsdaten zur FRITZ!Box werden im Apple-Schlüsselbund von iOS und macOS gespeichert und nur für die direkte Verbindung zum eigenen Router verwendet. Messwerte und Einstellungen bleiben lokal auf dem Gerät. Datenschutz und Sicherheit wurden also nicht nachträglich ergänzt, sondern waren Teil der Architektur – Privacy und Security by Design.

Die Architektur war wichtiger als der Code

KI kann zügig Swift schreiben. Sie muss aber wissen, welche App entstehen soll. Die entscheidenden Vorgaben waren deshalb keine einzelnen Buttons, sondern Grenzen und Grundsätze:

• Close to core: Die App sollte nativ mit SwiftUI und AppKit arbeiten.
• Release early, release often. Dafür muss alles vollständig automatisiert werden. Siehe Zero Maintenance.
• Working Backwards („vom Kunden rückwärts denken“): Immer den Kunden in den Vordergrund stellen.
• Test-driven development: Damals als Entwickler habe ich selten Unit-Tests geschrieben. Hier war es essenziell, damit ich nicht etwas mit dem Hintern einreiße, was ich vorn aufbaue.
• No legacy: Wir unterstützen nur den neuesten Tech-Stack und Hardware. Sorry, Intel-CPUs. Apple Silicon only.
• Shared Codebase: Mac und iOS sollten Router-Zugriff, Messwerte, Verlauf, Einstellungen und Schlüsselbund gemeinsam nutzen.

Außerdem mussten Dinge klar sein wie die Verortung in der Menüleiste mit Popover und permanentem Aktualisieren der Daten. Auf iOS dagegen läuft die Messung nur im Vordergrund, weil das System gewöhnliche Apps im Hintergrund anhält. Die Verbindung zur Fritz!Box sollte lokal über TR-064 laufen. So was muss man als Mensch hereinbringen, sonst wird es schnell wild.

Formalisiert wurde all das mit dem Prinzip der AGENTS.md, welche ich von meinen anderen Projekten auf GitHub übernommen und auf App-Entwicklung umgestellt und angepasst habe. Auch dieser Prozess ist natürlich gestützt über Agentic AI.

Solche Entscheidungen verhindern, dass eine KI einfach zwei Apps baut, die zufällig ähnlich aussehen. Sie bestimmen, was gemeinsam genutzt wird, wo sich die Plattformen unterscheiden dürfen und welche Daten das Gerät niemals verlassen. Dank des „Nimm, was Apple schon mitbringt“-Ansatzes ist die Binary mit nur 1,4 MB sogar diskettentauglich.

Ich war Auftraggeber, Tester und Bremse

Meine Arbeit bestand deshalb nicht im Programmieren, sondern darin, Anforderungen zu formulieren, Ergebnisse an einer echten FRITZ!Box (kaufen) zu prüfen und Entscheidungen zu treffen. Ich war Auftraggeber, Tester und manchmal auch die Bremse, wenn ein technisch korrekter Build noch nicht das gewünschte Ergebnis lieferte.

Die KI hat den Code geschrieben. Ich musste trotzdem entscheiden, welche App sie schreiben soll.

Ein erfolgreicher Build war dabei nie der Beweis, dass etwas funktioniert. Entscheidend waren die echte Anzeige in der Mac-Menüleiste, der Test auf iPhone und iPad, die Verbindung zum Router und später der tatsächlich sichtbare Zustand bei Apple.

Auch App Store Connect lief über Automatisierung

Normalerweise beginnt nach der App-Entwicklung noch eine zweite Disziplin: Zertifikate, Builds, TestFlight, Bildschirmfotos, Beschreibungen und App-Review. Auch dafür entstanden Skripte und vor allem GitHub-Actions. Sie bauen und signieren beide Apps, laden sie hoch, verteilen TestFlight-Versionen und gleichen die bei Apple gespeicherten Bildschirmfotos mit dem Projekt ab.

Auch hier musste der Prozess klar definiert werden: iOS und macOS sind getrennte Plattformen, ein erfolgreicher Upload ist noch keine sichtbare TestFlight-Version und eine Freigabe ist noch keine Veröffentlichung. Automatisierung nimmt Arbeit ab. Sie nimmt einem nicht die Verantwortung für den gewünschten Endzustand ab.

Feedback einsammeln macht Spaß!

Besonders viel Freude hat es mir gemacht, wenn sich Leute in meiner Gegenwart die App geladen haben, Feedback äußerten und ich das direkt durch die schlanke Pipeline umsetzen konnte. Dabei habe ich die Wahl, es erst über Testflight oder direkt in Produktion zu bringen.

Beispiel:

„Wenn eine App mich nach dem ersten Start mit dem Kauf nervt, werfe ich sie sofort wieder runter.“

Michael S. bei der ersten Nutzung der iOS-App

Noch am selben Tag war eine neue Version produktiv im Store, welche erst 10 Minuten nach der ersten erfolgreichen Verbindung mit der Fritz!Box fragt, ob man die „7 Tage kostenlos“-Phase aktivieren will, was dann am Ende zum Kauf führt.

99 Euro für TestFlight und den App Store

Bevor Router Monitor über TestFlight getestet und im App Store veröffentlicht werden konnte, musste ich Apples Developer-Programm beitreten. Das kostet 99 Euro pro Jahr.

Deshalb ist die App nach sieben kostenlosen Tagen kostenpflichtig: einmalig 5,99 Euro für die dauerhafte Nutzung. Nach Mehrwertsteuer und Apples Anteil bleiben davon ungefähr 4,30 Euro übrig. Die App muss sich also rund 24-mal verkaufen, nur um die jährliche Entwicklergebühr zu finanzieren.

Sogar die App-Store-Screenshots entstanden automatisch

Nicht einmal die Erzeugung des Codes fühlte sich für mich wie die größte Magie an. Noch beeindruckender fand ich, wie ChatGPT mit Codex selbstständig die Screenshots für macOS und iOS erstellte.

Dafür wurde mein Mac ferngesteuert, die App in den passenden Zuständen geöffnet und die benötigten Aufnahmen erzeugt. Selbst die Konfiguration im schrecklichen App Store Connect – Apples Verwaltungsoberfläche für Apps – erledigte ChatGPT über die Browser-Erweiterung. Irre!

Softwareentwicklung ohne Programmieren?

Bei SimpleTOC habe ich noch versucht, React zu verstehen – und dabei vor allem verstanden, wie wenig ich React verstanden hatte. Für Router Monitor habe ich Swift gar nicht erst gelernt. Trotzdem ist das Ergebnis größer: zwei native Apps, Tests und ein automatisierter Veröffentlichungsprozess. Danke, Computer Nr. 3.

Von der ersten Idee bis in den Store verging in meinem Urlaub gerade einmal eine Woche. Dank „Release early, release often“ und der vollautomatischen Pipeline sind Bugfixes noch am selben Tag im Store.