KI-Fallbeispiele
Die iOS-App desselben Dienstes war das Hauptschlachtfeld, auf dem die Mehrheit der Mitglieder liegt. Dennoch schwiegen die Benachrichtigungen hier noch stiller als unter Android — der Benachrichtigungsweg der vorigen Generation war vollständig abgerissen. Im Anschluss an Praxisbericht ⑥ (den Android-Teil) fassen wir diesmal die iOS-spezifischen Stolperstellen zusammen sowie das, was für beide Betriebssysteme gilt: wie wir die Benachrichtigungen modernisiert haben, ohne den alten Server anzufassen.
Gerade die „Störung, die niemand bemerkt“, ist es wert, zuerst beseitigt zu werden.
Die meisten Nutzer waren auf iOS. Und auf iOS waren die Benachrichtigungen tot.
Wie unter Android war auch die iOS-App eine native Hülle, die einen bestehenden Webdienst anzeigt — ein WebView-Wrapper plus Benachrichtigungen. Der Versand hing an einem Mechanismus der vorigen Generation, und die Zustellung endete in dem Moment, in dem dieser Weg unbrauchbar wurde. Da die meisten Nutzer hier lagen, war die Reichweite der Auswirkungen maximal. Genau diesen Teil auf eine moderne Zustellplattform umzuziehen, war der größte Ertrag des Projekts.
Die Stolperstellen bei iOS waren durchweg solche, die nur auf echter Hardware auftreten.
Bei iOS standen Probleme im Vordergrund, die weder ein virtuelles Gerät noch ein Code-Review zeigt — sie treten erst auf echter Hardware zutage.
Die Hülle wurde in Swift neu gebaut, Inhalt und Mitglieder blieben unangetastet.
Die iOS-App hat ein KI-Agent auf einen aktuellen nativen Aufbau (Swift + WKWebView + aktuelle Benachrichtigungsplattform) neu gebaut. Wir haben alles durchlaufen, von der Erzeugung des Projektgerüsts bis zur Prüfung auf echter Hardware, und die Funktion mit einem Gerätebuild vom Mac aus bestätigt. Der angezeigte Inhalt (der bestehende Webdienst) und der Mitgliederbestand von rund 14.000 registrierten Geräten wurden unverändert übernommen.
| Punkt | Bisher | Nach dem Neubau |
|---|---|---|
| Benachrichtigungsweg | Benachrichtigungsverfahren der vorigen Generation (eingestellt – Versand nicht möglich) | Aktuelle Zustellplattform + Authentifizierungsschlüssel im neuen Verfahren |
| App-Hülle | Native Umsetzung einer alten Generation | Mit Swift + WKWebView neu erzeugt |
| Oberfläche (Inhalt) | Zeigt den bestehenden Webdienst an | Bleibt unverändert (Mitgliederbestände erhalten) |
| Fehler auf echter Hardware | Verstümmelter japanischer Text u. a. | Schriften, Badges und Generationsunterschiede einzeln behandelt |
Den alten Server haben wir modernisiert, ohne ihn zu ersetzen.
Der für beide Betriebssysteme entscheidende Punkt war der Server auf der Senderseite. Dieser Server läuft in einer sehr alten Laufzeitumgebung, sodass sich die aktuellen offiziellen Werkzeuge dort nicht ohne Weiteres einsetzen lassen. Deshalb haben wir die für die Authentifizierung nötige Signaturverarbeitung selbst implementiert und die Verbindung zur aktuellen Zustellplattform hergestellt. Ohne den Server komplett auszutauschen, haben wir allein die Benachrichtigungen auf ein modernes Verfahren umgestellt.
Zusätzlich wurde die Senderseite von der gemeinsamen Basis gelöst und als eigenständiger Zustelldienst neu gebaut, sodass sich die Empfänger über eine Verwaltungsoberfläche auswählen und anschreiben lassen.
Selbst eine mobile App, von der es heißt, sie laufe nicht mehr, lässt sich mit einem einzigen Neubau in den laufenden Betrieb zurückholen: die Hülle neu bauen, Schlüssel und Mitgliederbestände übernehmen und den alten Server modernisieren. Wenn Sie eine App haben, die Sie als unberührbar aufgegeben haben, sprechen Sie uns zuerst auf eine Analyse des Vorhandenen an.
* Dieser Beitrag verallgemeinert ein reales Projekt so weit, dass weder Unternehmen noch Dienst identifizierbar sind. Die Zahlen sind Näherungswerte auf Basis von Messungen mit Stand August 2026. Dauer und Umfang der Arbeiten hängen vom Aufbau der jeweiligen App ab.