L'App Store a dit oui
Il y a deux semaines, j'écrivais « Toujours en construction. Toujours pas terminé. » Aujourd'hui, DIALØGUE est disponible sur l'App Store. Voilà à quoi ressemblaient vraiment les 40 % restants.
Il y a deux semaines, je finissais un article avec : « Toujours en construction. Toujours pas terminé. Toujours en train de chercher quoi dire à ma fille. »
J'avais promis un suivi quand l'app arriverait sur l'App Store. Ou quand elle se ferait rejeter. J'avais dit que l'histoire du refus serait peut-être plus intéressante.
DIALØGUE - AI Podcast Studio est maintenant dispo sur l'App Store — une app iOS native en SwiftUI qui transforme n'importe quel sujet ou PDF en épisode de podcast entièrement produit, construite avec Claude Code par quelqu'un qui n'avait jamais écrit une ligne de Swift. Tu peux la télécharger maintenant.
Mais pas du premier coup. Je dois avouer — j'avais prédit que l'histoire du refus serait plus intéressante que celle de l'approbation. J'avais raison.
Quand Apple a rejeté ma première soumission
Ma première soumission s'est fait recaler. Règle 2.1 — Performance : Complétude de l'app. Les achats intégrés étaient cassés.
Le message d'Apple était poli — ils ont remarqué que c'était ma première soumission, m'ont félicité d'avoir rejoint le programme développeur, et ont bien expliqué le problème. Les achats intégrés renvoyaient une erreur quand le reviewer tentait un achat.
Le truc, c'est que le flux d'achat marchait parfaitement dans mes tests. Le problème venait de l'environnement sandbox d'Apple, qui se comporte différemment du dev et de la prod. La config StoreKit devait être exactement synchronisée avec App Store Connect — et elle ne l'était pas. Moi je testais contre un fichier de config StoreKit local, alors que le reviewer tapait dans le vrai sandbox.
J'ai corrigé le jour même, resoumis, et c'est passé. Puis j'ai poussé un correctif v1.0.1 peu après, qui est aussi passé sans encombre.
Trois soumissions au total. Un refus. Le refus m'a appris bien plus sur le process App Store que les deux approbations réunies. C'est toujours comme ça, non ? Les échecs sont toujours plus formateurs que les succès.
Les « 40 % restants », concrètement
Dans l'article original, j'ai dit que l'IA t'amène à 60 % et que les 40 % restants sont entièrement humains. Je veux être plus précis maintenant, parce que j'ai le git log pour le prouver.
16 commits. 57 fichiers modifiés. 4 886 lignes ajoutées. L'app est passée de 69 fichiers Swift à 88, de 7 568 lignes à 11 459. Presque 4 000 lignes de « peaufinage ».
Voici ce que ces 16 commits contenaient vraiment — dans l'ordre à peu près chronologique :
Les tests qui auraient dû exister dès le jour 1
Le scaffold d'origine avait zéro test. Zéro. Claude a construit 69 fichiers de code de prod sans le moindre test. Mon premier vrai commit après l'article original a ajouté 176 tests unitaires et 19 tests d'intégration tournant contre une instance Supabase locale.
Écrire ces tests a immédiatement révélé de vrais bugs : des échecs de décodage du modèle Show à cause de colonnes inexistantes en base, un AudioPlayer qui ne se réinitialisait pas en fin de piste, une race condition au rechargement de la bibliothèque, et un guard nil UUID manquant dans l'assistant de création. Chacun de ces bugs aurait causé un crash en prod.
Je pense que c'est un pattern qui mérite d'être nommé : l'IA génère du code sans infra de test. Pas parce qu'elle ne sait pas écrire des tests — Claude est excellent pour ça quand tu le demandes — mais parce que le prompt initial est toujours « construis l'app », pas « construis l'app avec des tests complets ». Les tests sont venus de ma décision que je n'étais pas à l'aise de livrer sans eux.
Studio : la feature qui n'était qu'une coquille
La feature « Studio » d'origine pour les émissions récurrentes était un placeholder. Deux commits plus tard, c'était un vrai produit : création d'émissions avec grilles de templates, gestion des épisodes avec badges de statut et boutons d'action, flux d'édition et suppression, config de programmation avec sélecteurs de fuseau horaire, et feuilles de personnalisation vocale.
Puis est venue la Phase 2 de Studio : refonte du détail des émissions, retry et suppression par épisode, génération manuelle avec vérification des crédits. Plus 8 nouveaux XCUITests pour vérifier que tout marchait de bout en bout.
C'est exactement ce que je voulais dire par « l'IA a construit une codebase, pas un produit ». La feature Studio compilait. Elle affichait un écran. Mais tu ne pouvais pas réellement gérer une émission de podcast récurrente avec.
Le lecteur audio, version 2
J'avais mentionné dans l'article original que j'avais supprimé le mini-lecteur. En fait, j'avais tort — j'ai fini par en construire un meilleur. Le design final a une barre de mini-lecteur persistante au-dessus de la tab bar avec la progression, les contrôles de saut et lecture/pause. Tu appuies dessus et tu obtiens une vue « En cours de lecture » avec un slider de seek, un sélecteur de vitesse (0,5x à 2x), des commandes de transport et une animation d'anneaux sonores.
La partie piégeuse, c'était l'état isSeeking — sans lui, la position du slider et l'observer audio se battent l'un contre l'autre, créant un truc tout saccadé. Une seule ligne d'état qui m'a pris une heure à diagnostiquer.
J'ai aussi ajouté le téléchargement hors ligne avec une UX discrète : une icône verte sur les épisodes téléchargés dans la bibliothèque, un toast de confirmation, un label « Téléchargé » dans En cours de lecture, et un swipe pour supprimer le téléchargement. Le DownloadManager avait une race condition sur les fichiers temporaires dans le delegate URLSession qui causait des échecs silencieux — le fix, c'était un déplacement de fichier synchrone dans le callback. Le genre de bug qui ne se voit pas en code review.
Sécurisation de toute la stack
Celui-là, c'était un peu déprimant. Un audit sécu de toute la stack — pas juste l'app iOS — a révélé des vulnérabilités sur plusieurs couches : des fonctions de base de données trop permissives, des edge cases d'authentification, des failles dans la vérification des tokens, et des problèmes de validation d'input dans plusieurs services backend.
Aucun de ces problèmes n'était dans le code Swift. Ils étaient dans le backend avec lequel l'app iOS communique. Mais livrer une app iOS, ça veut dire que toute ta stack est maintenant dans la poche de tes utilisateurs. Ça a relevé les enjeux sur tout. Du code qui « marchait bien » pour une app web semblait soudain inacceptable quand il passait par la review d'Apple et atterrissait dans une app native que les gens trimbalent partout.
StoreKit : le tueur de soumissions
Le sandbox testing de StoreKit, c'est un univers à part, et c'est exactement ce qui a fait recaler ma première soumission. L'environnement sandbox se comporte différemment de la prod. Les transactions restent parfois « en attente » indéfiniment. Le fichier de config StoreKit dans Xcode nécessite une synchro manuelle. J'ai passé toute une soirée à débugger un flux d'achat qui marchait parfaitement dans le code mais échouait silencieusement dans le sandbox — en fait, les identifiants de produit dans App Store Connect avaient un espace en trop à la fin. Un seul espace.
Le reviewer d'Apple a rencontré une erreur sandbox parce que ma config StoreKit n'était pas synchro avec App Store Connect. Le flux d'achat marchait très bien dans mes tests locaux — mais le reviewer tapait dans le vrai sandbox, pas mon fichier de config local. J'ai corrigé le jour même, mais c'est l'exemple parfait de l'écart entre « ça marche sur ma machine » et « ça marche chez Apple » — et cet écart est loin d'être anodin.
La chaîne de vérification des achats, c'était un projet en soi : l'app iOS envoie une représentation JWS (JSON Web Signature) de la transaction à une fonction côté serveur, qui effectue une vérification cryptographique complète de la chaîne du reçu signé d'Apple. Pas juste du décodage — une vraie vérification de signature. Il a fallu deux commits dédiés pour que ça tourne.
Confidentialité et conformité App Store
La confidentialité et la conformité, c'est des formulaires, des décisions et des cases à cocher avec des implications légales — et aucune IA ne peut les remplir à ta place. Déclarations App Tracking Transparency, étiquettes nutritionnelles de confidentialité, conformité export pour le chiffrement (oui, HTTPS ça compte), droits sur le contenu, intégration du captcha Turnstile. Claude Code sait écrire du Swift, mais il ne peut pas te dire si tes pratiques de collecte de données nécessitent un label « Données utilisées pour te pister ».
MFA complet et localisation
L'implémentation MFA d'origine, c'était une ébauche cassée — des ID de facteur vides, un flux de vérification seulement. Je l'ai réécrite en cycle de vie TOTP complet : inscription, scan de QR code (génération native CoreImage), vérification, affichage du statut, désactivation. Ça donne un MFAView.swift de 394 lignes qui n'existait pas avant.
La localisation en 7 langues, ça a voulu dire 253 chaînes d'interface traduites en anglais, espagnol, français, japonais, coréen, vietnamien et chinois. Claude a fait les traductions, et elles étaient globalement bonnes. Mais « globalement bonnes » en japonais, ça veut dire que tu peux te retrouver avec un libellé de bouton grammaticalement correct mais qui sonne robot. J'en ai repéré plusieurs en changeant la langue de mon téléphone et en utilisant vraiment l'app. C'est le genre de test que l'IA ne peut pas faire à ta place — pas encore.
Ce que tu peux faire avec DIALØGUE sur iOS
Pour ceux qui n'ont pas lu l'histoire de la construction, voici ce que fait DIALØGUE :
Tu lui donnes un sujet — ou tu uploades un PDF — et elle produit un épisode de podcast entièrement recherché, scripté et doublé. Deux hôtes IA ont une conversation naturelle sur ton sujet, basée sur de vraies recherches. Pas de micro nécessaire.
L'app iOS inclut :
- Assistant de création en 5 étapes — sujet, format, personnalisation, revue du plan, revue du script
- 30 voix IA en 7 langues — anglais, espagnol, français, japonais, coréen, vietnamien, chinois
- 9 formats de podcast — du Tech News Analysis à l'Investigative Comedy
- Lecture audio avec commandes sur l'écran de verrouillage — la lecture en arrière-plan juste marche
- Apple Sign-In, Google OAuth, et auth par email
- Achats intégrés — basés sur des crédits, sans abonnement : 4 crédits pour 4,99 $, 9 pour 9,99 $, 18 pour 19,99 $
- Studio — configure des émissions récurrentes qui génèrent de nouveaux épisodes automatiquement
- Upload de PDF — articles de recherche, rapports, livres comme source
C'est une vraie app iOS native en SwiftUI. Pas un wrapper web. Pas du React Native. Ce qui a commencé avec 69 fichiers Swift, c'est maintenant 88 fichiers et 11 459 lignes de code, avec 195 tests derrière. Je suis sincèrement fier de l'avoir livrée.
À quel point je me suis trompé sur la « phase de peaufinage »
J'avais écrit que l'app était « toujours en développement, dans la phase de peaufinage finale ». Techniquement vrai, mais j'avais sous-estimé à quel point le « peaufinage » était en réalité du travail neuf.
Quand je regarde le git log maintenant, 16 commits ça ne ressemble pas à du « peaufinage ». Ça ressemble à une deuxième phase de dev. La suite de tests à elle seule — 176 tests unitaires et 19 tests d'intégration — c'était un projet entier. Studio est passé d'une coquille à une feature complète. Le lecteur audio a été repensé deux fois. La sécurisation a touché plus de 40 fonctions backend. La MFA a été réécrite de zéro.
J'avais aussi dit que j'avais supprimé le mini-lecteur. Encore faux — j'ai fini par en construire un meilleur, avec une vue Now Playing, des contrôles de vitesse et des indicateurs de téléchargement. L'instinct d'origine de « le supprimer » était juste — le premier mini-lecteur était mauvais. Mais le concept était bon. Il fallait juste le construire correctement.
Je pense que la répartition honnête, maintenant que je vois le tableau complet, c'est : l'IA construit la fondation (60 %), les humains construisent le produit (30 %), et le process de soumission App Store t'enseigne les 10 % restants.
DIALØGUE est-elle dispo dans l'UE ?
DIALØGUE est dispo dans le monde entier, mais la disponibilité dans l'UE est encore en cours de traitement chez Apple. Le Digital Markets Act de l'UE exige des étapes de conformité supplémentaires — déclarations sur les paiements alternatifs, documentation de confidentialité spécifique, détails d'enregistrement de l'entreprise. J'ai tout soumis, et Apple est en train d'examiner. Ça devrait être dispo dans les pays de l'UE bientôt.
Si tu es dans l'UE et que tu ne peux pas attendre, l'app web marche partout et propose les mêmes fonctionnalités.
Le dev iOS assisté par IA, ça va à quelle vitesse ?
L'app iOS DIALØGUE a pris environ deux semaines du premier commit à l'approbation App Store — une soirée de scaffold IA et deux semaines de travail humain sur le produit. Je continue de maintenir ce tableau parce qu'il continue de m'apprendre des choses :
| Projet | Complexité | Temps de build |
|---|---|---|
| DIALØGUE v1 | Générateur de podcast MVP | ~6 mois |
| STRAŦUM | 10 agents IA, 11 frameworks, multi-tenant | 75 jours |
| Refonte du site | Refonte du frontend WordPress | 3 jours |
| DIALØGUE v2 | Rebuild complet de l'app web | 14 jours |
| Migration du blog | WordPress → Next.js, 490 articles, Sydney RAG | 4 jours |
| DIALØGUE iOS | App iOS native, première fois en Swift | ~2 semaines (scaffold : une soirée) |
L'écart scaffold-livraison pour DIALØGUE iOS, c'était environ deux semaines. Le scaffold en lui-même, une soirée. Ce ratio — une soirée de travail IA, deux semaines de travail humain — te dit tout sur où on en est avec le dev assisté par IA en ce moment.
La partie IA continue de s'accélérer. La partie humaine reste à peu près la même. Je l'ai écrit il y a deux semaines et c'est toujours vrai.
Quelles compétences comptent quand l'IA écrit le code ?
Dans l'article original, je cherchais encore le bon conseil. « Apprends à être la personne qui ouvre le Simulateur » — c'était le mieux que j'avais.
Maintenant que j'ai vraiment livré le truc, je pense pouvoir être un peu plus précis.
L'app existe grâce à trois choses que l'IA ne pouvait pas faire :
-
J'ai utilisé le produit. Pas testé. Utilisé. Créé des podcasts. Écouté pendant mes trajets. Remarqué que l'écran de revue du plan devait afficher les sources de recherche parce que je voulais savoir d'où venaient les faits.
-
J'ai pris des décisions qui n'ont pas de bonne réponse. Supprimer le mini-lecteur ou le garder ? Combien de personnalisation c'est trop dans un assistant de création ? Le Studio, ça devrait être un onglet ou une section ? Ce ne sont pas des décisions d'ingénierie. Ce sont des décisions de goût. Et le goût, ça vient d'avoir utilisé beaucoup de produits — des excellents et des terribles — et d'avoir développé un instinct pour ce qui sonne juste.
-
J'ai navigué dans un système conçu pour les humains. App Store Connect, les déclarations de confidentialité, la conformité export, les exigences de captures d'écran — rien de tout ça ne peut être automatisé. Ça demande de lire, de comprendre le contexte, et de trancher sur les implications légales et business. Cette compétence — naviguer dans des systèmes humains complexes — elle ne va pas disparaître.
Donc peut-être que le conseil mis à jour, c'est : apprends à utiliser les choses en profondeur, développe le goût en te souciant de la qualité, et habitue-toi à naviguer dans des systèmes qui n'ont pas été conçus pour être simples.
C'est plus concret que « apprends à penser de façon critique ». Je pense que c'est plus proche de la vérité. Je ne suis toujours pas sûr que ce soit suffisant.
Comment télécharger DIALØGUE ?
L'app est gratuite avec des achats de crédits intégrés. Pas d'abonnement.
Dispo dans le monde entier — la disponibilité dans l'UE est en cours de traitement chez Apple et devrait arriver bientôt. L'app web est dispo partout.
Questions fréquentes
DIALØGUE est-elle dispo sur l'App Store ?
Oui ! DIALØGUE - AI Podcast Studio est dispo sur l'App Store depuis mars 2026. C'est un téléchargement gratuit avec achats de crédits intégrés (4 crédits pour 4,99 $, 9 pour 9,99 $, 18 pour 19,99 $). Dispo dans le monde entier — la disponibilité dans l'UE a été soumise et est en cours de traitement chez Apple.
Est-elle dispo dans l'UE ?
C'est soumis et en cours de traitement chez Apple. Le Digital Markets Act de l'UE exige des étapes de conformité supplémentaires, et j'ai rempli toute la paperasse — j'attends juste la review d'Apple. Ça devrait être dispo bientôt. En attendant, l'app web marche partout, y compris dans l'UE.
Apple l'a rejetée ?
Oui — la première soumission s'est fait recaler pour des achats intégrés cassés (Règle 2.1 : Complétude de l'app). La config sandbox StoreKit n'était pas synchro avec App Store Connect, donc les achats renvoyaient une erreur en review. J'ai corrigé le jour même, resoumis, et c'est passé. Puis la v1.0.1 est passée aussi. Trois soumissions au total, un refus. Le refus m'a appris plus que les deux approbations réunies.
Combien de temps a pris tout le process ?
Environ deux semaines de l'article de blog original à l'approbation App Store. Claude Code a scaffoldé 69 fichiers Swift en une soirée. Les 16 commits restants ont ajouté 4 886 lignes sur 57 fichiers — tests, features Studio, refonte du lecteur audio, réécriture MFA, sécurisation, vérification StoreKit, localisation, et le process de soumission App Store. L'app a été livrée avec 88 fichiers et 11 459 lignes, 195 tests.
Le plus dur dans les 40 % restants ?
Le sandbox testing StoreKit. L'écart entre « ça marche dans le code » et « ça marche dans le système de transactions Apple » est énorme. Les transactions sandbox se comportent différemment de la prod, les identifiants de produit doivent correspondre exactement (jusqu'aux espaces en trop), et la boucle de feedback est lente — tu ne peux pas juste lancer un test unitaire.
Je peux toujours utiliser l'app web ?
Absolument. podcast.chandlernguyen.com a les mêmes fonctionnalités et marche sur n'importe quel appareil. L'app iOS ajoute des avantages natifs — Apple Sign-In, commandes sur l'écran de verrouillage, téléchargements hors ligne — mais l'expérience de génération de podcast au coeur, c'est identique.
Toujours en train de chercher quoi dire à ma fille. Mais au moins, j'ai maintenant une app livrée à montrer quand je dis « le travail humain, c'est la partie difficile ».
À bientôt, Chandler
