„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 direkt in der Mac-Menüleiste oder 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. Sogar App Store Connect habe ich nicht selbst bedient.

Das Ergebnis heißt Router Monitor

Router Monitor im AppStore iOS, iPad und macOS verbindet sich im lokalen Netzwerk direkt mit der FRITZ!Box. 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 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.

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:

• Die App sollte nativ mit SwiftUI und AppKit arbeiten und sich auf jedem System zu Hause anfühlen.
• Mac und iOS sollten Router-Zugriff, Messwerte, Verlauf, Einstellungen und Schlüsselbund gemeinsam nutzen.
• Auf dem Mac gehört alles in ein kompaktes Menüleisten-Popover. Auf iOS läuft die Messung nur im Vordergrund, weil das System gewöhnliche Apps im Hintergrund anhält.
• Die Verbindung sollte lokal über TR-064 laufen – ohne Cloud, Werbung oder Analyse-Software. So was muss man als Mensch hereinbringen, sonst wird es schnell wild.

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 aus Anforderungen, Rückfragen und sehr vielen Korrekturen. Ich habe die App an einer echten FRITZ!Box ausprobiert, Screenshots geprüft und gesagt, wenn Texte abgeschnitten waren, eine Einstellung am falschen Ort saß oder ein Messwert keinen Sinn ergab. Die KI hat daraufhin den Code geändert, Tests ergänzt und neue Builds erzeugt.

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.

Ich habe App Store Connect dafür nicht selbst bedient. Aber 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.

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.

„KI ersetzt fehlende Expertise nicht – sie vervielfacht die Wirkung vorhandener Expertise.“

Meine Meinung zu KI in der Softwareentwicklung

KI hat Softwareentwicklung für mich nicht abgeschafft. Sie hat meinen Anteil daran verschoben: weg von Syntax und App-Store-Formularen, hin zu Anforderungen, Architektur, Tests und Entscheidungen. Genau dort lag am Ende auch die eigentliche Arbeit.