La App Store dijo que sí
Hace dos semanas escribí "Todavía construyendo. Todavía sin terminar." Hoy DIALØGUE está en la App Store. Así se vio realmente ese último 40%.
Hace dos semanas terminé un post con esto: "Todavía construyendo. Todavía sin terminar. Todavía descubriendo qué decirle a mi hija."
Prometí una actualización cuando la app llegara a la App Store. O cuando la rechazaran. Dije que la historia del rechazo podría ser más interesante.
DIALØGUE - AI Podcast Studio ya está en la App Store — una app iOS nativa en SwiftUI que convierte cualquier tema o PDF en un episodio de podcast completamente producido, construida con Claude Code por alguien que jamás había escrito una línea de Swift. La puedes descargar ahora mismo.
Pero no al primer intento. Tengo que admitir que predije que la historia del rechazo sería más interesante que la de la aprobación. Y tenía razón.
¿Qué pasó cuando Apple rechazó el primer envío?
Mi primer envío fue rechazado. Directriz 2.1 — Rendimiento: Completitud de la app. Las compras in-app estaban rotas.
El mensaje de Apple fue amable — notaron que era mi primer envío, me felicitaron por unirme al programa de desarrolladores y explicaron el problema con claridad. Las compras in-app arrojaban un error cuando su revisor intentaba comprar.
La cosa es esta: el flujo de compra funcionaba perfecto en mis pruebas. El problema estaba en el entorno sandbox de Apple, que se comporta distinto tanto al desarrollo como a producción. La configuración de StoreKit tenía que estar exactamente sincronizada con App Store Connect — y la mía no lo estaba. Yo estaba probando con un archivo de configuración local de StoreKit mientras el revisor usaba el sandbox real.
Lo arreglé ese mismo día, volví a enviarlo y pasó. Después publiqué un parche v1.0.1 que también salió sin problemas.
Tres envíos en total. Un rechazo. El rechazo me enseñó más sobre el proceso de la App Store que cualquiera de las dos aprobaciones. Es el patrón de siempre, ¿no? Los fracasos siempre enseñan más que los éxitos.
¿Cómo se ve realmente ese "último 40%"?
En el post original, dije que la IA te lleva al 60% y que el 40% restante es puro trabajo humano. Ahora quiero ser más específico, porque tengo el git log para demostrarlo.
16 commits. 57 archivos modificados. 4.886 líneas agregadas. La app creció de 69 archivos Swift a 88, de 7.568 líneas a 11.459. Casi 4.000 líneas de "pulido".
Esto es lo que esos 16 commits contenían en realidad — más o menos en el orden en que ocurrieron:
Los tests que debieron existir desde el día uno
El scaffolding original tenía cero tests. Ninguno. Claude construyó 69 archivos de código de producción y ni un solo test. Mi primer commit real después del post original agregó 176 tests unitarios y 19 de integración corriendo contra una instancia local de Supabase.
Escribir esos tests detectó bugs reales de inmediato: errores de decodificación del modelo Show por columnas inexistentes en la base de datos, AudioPlayer que no se reiniciaba al final de la pista, una race condition al recargar la biblioteca, un guard de UUID nulo que faltaba en el wizard de creación. Cualquiera de estos habría sido un crash en producción.
Creo que es un patrón que vale la pena nombrar: la IA genera código sin infraestructura de testing. No porque no pueda escribir tests — Claude es excelente escribiendo tests cuando se lo pides — sino porque el prompt inicial siempre es "construye la app", no "construye la app con tests exhaustivos". Los tests vinieron de mi decisión de no sentirme cómodo publicando sin ellos.
Studio: la feature que apenas era un esqueleto
La feature "Studio" original para shows recurrentes era un placeholder. Dos commits después, era un producto real: creación de shows con grids de templates, gestión de episodios con badges de estado y botones de acción, flujos de edición y eliminación, configuración de horarios con selectores de zona horaria y sheets de personalización de voz.
Después vino Studio Fase 2: rediseño del detalle del show, retry y eliminación por episodio, generación manual de episodios con verificación de créditos. Más 8 nuevos XCUITests para asegurar que todo funcionara end-to-end.
Esto es lo que quise decir con "la IA construyó un codebase, no un producto". La feature Studio compilaba. Renderizaba una pantalla. Pero no podías gestionar realmente un show de podcast recurrente con ella.
El reproductor de audio reimaginado
En el post original mencioné que había eliminado el mini reproductor. Resulta que estaba equivocado — terminé construyendo uno mejor. El diseño final tiene una barra persistente de mini reproductor sobre el tab bar con progreso, controles de salto y play/pausa. Tocas la barra y aparece un sheet expandido "Now Playing" con un slider seekable, selector de velocidad (0.5x a 2x), controles de transporte y una animación de anillos de sonido.
La parte complicada fue el estado isSeeking — sin él, la posición del slider y el observer de audio pelean entre sí, creando un desastre entrecortado. Una línea de estado que tardé una hora en diagnosticar.
También agregué descargas offline con UX ambiental: un ícono verde en los episodios descargados en la biblioteca, un toast de finalización, una etiqueta "Descargado" en Now Playing y swipe para eliminar la descarga. El DownloadManager tenía una race condition de archivo temporal en el delegate de URLSession que causaba fallas silenciosas — la solución fue un file move sincrónico dentro del callback. No es el tipo de bug que aparece en un code review.
Seguridad: blindando cada capa
Esta parte fue aleccionadora. Una auditoría de seguridad del stack completo — no solo la app iOS — reveló vulnerabilidades en múltiples capas: funciones de base de datos con permisos excesivos, edge cases de autenticación, brechas en la verificación de tokens y problemas de validación de input en varios servicios del backend.
Ninguno estaba en el código Swift de iOS. Estaban en el backend con el que habla la app. Pero publicar una app iOS significa que todo tu stack ahora está en el bolsillo de tus usuarios. Eso sube la vara de todo. Código que "funcionaba bien" para una app web de repente se sentía inaceptable cuando iba a pasar por la revisión de Apple y terminar en una app nativa que la gente lleva encima.
StoreKit: lo que mató el primer envío
El sandbox de StoreKit es un universo aparte, y fue exactamente lo que provocó el rechazo de mi primer envío. El entorno sandbox se comporta distinto a producción. Las transacciones a veces quedan "pendientes" para siempre. El archivo de configuración de StoreKit en Xcode necesita sync manual. Pasé una tarde entera debuggeando un flujo de compra que funcionaba perfecto en el código pero fallaba en silencio en el sandbox — resultó que los product IDs en App Store Connect tenían un espacio al final. Un espacio.
El revisor de Apple se topó con un error de sandbox porque mi configuración de StoreKit estaba desincronizada con App Store Connect. El flujo de compra andaba bien en mis pruebas locales — pero el revisor estaba usando el sandbox real, no mi config local de StoreKit. Lo arreglé ese mismo día, pero es el ejemplo perfecto de que la distancia entre "funciona en mi máquina" y "funciona en el entorno de Apple" no es trivial.
La cadena de verificación de compras fue un proyecto en sí misma: la app iOS manda una representación JWS (JSON Web Signature) de la transacción a una función server-side, que realiza verificación criptográfica completa de la cadena del recibo firmado de Apple. No solo decodificación — validación real de firma. Esto tomó dos commits dedicados para dejarlo bien.
Privacidad y cumplimiento de la App Store
La privacidad y el compliance son formularios, decisiones y checkboxes con implicaciones legales — y ninguna IA puede llenarlos por ti. Declaraciones de App Tracking Transparency, etiquetas nutricionales de privacidad, compliance de exportación para cifrado (sí, HTTPS cuenta), derechos de contenido, integración de Turnstile captcha. Claude Code puede escribir Swift, pero no puede decirte si tus prácticas de recopilación de datos necesitan una etiqueta de "Datos usados para rastrearte".
MFA completo y localización
La implementación original de MFA era un esqueleto roto — IDs de factores vacíos, solo flujo de verificación. La reescribí como un ciclo completo de TOTP: enrollment, escaneo de código QR (generación nativa con CoreImage), verificación, visualización del estado, desactivación. Son 394 líneas de MFAView.swift que no existían antes.
La localización en 7 idiomas significó 253 strings de UI traducidos al inglés, español, francés, japonés, coreano, vietnamita y chino. Claude hizo las traducciones, y en general estaban bien. Pero "en general bien" en japonés significa que puedes tener un botón que es gramaticalmente correcto pero suena como si lo hubiera escrito un robot. Detecté varios de esos casos cambiando el idioma de mi teléfono y usando la app de verdad. Ese tipo de testing la IA todavía no puede hacerlo por ti.
¿Qué puedes hacer con la app iOS de DIALØGUE?
Para quienes no leyeron la historia original, esto es lo que hace DIALØGUE:
Le das un tema — o subes un PDF — y produce un episodio de podcast completamente investigado, guionado y narrado. Dos hosts de IA tienen una conversación natural sobre tu tema, con investigación real detrás. Sin micrófono.
La app iOS incluye:
- Wizard de creación en 5 pasos — tema, formato, personalización, revisión del outline, revisión del script
- 30 voces de IA en 7 idiomas — inglés, español, francés, japonés, coreano, vietnamita, chino
- 9 formatos de podcast — desde Tech News Analysis hasta Investigative Comedy
- Reproducción de audio con controles en la pantalla de bloqueo — reproducción en segundo plano que funciona
- Apple Sign-In, Google OAuth y autenticación por correo
- Compras in-app — basadas en créditos, sin suscripción: 4 créditos por $4.99, 9 por $9.99, 18 por $19.99
- Studio — configura shows recurrentes que generan episodios frescos automáticamente
- Carga de PDF — papers, informes, libros como material fuente
Es una app SwiftUI nativa de verdad. No un wrapper web. No React Native. Lo que empezó con 69 archivos Swift ahora son 88 archivos y 11.459 líneas de código, respaldados por 195 tests. Estoy genuinamente orgulloso de haberla publicado.
¿Qué tan mal calculé la "fase de pulido"?
Escribí que la app estaba "todavía en desarrollo, en la fase final de pulido". Técnicamente cierto, pero subestimé cuánto de la "fase de pulido" era trabajo nuevo disfrazado.
Mirando el git log ahora, 16 commits no suena a "pulido". Suena a una segunda fase de desarrollo. La suite de tests sola — 176 unitarios y 19 de integración — fue un proyecto entero. Studio pasó de esqueleto a feature completa. El reproductor de audio fue reimaginado dos veces. El blindaje de seguridad tocó más de 40 funciones del backend. MFA fue reescrito desde cero.
También dije que había eliminado el mini reproductor. También estaba equivocado — terminé construyendo uno mejor, con un sheet de Now Playing, controles de velocidad e indicadores de descarga. El instinto de "eliminarlo" era correcto — el primer mini reproductor era malo. Pero el concepto era correcto. Solo había que construirlo bien.
Creo que la división honesta, ahora que veo el panorama completo, es: la IA construye los cimientos (60%), los humanos construyen el producto (30%), y el proceso de envío a la App Store te enseña el 10% restante.
¿Está disponible DIALØGUE en la UE?
DIALØGUE está disponible en todo el mundo, pero la disponibilidad en la UE todavía está siendo procesada por Apple. La Ley de Mercados Digitales de la UE requiere pasos adicionales de cumplimiento — divulgaciones de pagos alternativos, documentación específica de privacidad, detalles de registro comercial. Envié todo, y Apple lo está revisando ahora. Debería estar disponible en los países de la UE pronto.
Si estás en la UE y no puedes esperar, la app web funciona en todas partes y tiene las mismas funcionalidades.
¿Qué tan rápido es desarrollar para iOS con IA?
La app iOS de DIALØGUE tardó unas dos semanas del primer commit a la App Store — una noche de scaffolding con IA y dos semanas de trabajo humano de producto. Sigo manteniendo esta tabla porque me sigue enseñando cosas:
| Proyecto | Complejidad | Tiempo de construcción |
|---|---|---|
| DIALØGUE v1 | MVP generador de podcasts | ~6 meses |
| STRAŦUM | 10 agentes de IA, 11 frameworks, multi-tenant | 75 días |
| Rediseño del sitio | Renovación del frontend de WordPress | 3 días |
| DIALØGUE v2 | Reconstrucción completa de la app web | 14 días |
| Migración del blog | WordPress → Next.js, 490 posts, Sydney RAG | 4 días |
| DIALØGUE iOS | App iOS nativa, primera vez usando Swift | ~2 semanas (scaffold: una noche) |
La distancia entre el scaffold y el ship de DIALØGUE iOS fue de unas dos semanas. El scaffold en sí fue una noche. Esa proporción — una noche de trabajo IA, dos semanas de trabajo humano — te dice todo sobre dónde estamos con el desarrollo asistido por IA ahora mismo.
La parte de la IA sigue acelerándose. La parte humana se mantiene más o menos igual. Lo escribí hace dos semanas y sigue siendo cierto.
¿Qué habilidades importan cuando la IA escribe el código?
En el post original, todavía estaba buscando el consejo correcto. "Aprende a ser la persona que abre el Simulador" era lo mejor que tenía.
Ahora que de verdad publiqué la cosa, creo que puedo ser un poco más específico.
La app existe gracias a tres cosas que la IA no pudo hacer:
-
Usé el producto. No lo probé. Lo usé. Creé podcasts. Los escuché camino al trabajo. Noté que la pantalla de revisión del outline necesitaba mostrar las fuentes de investigación porque quería saber de dónde venían los datos.
-
Tomé decisiones de criterio sin respuesta correcta. ¿Eliminar el mini reproductor o dejarlo? ¿Cuánta personalización es demasiada en un wizard de creación? ¿Studio debería ser un tab o una sección? No son decisiones de ingeniería. Son decisiones de gusto. Y el gusto viene de usar muchos productos — buenos y terribles — y desarrollar un instinto para lo que se siente bien.
-
Navegué un sistema diseñado para humanos. App Store Connect, declaraciones de privacidad, compliance de exportación, requisitos de screenshots — nada de esto se puede automatizar. Requiere leer, entender contexto y tomar decisiones con implicaciones legales y de negocio. Esa habilidad — navegar sistemas humanos complejos — no va a desaparecer.
Entonces quizás el consejo actualizado es: aprende a usar las cosas a fondo, desarrolla gusto preocupándote por la calidad, y ponte cómodo navegando sistemas que no fueron diseñados para ser simples.
Es más concreto que "aprende a pensar críticamente". Creo que está más cerca de la verdad. Todavía no estoy seguro de que sea suficiente.
¿Cómo descargo DIALØGUE?
La app es gratuita con compras de créditos in-app. Sin suscripción.
Disponible en todo el mundo — la disponibilidad en la UE está siendo procesada por Apple y debería estar en vivo pronto. La app web está disponible en todas partes.
Preguntas frecuentes
¿Está DIALØGUE disponible en la App Store?
¡Sí! DIALØGUE - AI Podcast Studio está en vivo en la App Store desde marzo de 2026. Descarga gratuita con compras de créditos in-app (4 créditos por $4.99, 9 por $9.99, 18 por $19.99). Disponible en todo el mundo — la disponibilidad en la UE ya fue enviada y está siendo procesada por Apple.
¿Está disponible en la UE?
Ya fue enviada y Apple está procesándola. La Ley de Mercados Digitales de la UE requiere pasos adicionales de compliance, y ya completé el papeleo — solo falta la revisión de Apple. Debería estar disponible pronto. Mientras tanto, la app web funciona en todas partes, incluyendo la UE.
¿Apple la rechazó?
Sí — el primer envío fue rechazado por compras in-app rotas (Directriz 2.1: Completitud de la app). La configuración de sandbox de StoreKit no estaba sincronizada con App Store Connect, así que las compras tiraban error durante la revisión. Lo arreglé ese mismo día, volví a enviarla y pasó. Después v1.0.1 también pasó. Tres envíos en total, un rechazo. El rechazo me enseñó más que cualquiera de las aprobaciones.
¿Cuánto tiempo tomó todo el proceso?
Unas dos semanas desde el post original hasta la aprobación en la App Store. Claude Code scaffoldeó 69 archivos Swift en una noche. Los 16 commits restantes agregaron 4.886 líneas en 57 archivos — tests, features de Studio, rediseño del reproductor de audio, reescritura de MFA, blindaje de seguridad, verificación de StoreKit, localización y el proceso de envío a la App Store. La app se publicó con 88 archivos y 11.459 líneas con 195 tests.
¿Cuál fue la parte más difícil del último 40%?
El sandbox de StoreKit. La distancia entre "esto funciona en el código" y "esto funciona en el sistema de transacciones de Apple" es enorme. Las transacciones en el sandbox se comportan distinto a producción, los product IDs tienen que coincidir exactamente (hasta los espacios al final), y el feedback loop es lento — no puedes simplemente correr un test unitario.
¿Todavía puedo usar la app web?
Claro que sí. podcast.chandlernguyen.com tiene las mismas funcionalidades y funciona en cualquier dispositivo. La app iOS agrega comodidades nativas — Apple Sign-In, controles en la pantalla de bloqueo, descargas offline — pero la experiencia core de generación de podcasts es idéntica.
Todavía descubriendo qué decirle a mi hija. Pero al menos ahora tengo una app publicada para señalar cuando digo "el trabajo humano es la parte difícil."
Un abrazo, Chandler
