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 terminais un article de blog avec : « Toujours en construction. Toujours pas terminé. Toujours en train de chercher quoi dire à ma fille. »
Je promettais un suivi quand l'app atterrirait 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 disponible sur l'App Store — une application 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 dès maintenant.
Mais pas du premier coup. Je dois admettre — j'avais prédit que l'histoire du refus serait plus intéressante que celle de l'approbation. J'avais raison.
Qu'est-ce qui s'est passé quand Apple a rejeté la première soumission ?
Ma première soumission a été rejetée. Règle 2.1 — Performance : Complétude de l'application. Les achats intégrés ne fonctionnaient pas.
Le message de révision 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 clairement expliqué le problème. Les produits d'achat intégré renvoyaient une erreur quand leur évaluateur tentait d'effectuer un achat.
Voilà la chose : le flux d'achat fonctionnait parfaitement dans mes tests. Le problème venait de l'environnement sandbox d'Apple, qui se comporte différemment du développement et de la production. La configuration StoreKit devait être exactement synchronisée avec App Store Connect — et ce n'était pas le cas. Je testais contre un fichier de configuration StoreKit local, tandis que l'évaluateur frappait le vrai sandbox.
J'ai corrigé le problème le jour même, resoumis, et ça a passé. Puis j'ai expédié une mise à jour corrective v1.0.1 peu après, qui est aussi passée sans encombre.
Trois soumissions au total. Un refus. Le refus m'a appris bien plus sur le processus App Store que les deux approbations réunies. C'est le schéma habituel, non ? Les échecs sont toujours plus formateurs que les succès.
À quoi ressemblent vraiment les « 40 % restants » ?
Dans l'article original, j'ai dit que l'IA t'emmène à 60 % du chemin 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'application est passée de 69 fichiers Swift à 88, de 7 568 lignes à 11 459. C'est presque 4 000 lignes de « peaufinage ».
Voici ce que ces 16 commits contenaient vraiment — dans l'ordre approximatif où les choses se sont passées :
La suite de tests qui aurait dû exister dès le premier jour
Le scaffold d'origine avait zéro test. Zéro. Claude a construit 69 fichiers de code de production 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 de base de données inexistantes, un AudioPlayer qui ne se réinitialisait pas en fin de piste, une race condition lors du rechargement de la bibliothèque, et un guard nil UUID manquant dans l'assistant de création. Chacun de ces problèmes aurait provoqué un crash en production.
Je pense que c'est un schéma qui mérite d'être nommé : l'IA génère du code sans infrastructure de test. Pas parce qu'elle ne sait pas écrire des tests — Claude est excellent pour écrire des tests quand tu le demandes — mais parce que le prompt du scaffold initial est toujours « construis l'application », pas « construis l'application 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 fonctionnalité qui n'était qu'une ébauche
La fonctionnalité « 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 des grilles de modèles, gestion des épisodes avec des badges de statut et des boutons d'action, des flux de modification et suppression, une configuration de programmation avec des sélecteurs de fuseau horaire, et des feuilles de personnalisation vocale.
Puis vint Studio Phase 2 : refonte du détail des émissions, réessai et suppression par épisode, génération manuelle d'épisodes avec vérification des crédits. Plus 8 nouveaux XCUITests pour s'assurer que tout fonctionnait de bout en bout.
C'est exactement ce que je voulais dire par « l'IA a construit une base de code, pas un produit ». La fonctionnalité Studio compilait. Elle affichait un écran. Mais tu ne pouvais pas vraiment gérer une émission de podcast récurrente avec elle.
La refonte du lecteur audio
J'avais mentionné dans l'article original que j'avais supprimé le mini-lecteur. Il s'avère que j'avais tort — j'ai fini par en construire un meilleur. Le design final dispose d'une barre de mini-lecteur persistante au-dessus de la barre d'onglets avec la progression, les contrôles de saut et lecture/pause. En appuyant dessus, tu obtiens une feuille « En cours de lecture » développée avec un curseur de défilement, un sélecteur de vitesse (0,5x à 2x), des commandes de transport et une animation d'anneaux sonores.
La partie délicate était l'état isSeeking — sans lui, la position du curseur et l'observateur audio se battent l'un contre l'autre, créant un désordre saccadé. C'est une seule ligne d'état qui m'a pris une heure à diagnostiquer.
J'ai également ajouté des téléchargements hors ligne avec une UX ambiante : 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 délégué URLSession qui causait des échecs silencieux — le correctif était un déplacement de fichier synchrone à l'intérieur du callback. Le genre de bug qui ne se voit pas en revue de code.
Sécurisation sur toutes les couches
Celui-là était un peu déprimant. Un audit de sécurité de la pile complète — pas seulement l'application iOS — a révélé des vulnérabilités sur plusieurs couches : des fonctions de base de données trop permissives, des cas limites d'authentification, des lacunes dans la vérification des tokens, et des problèmes de validation des entrées dans plusieurs services backend.
Aucun de ces problèmes n'était dans le code Swift iOS. Ils étaient dans le backend avec lequel l'application iOS communique. Mais livrer une application iOS signifie que toute ta pile est maintenant dans la poche de tes utilisateurs. Ça a élevé les enjeux sur tout. Du code qui « fonctionnait bien » pour une application web semblait soudain inacceptable quand il passait par le processus de révision d'Apple et entrait dans une application native que les gens transportent partout.
StoreKit : le tueur de soumissions
Le sandbox testing de StoreKit est son propre univers, et c'est exactement ce qui a fait rejeter ma première soumission. L'environnement sandbox se comporte différemment de la production. Les transactions restent parfois « en attente » indéfiniment. Le fichier de configuration StoreKit dans Xcode nécessite une synchronisation manuelle. J'ai passé toute une soirée à déboguer un flux d'achat qui fonctionnait parfaitement dans le code mais échouait silencieusement dans le sandbox — il s'avérait que les identifiants de produit dans App Store Connect avaient un espace final. Un seul espace.
L'évaluateur d'Apple a rencontré une erreur sandbox parce que ma configuration StoreKit n'était pas synchronisée avec App Store Connect. Le flux d'achat fonctionnait très bien dans mes tests locaux — mais l'évaluateur frappait le vrai sandbox, pas mon fichier de configuration StoreKit local. Je l'ai corrigé le jour même, mais c'est un parfait exemple de la façon dont l'écart entre « ça marche sur ma machine » et « ça marche dans l'environnement d'Apple » est loin d'être anodin.
La chaîne de vérification des achats était son propre projet : l'application 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 de la réception signée d'Apple. Pas seulement le décodage — une vérification réelle de la signature. Ça a demandé deux commits dédiés pour bien faire les choses.
Confidentialité et conformité App Store
La confidentialité et la conformité, ce sont 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 compte), droits sur le contenu, intégration du captcha Turnstile. Claude Code peut é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 était une ébauche cassée — des ID de facteur vides, un flux de vérification uniquement. Je l'ai réécrite comme un cycle de vie TOTP complet : inscription, scan de QR code (génération native CoreImage), vérification, affichage du statut, désactivation. C'est un MFAView.swift de 394 lignes qui n'existait pas avant.
La localisation sur 7 langues a signifié 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 signifie que tu peux avoir un libellé de bouton grammaticalement correct qui sonne comme s'il avait été écrit par un robot. J'en ai repéré plusieurs en changeant la langue de mon téléphone et en utilisant vraiment l'application. C'est le genre de test que l'IA ne peut pas faire à ta place — pas encore.
Que peux-tu faire avec l'application iOS DIALØGUE ?
Pour ceux qui n'ont pas lu l'histoire de construction originale, voici ce que fait DIALØGUE :
Tu lui donnes un sujet — ou tu téléverses 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, s'appuyant sur de vraies recherches. Pas besoin de microphone.
L'application iOS inclut :
- Un assistant de création en 5 étapes — sujet, format, personnalisation, révision du plan, révision du script
- 30 voix IA sur 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 d'écran de verrouillage — la lecture en arrière-plan fonctionne tout simplement
- Apple Sign-In, Google OAuth, et authentification 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 automatiquement de nouveaux épisodes
- Téléversement de PDF — articles de recherche, rapports, livres comme matériau source
C'est une vraie application iOS native SwiftUI. Pas un wrapper web. Pas React Native. Ce qui a commencé avec 69 fichiers Swift en est maintenant à 88 fichiers et 11 459 lignes de code, soutenu par 195 tests. Je suis sincèrement fier de l'avoir livrée.
À quel point mon estimation initiale de la « phase de peaufinage » était-elle fausse ?
J'avais écrit que l'application était « toujours en développement, dans la phase de peaufinage finale ». C'était techniquement vrai, mais j'avais sous-estimé à quel point la « phase de peaufinage » représentait en réalité un nouveau travail.
En regardant le git log maintenant, 16 commits ça ne ressemble pas à du « peaufinage ». Ça ressemble à une deuxième phase de développement. La suite de tests à elle seule — 176 tests unitaires et 19 tests d'intégration — était un projet entier. Studio est passé d'une ébauche à une fonctionnalité 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. J'avais tort là aussi — j'ai fini par en construire un meilleur, avec une feuille 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 peux voir la vue d'ensemble, est la suivante : l'IA construit la fondation (60 %), les humains construisent le produit (30 %), et le processus de soumission à l'App Store t'enseigne les 10 % restants.
DIALØGUE est-elle disponible dans l'UE ?
DIALØGUE est disponible dans le monde entier, mais la disponibilité dans l'UE est encore en cours de traitement par Apple. Le Digital Markets Act de l'UE exige des étapes de conformité supplémentaires — divulgations de paiements alternatifs, documentation de confidentialité spécifique, détails d'enregistrement de l'entreprise. J'ai tout soumis, et Apple est en train de l'examiner. Elle devrait être disponible dans les pays de l'UE bientôt.
Si tu es dans l'UE et que tu ne peux pas attendre, l'application web fonctionne partout et propose les mêmes fonctionnalités.
À quelle vitesse va le développement iOS assisté par IA ?
L'application 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 construction |
|---|---|---|
| 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 | Reconstruction complète de l'application web | 14 jours |
| Migration du blog | WordPress → Next.js, 490 articles, Sydney RAG | 4 jours |
| DIALØGUE iOS | Application iOS native, première fois avec Swift | ~2 semaines (scaffold : une soirée) |
L'écart scaffold-à-livraison pour DIALØGUE iOS était d'environ deux semaines. Le scaffold lui-même était une soirée. Ce ratio — une soirée de travail IA, deux semaines de travail humain — te dit tout sur où nous en sommes avec le développement 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 construit le code ?
Dans l'article original, je cherchais encore le bon conseil. « Apprends à être la personne qui ouvre le Simulateur » était le mieux que j'avais.
Maintenant que j'ai vraiment livré le produit, je pense pouvoir être un peu plus précis.
L'application existe grâce à trois choses que l'IA ne pouvait pas faire :
-
J'ai utilisé le produit. Pas simplement testé. Utilisé. Créé des podcasts. Écouté pendant mes trajets. Remarqué que l'écran de révision 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 est trop dans un assistant de création ? Le Studio devrait-il ê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 vient d'avoir utilisé beaucoup de produits — des excellents et des terribles — et d'avoir développé un instinct pour ce qui semble 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 cela ne peut être automatisé. Ça nécessite de lire, de comprendre le contexte, et de prendre des décisions sur les implications légales et commerciales. Cette compétence — naviguer dans des systèmes humains complexes — ne disparaîtra pas.
Donc peut-être que le conseil mis à jour est : apprends à utiliser les choses en profondeur, développe le goût en te souciant de la qualité, et apprends à te sentir à l'aise pour 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'application est gratuite avec des achats de crédits intégrés. Pas d'abonnement.
Disponible dans le monde entier — la disponibilité dans l'UE est en cours de traitement par Apple et devrait être active bientôt. L'application web est disponible partout.
Questions fréquentes
DIALØGUE est-elle disponible sur l'App Store ?
Oui ! DIALØGUE - AI Podcast Studio est disponible sur l'App Store depuis mars 2026. C'est un téléchargement gratuit avec des achats de crédits intégrés (4 crédits pour 4,99 $, 9 pour 9,99 $, 18 pour 19,99 $). Disponible dans le monde entier — la disponibilité dans l'UE a été soumise et est en cours de traitement par Apple.
Est-elle disponible dans l'UE ?
Elle a été soumise et est en cours de traitement par Apple. Le Digital Markets Act de l'UE exige des étapes de conformité supplémentaires, et j'ai complété la paperasse — j'attends juste la révision d'Apple. Elle devrait être disponible bientôt. En attendant, l'application web fonctionne partout, y compris dans l'UE.
Apple l'a-t-elle rejetée ?
Oui — la première soumission a été rejetée pour des achats intégrés défectueux (Règle 2.1 : Complétude de l'application). La configuration sandbox StoreKit n'était pas synchronisée avec App Store Connect, donc les achats renvoyaient une erreur lors de la révision. Je l'ai corrigé le jour même, resoumis, et ça a passé. Puis la v1.0.1 a passé aussi. Trois soumissions au total, un refus. Le refus m'a appris plus que les deux approbations réunies.
Combien de temps a duré l'ensemble du processus ?
Environ deux semaines depuis l'article de blog original jusqu'à 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, fonctionnalités Studio, refonte du lecteur audio, réécriture MFA, sécurisation, vérification StoreKit, localisation, et le processus de soumission App Store. L'application a été livrée avec 88 fichiers et 11 459 lignes avec 195 tests.
Quelle a été la partie la plus difficile des 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 production, les identifiants de produit doivent correspondre exactement (jusqu'aux espaces de fin), et la boucle de rétroaction est lente — tu ne peux pas simplement lancer un test unitaire.
Puis-je toujours utiliser l'application web ?
Absolument. podcast.chandlernguyen.com a les mêmes fonctionnalités et fonctionne sur n'importe quel appareil. L'application iOS ajoute des commodités natives — Apple Sign-In, commandes d'écran de verrouillage, téléchargements hors ligne — mais l'expérience centrale de génération de podcast est identique.
Toujours en train de chercher quoi dire à ma fille. Mais au moins, j'ai maintenant une application livrée sur laquelle pointer du doigt quand je dis « le travail humain, c'est la partie difficile ».
À bientôt, Chandler
