Der App Store hat Ja gesagt
Vor zwei Wochen schrieb ich „Noch am Bauen. Noch nicht fertig." Heute ist DIALØGUE live im App Store. Hier ist, wie die letzten 40 % wirklich ausgesehen haben.
Vor zwei Wochen beendete ich einen Blogbeitrag mit den Worten: „Noch am Bauen. Noch nicht fertig. Noch immer am Überlegen, was ich meiner Tochter sagen soll."
Ich hatte ein Update versprochen – entweder wenn die App im App Store landet oder wenn sie abgelehnt wird. Ich sagte damals, die Ablehnungsgeschichte könnte die interessantere sein.
DIALØGUE - AI Podcast Studio ist jetzt live im App Store – eine native SwiftUI-iOS-App, die aus jedem Thema oder PDF eine vollständig produzierte Podcast-Episode macht, gebaut mit Claude Code von jemandem, der noch nie eine Zeile Swift geschrieben hatte. Du kannst sie jetzt herunterladen.
Aber nicht beim ersten Versuch. Ich muss zugeben – ich hatte vorhergesagt, dass die Ablehnungsgeschichte interessanter werden würde als die Genehmigungsgeschichte. Ich hatte recht.
Was passierte, als Apple die erste Einreichung ablehnte?
Meine erste Einreichung wurde abgelehnt. Richtlinie 2.1 – Leistung: App-Vollständigkeit. Die In-App-Käufe waren defekt.
Apples Bewertungsnachricht war freundlich formuliert – sie bemerkten, dass es meine erste Einreichung war, gratulierten mir zum Beitritt ins Entwicklerprogramm und erklärten das Problem klar. Die IAP-Produkte warfen einen Fehler, als der Prüfer versuchte, einen Kauf durchzuführen.
Das Verrückte: Der Kaufprozess hatte in meinen eigenen Tests einwandfrei funktioniert. Das Problem lag in Apples Sandbox-Umgebung, die sich sowohl von der Entwicklungs- als auch von der Produktionsumgebung unterscheidet. Die StoreKit-Konfiguration musste exakt mit App Store Connect übereinstimmen – und meine tat es nicht. Ich hatte gegen eine lokale StoreKit-Konfigurationsdatei getestet, während der Prüfer gegen die echte Sandbox arbeitete.
Ich habe es noch am selben Tag behoben, erneut eingereicht, und es wurde genehmigt. Kurz darauf habe ich ein v1.0.1-Bugfix-Update veröffentlicht, das ebenfalls problemlos durchkam.
Drei Einreichungen insgesamt. Eine Ablehnung. Die Ablehnung hat mir mehr über den App-Store-Prozess beigebracht als beide Genehmigungen zusammen. Das ist das Muster, oder? Misserfolge sind immer lehrreicher als Erfolge.
Wie sehen die „letzten 40 %" wirklich aus?
Im ursprünglichen Beitrag schrieb ich, dass die KI dich 60 % des Weges bringt und die verbleibenden 40 % vollständig menschliche Arbeit sind. Jetzt kann ich konkreter werden – ich habe das Git-Log als Beweis.
16 Commits. 57 geänderte Dateien. 4.886 hinzugefügte Zeilen. Die App wuchs von 69 Swift-Dateien auf 88, von 7.568 Zeilen auf 11.459. Das sind fast 4.000 Zeilen „Politur".
Was diese 16 Commits tatsächlich enthielten – grob in der Reihenfolge, in der sie entstanden:
Die Test-Suite, die von Anfang an hätte existieren sollen
Das ursprüngliche Gerüst hatte null Tests. Null. Claude hatte 69 Dateien Produktionscode gebaut – und keinen einzigen Test. Mein erster echter Commit nach dem ursprünglichen Beitrag fügte 176 Unit-Tests und 19 Integrationstests hinzu, die gegen eine lokale Supabase-Instanz laufen.
Das Schreiben dieser Tests hat sofort echte Fehler aufgedeckt: Show-Model-Decode-Fehler durch nicht vorhandene Datenbankspalten, AudioPlayer, der am Ende eines Tracks nicht zurückgesetzt wurde, eine Bibliotheks-Reload-Race-Condition und ein fehlender Nil-UUID-Guard im Erstellungsassistenten. Jeder dieser Fehler wäre in der Produktion ein Absturz gewesen.
Ich glaube, das ist ein Muster, das einen Namen verdient: KI generiert Code ohne Test-Infrastruktur. Nicht weil sie keine Tests schreiben kann – Claude ist großartig darin, Tests zu schreiben, wenn man es danach fragt – sondern weil der initiale Scaffold-Prompt immer „Bau die App" heißt, nicht „Bau die App mit umfassenden Tests." Die Tests kamen daher, weil ich entschied, dass ich ohne sie nicht komfortabel liefern wollte.
Studio: Das Feature, das kaum ein Stub war
Das ursprüngliche „Studio"-Feature für wiederkehrende Shows war ein Platzhalter. Zwei Commits später war es ein echtes Produkt: Show-Erstellung mit Template-Grids, Episodenverwaltung mit Status-Badges und Aktionsschaltflächen, Bearbeitungs- und Lösch-Workflows, Zeitplan-Konfiguration mit Zeitzonen-Auswahl und Stimmanpassungsblättern.
Dann kam Studio Phase 2: Überarbeitung der Show-Detailansicht, episodenweises Wiederholen/Löschen, manuelle Episodengenerierung mit Guthaben-Prüfungen. Dazu 8 neue XCUITests, die sicherstellen, dass alles von Anfang bis Ende funktioniert.
Genau das meinte ich mit „die KI hat eine Codebasis gebaut, kein Produkt." Das Studio-Feature hat kompiliert. Es hat einen Bildschirm gerendert. Aber man konnte damit keine wiederkehrende Podcast-Show wirklich verwalten.
Der Audio-Player: Neu gedacht
Im ursprünglichen Beitrag hatte ich erwähnt, dass ich den Mini-Player gelöscht hatte. Stellt sich heraus: Ich lag falsch – ich habe am Ende einen besseren Mini-Player gebaut. Das finale Design hat eine persistente Mini-Player-Leiste oberhalb der Tab-Leiste mit Fortschrittsanzeige, Skip-Steuerelementen und Play/Pause. Tippt man darauf, öffnet sich ein erweitertes „Now Playing"-Blatt mit einem ziehbaren Schieberegler, einem Geschwindigkeitswahlschalter (0,5x bis 2x), Transport-Steuerelementen und einer Klangring-Artwork-Animation.
Der knifflige Teil war der isSeeking-Zustand – ohne ihn kämpfen die Position des Schiebereglers und der Audio-Observer gegeneinander und erzeugen ein ruckeliges Durcheinander. Das ist eine einzige Zeile Zustand, für deren Diagnose ich eine Stunde gebraucht habe.
Ich habe außerdem Offline-Downloads mit umgebungsbewusstem UX hinzugefügt: ein grünes Symbol bei heruntergeladenen Episoden in der Bibliothek, ein Abschluss-Toast, ein „Downloaded"-Label im Now Playing und Wischen zum Entfernen des Downloads. Der DownloadManager hatte eine Temp-File-Race-Condition im URLSession-Delegate, die stille Fehler verursachte – die Lösung war ein synchrones File-Move innerhalb des Callbacks. Nicht die Art von Fehler, die im Code-Review auftaucht.
Sicherheitshärtung auf jeder Ebene
Das war ernüchternd. Ein Sicherheitsaudit des gesamten Stacks – nicht nur der iOS-App – deckte Schwachstellen auf mehreren Ebenen auf: übermäßig berechtigte Datenbankfunktionen, Authentifizierungs-Grenzfälle, Lücken bei der Token-Verifizierung und Probleme bei der Eingabevalidierung in mehreren Backend-Services.
Nichts davon steckte im iOS-Swift-Code. Es steckte im Backend, mit dem die iOS-App kommuniziert. Aber eine iOS-App zu veröffentlichen bedeutet, dass dein gesamter Stack jetzt in den Taschen deiner Nutzer steckt. Das hat die Einsätze für alles erhöht. Code, der „für eine Web-App gut genug war", fühlte sich plötzlich inakzeptabel an, als er durch Apples Review-Prozess ging und in eine native App einging, die Menschen mit sich tragen.
StoreKit: Der Einreichungskiller
StoreKit-Sandbox-Tests sind ein eigenes Universum – und genau das hat meine erste Einreichung zum Scheitern gebracht. Die Sandbox-Umgebung verhält sich anders als die Produktion. Transaktionen bleiben manchmal für immer „ausstehend". Die Xcode-StoreKit-Konfigurationsdatei muss manuell synchronisiert werden. Ich habe einen ganzen Abend damit verbracht, einen Kaufprozess zu debuggen, der im Code einwandfrei funktionierte, aber in der Sandbox lautlos scheiterte – es stellte sich heraus, dass die Produkt-IDs in App Store Connect ein abschließendes Leerzeichen hatten. Ein einziges Leerzeichen.
Apples Prüfer ist auf einen Sandbox-Fehler gestoßen, weil meine StoreKit-Konfiguration nicht mit App Store Connect synchronisiert war. Der Kaufprozess hat in meinen lokalen Tests einwandfrei funktioniert – aber der Prüfer traf die echte Sandbox, nicht meine lokale StoreKit-Konfigurationsdatei. Ich habe es noch am selben Tag behoben, aber das ist ein perfektes Beispiel dafür, wie die Lücke zwischen „funktioniert auf meinem Rechner" und „funktioniert in Apples Umgebung" alles andere als trivial ist.
Die Kaufverifizierungskette war ein eigenes Projekt: Die iOS-App sendet eine JWS-Darstellung (JSON Web Signature) der Transaktion an eine serverseitige Funktion, die eine vollständige kryptografische Kettenverifizierung von Apples signiertem Beleg durchführt. Nicht nur Dekodierung – echte Signaturvalidierung. Das hat zwei dedizierte Commits gebraucht, um es richtig hinzubekommen.
Datenschutz und App-Store-Compliance
Datenschutz und Compliance sind Formulare, Entscheidungen und Kontrollkästchen mit rechtlichen Implikationen – und keine KI kann sie für dich ausfüllen. App Tracking Transparency-Erklärungen, Datenschutz-Nährwertkennzeichnungen, Export-Compliance für Verschlüsselung (ja, HTTPS zählt), Inhaltsrechte, Turnstile-Captcha-Integration. Claude Code kann Swift schreiben, aber es kann dir nicht sagen, ob deine Datenerfassungspraktiken ein „Data Used to Track You"-Label erfordern.
Vollständige MFA und Lokalisierung
Die ursprüngliche MFA-Implementierung war ein defekter Stub – leere Faktor-IDs, nur ein Verifizierungsfluss. Ich habe sie als vollständigen TOTP-Lebenszyklus neu geschrieben: Registrierung, QR-Code scannen (native CoreImage-Generierung), verifizieren, Status anzeigen, deaktivieren. Das ist eine 394-zeilige MFAView.swift, die vorher nicht existiert hat.
Lokalisierung in 7 Sprachen bedeutete 253 UI-Strings, übersetzt ins Englische, Spanische, Französische, Japanische, Koreanische, Vietnamesische und Chinesische. Claude hat die Übersetzungen gemacht, und die meisten waren gut. Aber „meistens gut" bedeutet auf Japanisch, dass man vielleicht eine Schaltflächenbeschriftung hat, die grammatikalisch korrekt ist, aber klingt, als hätte ein Roboter sie geschrieben. Ein paar solcher Fälle habe ich entdeckt, indem ich die Sprache meines Telefons gewechselt und die App tatsächlich benutzt habe. Das ist die Art von Test, die KI nicht für dich machen kann – noch nicht.
Was kannst du mit der DIALØGUE-iOS-App machen?
Für alle, die die ursprüngliche Build-Geschichte nicht gelesen haben: DIALØGUE gibt dir ein Thema – oder du lädst ein PDF hoch – und es produziert eine vollständig recherchierte, geskriptete, vertonte Podcast-Episode. Zwei KI-Hosts führen ein natürliches Gespräch über dein Thema, gestützt auf echte Recherche. Kein Mikrofon nötig.
Die iOS-App umfasst:
- 5-Schritt-Erstellungsassistent – Thema, Format, Anpassung, Gliederungs-Review, Skript-Review
- 30 KI-Stimmen in 7 Sprachen – Englisch, Spanisch, Französisch, Japanisch, Koreanisch, Vietnamesisch, Chinesisch
- 9 Podcast-Formate – von Tech News Analysis bis Investigative Comedy
- Audio-Wiedergabe mit Sperrbildschirm-Steuerung – Hintergrundwiedergabe funktioniert einfach
- Apple Sign-In, Google OAuth und E-Mail-Auth
- In-App-Käufe – guthabenbasiert, kein Abo: 4 Credits für 4,99 $, 9 für 9,99 $, 18 für 19,99 $
- Studio – richte wiederkehrende Shows ein, die automatisch frische Episoden generieren
- PDF-Upload – Forschungsarbeiten, Berichte, Bücher als Quellmaterial
Es ist eine echte native SwiftUI-App. Kein Web-Wrapper. Kein React Native. Was mit 69 Swift-Dateien begann, sind jetzt 88 Dateien und 11.459 Zeilen Code, abgesichert durch 195 Tests. Ich bin wirklich stolz, das zu veröffentlichen.
Wie falsch lag meine ursprüngliche Schätzung der „Polierphase"?
Ich hatte geschrieben, die App sei „noch in der Entwicklung, in der abschließenden Polierphase." Das war technisch gesehen korrekt, aber ich hatte unterschätzt, wie viel von der „Polierphase" eigentlich neue Arbeit war.
Wenn ich jetzt auf das Git-Log schaue, klingt „16 Commits" nicht nach „Politur". Es klingt nach einer zweiten Entwicklungsphase. Die Test-Suite allein – 176 Unit-Tests und 19 Integrationstests – war ein vollständiges Projekt. Studio entwickelte sich von einem Stub zu einem vollständigen Feature. Der Audio-Player wurde zweimal neu konzipiert. Die Sicherheitshärtung berührte über 40 Backend-Funktionen. MFA wurde von Grund auf neu geschrieben.
Ich hatte auch gesagt, ich hätte den Mini-Player gelöscht. Auch dabei lag ich falsch – ich habe am Ende einen besseren gebaut, mit einem Now-Playing-Blatt, Geschwindigkeitssteuerung und Download-Indikatoren. Der ursprüngliche „Löschen"-Instinkt war richtig – der erste Mini-Player war schlecht. Aber das Konzept war richtig. Er musste nur ordentlich gebaut werden.
Ich denke, die ehrliche Aufteilung, jetzt wo ich das Gesamtbild sehe, lautet so: Die KI baut das Fundament (60 %), Menschen bauen das Produkt (30 %), und der App-Store-Einreichungsprozess lehrt einen die verbleibenden 10 %.
Ist DIALØGUE in der EU verfügbar?
DIALØGUE ist weltweit verfügbar, aber die EU-Verfügbarkeit wird noch von Apple bearbeitet. Das Digital Markets Act der EU erfordert zusätzliche Compliance-Schritte – alternative Zahlungsoffenlegungen, spezifische Datenschutzdokumentation, Angaben zur Unternehmensregistrierung. Ich habe alles eingereicht, und Apple prüft es gerade. Es sollte bald in EU-Ländern verfügbar sein.
Wenn du in der EU bist und nicht warten kannst, funktioniert die Web-App überall und hat dieselben Funktionen.
Wie schnell ist KI-gestützte iOS-Entwicklung?
Die DIALØGUE-iOS-App hat von erstem Commit bis App-Store-Genehmigung etwa zwei Wochen gedauert – einen Abend KI-Scaffolding und zwei Wochen menschliche Produktarbeit. Ich pflege diese Tabelle weiter, weil sie mich immer wieder etwas lehrt:
| Projekt | Komplexität | Bauzeit |
|---|---|---|
| DIALØGUE v1 | MVP-Podcast-Generator | ~6 Monate |
| STRAŦUM | 10 KI-Agenten, 11 Frameworks, Multi-Tenant | 75 Tage |
| Site-Redesign | WordPress-Frontend-Überarbeitung | 3 Tage |
| DIALØGUE v2 | Vollständiger Web-App-Umbau | 14 Tage |
| Blog-Migration | WordPress → Next.js, 490 Posts, Sydney RAG | 4 Tage |
| DIALØGUE iOS | Native iOS-App, Swift zum ersten Mal | ~2 Wochen (Gerüst: ein Abend) |
Die Lücke zwischen Gerüst und Veröffentlichung bei DIALØGUE iOS betrug etwa zwei Wochen. Das Gerüst selbst war ein Abend. Dieses Verhältnis – ein Abend KI-Arbeit, zwei Wochen menschliche Arbeit – sagt dir alles darüber, wo wir gerade mit KI-gestützter Entwicklung stehen.
Der KI-Teil wird immer schneller. Der menschliche Teil bleibt ungefähr gleich. Das habe ich vor zwei Wochen geschrieben, und es stimmt immer noch.
Welche Fähigkeiten zählen, wenn die KI den Code schreibt?
Im ursprünglichen Beitrag suchte ich noch nach dem richtigen Ratschlag. „Lern, die Person zu sein, die den Simulator öffnet" war das Beste, was ich hatte.
Jetzt, wo ich das Ding tatsächlich geliefert habe, glaube ich, ich kann etwas konkreter sein.
Die App existiert wegen dreier Dinge, die die KI nicht tun konnte:
-
Ich habe das Produkt benutzt. Nicht getestet. Benutzt. Podcasts erstellt. Sie auf dem Weg zur Arbeit gehört. Bemerkt, dass der Gliederungs-Review-Bildschirm Forschungsquellen anzeigen musste, weil ich wissen wollte, woher die Fakten stammten.
-
Ich habe Urteilsentscheidungen getroffen, die keine eindeutig richtigen Antworten haben. Den Mini-Player löschen oder behalten? Wie viel Anpassung ist zu viel in einem Erstellungsassistenten? Soll das Studio-Feature ein Tab oder ein Abschnitt sein? Das sind keine technischen Entscheidungen. Das sind Geschmacksentscheidungen. Und Geschmack entsteht durch die Nutzung vieler Produkte – großartige und schreckliche – und durch die Entwicklung eines Instinkts dafür, was sich richtig anfühlt.
-
Ich habe ein für Menschen konzipiertes System navigiert. App Store Connect, Datenschutzerklärungen, Export-Compliance, Screenshot-Anforderungen – das alles lässt sich nicht automatisieren. Es erfordert Lesen, Kontext verstehen und Urteilsentscheidungen über rechtliche und geschäftliche Implikationen treffen. Diese Fähigkeit – komplexe menschliche Systeme zu navigieren – wird nicht verschwinden.
Der aktualisierte Ratschlag lautet also vielleicht: Lern, Dinge tief zu nutzen, entwickle Geschmack durch Qualitätsbewusstsein, und gewöhne dich daran, Systeme zu navigieren, die nicht dafür ausgelegt wurden, einfach zu sein.
Das ist konkreter als „lern kritisch zu denken." Ich glaube, es trifft die Wahrheit besser. Ob es reicht, bin ich mir noch nicht sicher.
Wie lade ich DIALØGUE herunter?
Die App ist kostenlos mit In-App-Guthabenkäufen. Kein Abo.
Weltweit verfügbar – die EU-Verfügbarkeit wird von Apple bearbeitet und sollte bald live sein. Die Web-App ist überall verfügbar.
Häufig gestellte Fragen
Ist DIALØGUE im App Store verfügbar?
Ja! DIALØGUE - AI Podcast Studio ist seit März 2026 live im App Store. Es ist ein kostenloser Download mit In-App-Guthabenkäufen (4 Credits für 4,99 $, 9 für 9,99 $, 18 für 19,99 $). Weltweit verfügbar – die EU-Verfügbarkeit wurde eingereicht und wird von Apple bearbeitet.
Ist es in der EU verfügbar?
Es wurde eingereicht und wird von Apple bearbeitet. Das Digital Markets Act der EU erfordert zusätzliche Compliance-Schritte, und ich habe den Papierkram erledigt – warte jetzt nur noch auf Apples Überprüfung. Es sollte bald verfügbar sein. In der Zwischenzeit funktioniert die Web-App überall, einschließlich der EU.
Hat Apple es abgelehnt?
Ja – die erste Einreichung wurde wegen defekter In-App-Käufe abgelehnt (Richtlinie 2.1: App-Vollständigkeit). Die StoreKit-Sandbox-Konfiguration war nicht mit App Store Connect synchronisiert, sodass Käufe während der Überprüfung einen Fehler warfen. Ich habe es noch am selben Tag behoben, erneut eingereicht, und es wurde genehmigt. Dann ist auch v1.0.1 durchgekommen. Drei Einreichungen insgesamt, eine Ablehnung. Die Ablehnung hat mir mehr beigebracht als beide Genehmigungen zusammen.
Wie lange hat der gesamte Prozess gedauert?
Etwa zwei Wochen vom ursprünglichen Blogbeitrag bis zur App-Store-Genehmigung. Claude Code hat 69 Swift-Dateien in einem Abend als Gerüst erstellt. Die verbleibenden 16 Commits fügten 4.886 Zeilen über 57 Dateien hinzu – Tests, Studio-Features, Audio-Player-Redesign, MFA-Neuentwicklung, Sicherheitshärtung, StoreKit-Verifizierung, Lokalisierung und der App-Store-Einreichungsprozess. Die App wurde mit 88 Dateien und 11.459 Zeilen sowie 195 Tests veröffentlicht.
Was war der schwierigste Teil der letzten 40 %?
StoreKit-Sandbox-Tests. Die Lücke zwischen „das funktioniert im Code" und „das funktioniert in Apples Transaktionssystem" ist enorm. Sandbox-Transaktionen verhalten sich anders als in der Produktion, Produkt-IDs müssen exakt übereinstimmen (bis hin zu abschließenden Leerzeichen), und die Feedback-Schleife ist langsam – man kann einfach keinen Unit-Test dafür ausführen.
Kann ich noch die Web-App nutzen?
Absolut. podcast.chandlernguyen.com hat dieselben Funktionen und läuft auf jedem Gerät. Die iOS-App bietet native Annehmlichkeiten – Apple Sign-In, Sperrbildschirm-Steuerung, Offline-Downloads – aber das Kern-Podcast-Erlebnis ist identisch.
Ich überlege immer noch, was ich meiner Tochter sagen soll. Aber jetzt habe ich wenigstens eine veröffentlichte App, auf die ich zeigen kann, wenn ich sage: „Die menschliche Arbeit ist der schwere Teil."
Viele Grüße, Chandler
