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. So sahen die letzten 40 % wirklich aus.
Vor zwei Wochen endete ein Blogpost mit: „Noch am Bauen. Noch nicht fertig. Noch immer am Überlegen, was ich meiner Tochter sagen soll."
Ich hatte ein Update versprochen — sobald die App im App Store landet. Oder abgelehnt wird. Ich meinte damals, die Ablehnungsstory könnte interessanter sein.
DIALØGUE - AI Podcast Studio ist jetzt live im App Store — eine native SwiftUI-iOS-App, die aus jedem Thema oder PDF eine fertig produzierte Podcast-Episode macht, gebaut mit Claude Code von jemandem, der vorher noch nie Swift geschrieben hat. Du kannst sie jetzt herunterladen.
Aber nicht beim ersten Anlauf. Ich muss zugeben — ich hatte vorhergesagt, dass die Ablehnungsstory spannender wird als die Erfolgsstory. Ich hatte recht.
Apple hat abgelehnt — und dann?
Meine erste Einreichung wurde abgelehnt. Richtlinie 2.1 — Performance: App Completeness. Die In-App-Käufe waren kaputt.
Apples Review-Nachricht war nett formuliert — sie merkten an, dass es meine erste Einreichung war, gratulierten zum Beitritt ins Entwicklerprogramm und erklärten das Problem klar. Die IAP-Produkte warfen einen Fehler, als der Reviewer versuchte, einen Kauf abzuschließen.
Die Sache ist: Der Kaufprozess hatte in meinen 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 Reviewer die echte Sandbox nutzte.
Noch am selben Tag behoben, erneut eingereicht — durchgekommen. Kurz darauf ein v1.0.1-Bugfix-Update nachgeschoben, das ebenfalls problemlos durchlief.
Drei Einreichungen insgesamt. Eine Ablehnung. Die Ablehnung hat mir mehr über den App-Store-Prozess beigebracht als beide Genehmigungen zusammen. Kennt man das Muster? Fehler sind immer lehrreicher als Erfolge.
Die „letzten 40 %" — was steckt wirklich dahinter?
Im ursprünglichen Post schrieb ich, dass die KI dich 60 % des Weges bringt und die restlichen 40 % reine Menschenarbeit sind. Jetzt kann ich konkreter werden — das Git-Log beweist es.
16 Commits. 57 geänderte Dateien. 4.886 neue Zeilen. Die App wuchs von 69 Swift-Dateien auf 88, von 7.568 Zeilen auf 11.459. Fast 4.000 Zeilen „Feinschliff".
Was in diesen 16 Commits wirklich steckte — grob in der Reihenfolge, wie sie entstanden:
Tests — die von Tag eins hätten da sein sollen
Das Scaffold hatte null Tests. Null. Claude hatte 69 Dateien Produktionscode gebaut — ohne einen einzigen Test. Mein erster richtiger Commit nach dem ursprünglichen Post fügte 176 Unit-Tests und 19 Integrationstests hinzu, laufend gegen eine lokale Supabase-Instanz.
Die Tests haben sofort echte Bugs aufgedeckt: Show-Model-Decode-Fehler durch nicht existierende Datenbankspalten, AudioPlayer, der am Trackende nicht zurücksetzte, eine Race-Condition beim Library-Reload und ein fehlender Nil-UUID-Guard im Erstellungsassistenten. Jeder dieser Fehler wäre in Production ein Crash 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, wenn man danach fragt — sondern weil der initiale Prompt immer „Bau die App" heißt, nicht „Bau die App mit umfassenden Tests." Die Tests kamen, weil ich entschied: Ohne sie ship ich nicht.
Studio — vom Stub zum echten Feature
Das ursprüngliche „Studio" 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 Action-Buttons, Edit- und Delete-Workflows, Zeitplan-Konfiguration mit Zeitzonen-Picker und Voice-Customization-Sheets.
Dann kam Studio Phase 2: Redesign der Show-Detailansicht, Retry/Delete pro Episode, manuelle Episodengenerierung mit Credit-Check. Dazu 8 neue XCUITests, um sicherzustellen, dass alles End-to-End funktioniert.
Genau das meinte ich mit „die KI hat eine Codebasis gebaut, kein Produkt." Das Studio-Feature kompilierte. Es renderte einen Screen. Aber eine wiederkehrende Podcast-Show konnte man damit nicht wirklich managen.
Audio-Player — komplett neu gedacht
Im ursprünglichen Post hatte ich erwähnt, dass ich den Mini-Player gelöscht hatte. Stellt sich raus: Ich lag falsch — am Ende habe ich einen besseren Mini-Player gebaut. Das finale Design hat eine persistente Mini-Player-Bar oberhalb der Tab-Bar mit Progress, Skip-Controls und Play/Pause. Tippt man drauf, öffnet sich ein „Now Playing"-Sheet mit Seek-Slider, Speed-Selector (0,5x bis 2x), Transport-Controls und einer Sound-Ring-Animation.
Der knifflige Teil war der isSeeking-State — ohne ihn kämpfen Slider-Position und Audio-Observer gegeneinander und erzeugen ein ruckeliges Chaos. Eine einzige Zeile State, für deren Diagnose ich eine Stunde gebraucht habe.
Dazu kamen Offline-Downloads mit durchdachtem UX: ein grünes Icon bei heruntergeladenen Episoden in der Library, ein Completion-Toast, ein „Downloaded"-Label im Now Playing und Swipe-to-Delete für Downloads. Der DownloadManager hatte eine Temp-File-Race-Condition im URLSession-Delegate, die stille Fehler verursachte — die Lösung war ein synchrones File-Move im Callback. Nicht die Art Bug, die im Code-Review auffällt.
Security Hardening — auf jeder Ebene
Das war ernüchternd. Ein Security-Audit des gesamten Stacks — nicht nur der iOS-App — deckte Schwachstellen auf mehreren Ebenen auf: zu weit berechtigte Datenbankfunktionen, Auth-Edge-Cases, Lücken bei der Token-Verifizierung und Input-Validation-Probleme in mehreren Backend-Services.
Nichts davon steckte im iOS-Swift-Code. Alles im Backend, mit dem die iOS-App kommuniziert. Aber eine iOS-App zu shippen bedeutet: Dein gesamter Stack steckt jetzt in den Taschen deiner Nutzer. Das erhöht den Einsatz bei allem. Code, der „für eine Web-App gut genug war", fühlt sich plötzlich inakzeptabel an, wenn er durch Apples Review-Prozess geht und in einer nativen App landet, die Leute überall mit sich tragen.
StoreKit — der Submission-Killer
StoreKit-Sandbox-Testing ist ein eigenes Universum — und genau das hat meine erste Einreichung gekillt. Die Sandbox-Umgebung verhält sich anders als Production. Transaktionen bleiben manchmal ewig auf „pending". Die Xcode-StoreKit-Config muss manuell synchronisiert werden. Ich habe einen ganzen Abend damit verbracht, einen Kaufprozess zu debuggen, der im Code einwandfrei lief, aber in der Sandbox lautlos scheiterte — die Produkt-IDs in App Store Connect hatten ein Leerzeichen am Ende. Ein einziges Leerzeichen.
Apples Reviewer stieß auf einen Sandbox-Fehler, weil meine StoreKit-Config nicht mit App Store Connect synchron war. Der Kaufprozess lief in meinen lokalen Tests einwandfrei — aber der Reviewer nutzte die echte Sandbox, nicht meine lokale StoreKit-Config. Noch am selben Tag gefixt, aber ein perfektes Beispiel dafür, dass die Lücke zwischen „funktioniert auf meinem Rechner" und „funktioniert in Apples Umgebung" alles andere als trivial ist.
Die Purchase-Verification-Chain 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 Receipt durchführt. Nicht nur Decoding — echte Signaturvalidierung. Zwei dedizierte Commits, bis das richtig saß.
Privacy und App-Store-Compliance
Datenschutz und Compliance sind Formulare, Entscheidungen und Checkboxen mit rechtlichen Konsequenzen — und keine KI kann sie für dich ausfüllen. App Tracking Transparency, Privacy Nutrition Labels, Export-Compliance für Verschlüsselung (ja, HTTPS zählt), Content Rights, Turnstile-Captcha-Integration. Claude Code kann Swift schreiben, aber nicht beurteilen, ob deine Datenerhebung ein „Data Used to Track You"-Label braucht.
MFA und Lokalisierung — komplett
Die ursprüngliche MFA-Implementierung war ein kaputter Stub — leere Faktor-IDs, nur Verify-Flow. Ich habe sie als vollständigen TOTP-Lifecycle neu geschrieben: Enroll, QR-Code scannen (native CoreImage-Generierung), verifizieren, Status anzeigen, deaktivieren. 394 Zeilen MFAView.swift, die vorher nicht existierten.
Lokalisierung in 7 Sprachen hieß 253 UI-Strings, übersetzt in Englisch, Spanisch, Französisch, Japanisch, Koreanisch, Vietnamesisch und Chinesisch. Claude hat die Übersetzungen gemacht, und die meisten waren gut. Aber „meistens gut" heißt auf Japanisch, dass vielleicht ein Button-Label grammatisch korrekt ist, aber klingt, als hätte ein Roboter es geschrieben. Ein paar solcher Fälle habe ich entdeckt, indem ich die Sprache meines Telefons umgestellt und die App wirklich benutzt habe. Die Art Test, die KI noch nicht für dich machen kann.
Was kann die DIALØGUE-iOS-App?
Für alle, die die ursprüngliche Build-Story nicht gelesen haben: Du gibst DIALØGUE ein Thema — oder lädst ein PDF hoch — und es produziert eine fertig 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 bietet:
- 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 Lock-Screen-Controls — Background-Playback funktioniert einfach
- Apple Sign-In, Google OAuth und E-Mail-Auth
- In-App-Käufe — Credit-basiert, kein Abo: 4 Credits für 4,99 $, 9 für 9,99 $, 18 für 19,99 $
- Studio — wiederkehrende Shows einrichten, die automatisch frische Episoden generieren
- PDF-Upload — Research-Papers, Berichte, Bücher als Quellmaterial
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 ehrlich stolz, das zu shippen.
Wie daneben lag meine „Feinschliff"-Schätzung?
Ich hatte geschrieben, die App sei „noch in der Entwicklung, in der abschließenden Feinschliff-Phase." Technisch korrekt — aber ich hatte massiv unterschätzt, wie viel davon eigentlich neue Arbeit war.
Wenn ich jetzt aufs Git-Log schaue: 16 Commits klingt nicht nach „Feinschliff". Es klingt nach einer zweiten Entwicklungsphase. Die Test-Suite allein — 176 Unit-Tests und 19 Integrationstests — war ein eigenständiges Projekt. Studio ging vom Stub zum vollen Feature. Der Audio-Player wurde zweimal komplett neu gedacht. Security Hardening betraf 40+ Backend-Funktionen. MFA wurde von Grund auf neu geschrieben.
Ich hatte auch gesagt, ich hätte den Mini-Player gelöscht. Auch da lag ich falsch — am Ende habe ich einen besseren gebaut, mit Now-Playing-Sheet, Speed-Controls und Download-Indikatoren. Der „Löschen"-Instinkt war richtig — der erste Mini-Player war schlecht. Aber das Konzept stimmte. Es musste nur vernünftig umgesetzt werden.
Die ehrliche Aufteilung, jetzt wo ich das Gesamtbild sehe: KI baut das Fundament (60 %), Menschen bauen das Produkt (30 %), und der App-Store-Submission-Prozess lehrt einen die restlichen 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. Der Digital Markets Act der EU erfordert zusätzliche Compliance-Schritte — alternative Zahlungshinweise, spezifische Datenschutzdokumentation, Angaben zur Unternehmensregistrierung. Alles eingereicht, Apple prüft gerade. 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 geht KI-gestützte iOS-Entwicklung?
DIALØGUE iOS hat vom ersten Commit bis zur App-Store-Freigabe etwa zwei Wochen gedauert — ein Abend KI-Scaffolding, zwei Wochen menschliche Produktarbeit. Ich pflege diese Tabelle weiter, weil sie mich jedes Mal etwas Neues 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, erstes Mal Swift | ~2 Wochen (Scaffold: ein Abend) |
Scaffold bis Ship bei DIALØGUE iOS: etwa zwei Wochen. Das Scaffold selbst war ein Abend. Dieses Verhältnis — ein Abend KI-Arbeit, zwei Wochen Menschenarbeit — sagt 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 Skills zählen, wenn KI den Code schreibt?
Im ursprünglichen Post suchte ich noch nach dem richtigen Rat. „Lern, die Person zu sein, die den Simulator öffnet" war das Beste, was ich hatte.
Jetzt, wo ich das Ding tatsächlich shipped habe, kann ich vielleicht etwas konkreter werden.
Die App existiert wegen drei Dingen, die die KI nicht konnte:
-
Ich habe das Produkt benutzt. Nicht getestet. Benutzt. Podcasts erstellt. Auf dem Weg zur Arbeit gehört. Gemerkt, dass der Outline-Review-Screen Quellen anzeigen muss, weil ich wissen wollte, woher die Fakten kommen.
-
Ich habe Entscheidungen getroffen, die keine richtige Antwort haben. Mini-Player löschen oder behalten? Wie viel Customization ist zu viel im Erstellungsassistenten? Studio als Tab oder als Section? Das sind keine Engineering-Entscheidungen. Das sind Geschmacksentscheidungen. Und Geschmack entsteht, indem man viele Produkte nutzt — großartige und furchtbare — und ein Gespür entwickelt für das, was sich richtig anfühlt.
-
Ich habe ein System navigiert, das für Menschen gemacht ist. App Store Connect, Privacy-Erklärungen, Export-Compliance, Screenshot-Anforderungen — nichts davon lässt sich automatisieren. Es erfordert Lesen, Kontext verstehen und Urteile über rechtliche und geschäftliche Konsequenzen fällen. Diese Fähigkeit — komplexe menschliche Systeme zu navigieren — wird nicht verschwinden.
Der aktualisierte Rat lautet also vielleicht: Lern, Dinge tief zu nutzen, entwickle Geschmack durch Qualitätsbewusstsein, und gewöhne dich daran, Systeme zu navigieren, die nicht darauf ausgelegt sind, einfach zu sein.
Konkreter als „lern kritisch zu denken." Ich glaube, es trifft die Wahrheit besser. Ob es reicht — da bin ich mir noch nicht sicher.
Wie lade ich DIALØGUE herunter?
Die App ist kostenlos, Credits kaufst du per In-App-Kauf. Kein Abo.
Weltweit verfügbar — EU-Verfügbarkeit wird von Apple bearbeitet und sollte bald live sein. Die Web-App funktioniert überall.
Häufige Fragen
Ist DIALØGUE im App Store?
Ja! DIALØGUE - AI Podcast Studio ist seit März 2026 live im App Store. Kostenloser Download mit In-App-Credit-Käufen (4 Credits für 4,99 $, 9 für 9,99 $, 18 für 19,99 $). Weltweit verfügbar — EU-Verfügbarkeit eingereicht und wird von Apple bearbeitet.
Verfügbar in der EU?
Eingereicht und bei Apple in Bearbeitung. Der Digital Markets Act erfordert zusätzliche Compliance-Schritte, und ich habe den Papierkram erledigt — warte nur noch auf Apples Review. Sollte bald verfügbar sein. Bis dahin funktioniert die Web-App überall, auch in der EU.
Hat Apple abgelehnt?
Ja — die erste Einreichung wurde wegen kaputter In-App-Käufe abgelehnt (Guideline 2.1: App Completeness). Die StoreKit-Sandbox-Config war nicht mit App Store Connect synchron, sodass Käufe beim Review einen Fehler warfen. Noch am selben Tag gefixt, erneut eingereicht, durchgekommen. v1.0.1 lief auch glatt durch. Drei Einreichungen, eine Ablehnung. Die Ablehnung hat mir mehr beigebracht als beide Approvals zusammen.
Wie lange hat das Ganze gedauert?
Etwa zwei Wochen vom ursprünglichen Blogpost bis zur App-Store-Freigabe. Claude Code hat 69 Swift-Dateien an einem Abend gescaffoldet. Die restlichen 16 Commits fügten 4.886 Zeilen über 57 Dateien hinzu — Tests, Studio-Features, Audio-Player-Redesign, MFA-Neuschrieb, Security Hardening, StoreKit-Verifizierung, Lokalisierung und der Submission-Prozess. Shipped mit 88 Dateien, 11.459 Zeilen und 195 Tests.
Was war das Härteste an den letzten 40 %?
StoreKit-Sandbox-Testing. Die Kluft zwischen „funktioniert im Code" und „funktioniert in Apples Transaktionssystem" ist riesig. Sandbox-Transaktionen verhalten sich anders als Production, Produkt-IDs müssen exakt stimmen (bis zum letzten Leerzeichen), und die Feedback-Schleife ist langsam — Unit-Tests helfen hier nicht.
Geht auch die Web-App noch?
Absolut. podcast.chandlernguyen.com hat dieselben Features und läuft auf jedem Gerät. Die iOS-App bringt native Extras — Apple Sign-In, Lock-Screen-Controls, 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 App im Store, auf die ich zeigen kann, wenn ich sage: „Die menschliche Arbeit ist der schwere Teil."
Viele Grüße, Chandler
