De un concepto en SwiftUI al App Store en semanas

Hay un tipo concreto de retraso que afecta a los proyectos de iOS: una función que debía publicarse «en unas semanas» sigue en desarrollo tres meses después porque el alcance no dejó de ampliarse y el proceso de envío resultó tener más pasos de los previstos. En realidad, publicar rápidamente una app de SwiftUI no es una cuestión de velocidad, sino de decidir pronto qué no hará la app y mantener esa decisión cuando aparezca la tentación de añadir una función más.

Hemos publicado varias apps de SwiftUI en plazos cortos. El proceso se puede repetir, pero exige disciplina con el alcance, conocer bien el proceso de envío de Apple y estar dispuesto a publicar un producto bueno aunque todavía no esté completo. Así funciona en la práctica.

El alcance se decide antes del primer commit

El trabajo más importante de un ciclo rápido de publicación en iOS ocurre antes de escribir código. La pregunta no es «¿Qué debería hacer esta app?», sino «¿Cuál es el único problema que esta app resuelve para el usuario en su primera versión?». Toda función que no esté directamente relacionada con ese problema corresponde a la segunda versión.

Esto es más difícil de lo que parece porque casi todo parece relevante cuando se diseña desde cero. Las notificaciones parecen importantes. Las funciones sociales parecen importantes. Los paneles detallados de analítica parecen importantes. Pero los usuarios no pueden valorar ninguna de esas funciones hasta haber utilizado la función principal de la app y haberla encontrado útil. Una app que hace una cosa bien y se publica en cuatro semanas genera más retroalimentación útil que una que hace seis cosas de forma aceptable y se publica en cuatro meses.

La herramienta práctica es una lista de dos columnas, escrita antes de empezar el desarrollo: qué incluye el producto mínimo viable (MVP) y qué se pospone explícitamente. La lista de funciones pospuestas no es una lista de tareas pendientes: es un mecanismo que obliga a decidir. Cada función que se añada a un proyecto en marcha debería evaluarse para determinar si corresponde a esa lista en lugar de al sprint actual. La mayoría debería posponerse.

Las dos primeras semanas: solo las pantallas principales

Una app de SwiftUI con un único propósito claro suele necesitar entre tres y cinco pantallas para funcionar: un flujo de bienvenida, una o dos pantallas principales de interacción y una pantalla de ajustes o de cuenta. En las dos primeras semanas, esas pantallas deben quedar completas desde el punto de vista funcional: hacen lo que deben, con datos reales y en el orden correcto. No necesitan estar pulidas. Las animaciones pueden ser las predeterminadas del sistema. La tipografía puede ser la que ofrece el sistema. Los estados de error pueden mostrarse como alertas de texto sencillas.

Las decisiones de arquitectura que importan en esta fase son las difíciles de cambiar después: el modelo de navegación (NavigationStack, TabView o un coordinador personalizado), el enfoque de gestión del estado (usar @Observable del framework Observation o mantener ObservableObject) y la estrategia de persistencia de datos (SwiftData, Core Data o UserDefaults para estados sencillos). Tomar estas decisiones de forma explícita y temprana, en lugar de dejar que se acumulen sobre la marcha, evita llegar a la tercera semana con la mitad de la app usando un modelo de navegación y la otra mitad, otro.

En las apps que integran un backend de Supabase, el flujo de autenticación merece especial atención en esta fase. Las directrices de App Review de Apple establecen dos requisitos separados: las apps que permiten crear cuentas deben permitir que los usuarios eliminen su cuenta desde la propia app (directriz 5.1.1(v)), y las apps que utilizan un inicio de sesión de terceros o social, como Google Sign-In, para la cuenta principal también deben ofrecer una opción de inicio de sesión equivalente centrada en la privacidad, que en la práctica suele ser Iniciar sesión con Apple (directriz 4.8). Si su app utiliza únicamente su propio sistema de autenticación con correo electrónico y contraseña mediante Supabase, Iniciar sesión con Apple no es obligatorio, pero el flujo de eliminación de cuentas debe estar en el MVP. No porque los usuarios vayan a utilizarlo desde el primer día, sino porque App Review rechazará la app si falta. Si añade un inicio de sesión social, planifique al mismo tiempo la opción de inicio de sesión equivalente.

Semanas tres y cuatro: pulido y TestFlight

En la tercera semana, la app empieza a parecer un producto real. Es el momento de abordar los estados de carga (no solo «mostrar un indicador de carga», sino «mostrar un indicador que haga que la espera resulte razonable»), los estados vacíos (lo que muestra la app cuando aún no hay datos) y los estados de error (lo que ocurre cuando falla una llamada de red). Esto no es un simple pulido: es la experiencia de los usuarios nuevos, que llegan sin datos y a veces tienen problemas de red.

La distribución por TestFlight debería empezar en la tercera semana, no en la cuarta. La primera compilación que cargue tendrá problemas que no había previsto. App Store Connect valida el binario antes de permitir las pruebas y detecta problemas —permisos de la app ausentes, combinaciones incorrectas de perfiles de aprovisionamiento, claves obligatorias de Info.plist que faltan— que la compilación local de Xcode no revela. Encontrarlos en la tercera semana deja tiempo para corregirlos antes del envío definitivo. Encontrarlos la noche anterior al lanzamiento previsto no.

En esta fase, la retroalimentación de TestFlight resulta más útil para detectar confusiones en la navegación y elementos que no dejan claro cómo interactuar que para recibir solicitudes de funciones. Pregunte a quienes prueben la app: «¿Hubo algo que intentó hacer y no pudo averiguar cómo?», en lugar de «¿Qué funciones le gustaría ver?». La segunda pregunta generará una lista que añadiría meses al calendario.

El proceso de envío al App Store

El proceso de envío al App Store tiene más pasos de los que esperan quienes lo realizan por primera vez, y cada uno puede bloquear la publicación. Resolverlos con antelación, en lugar de empezar cuando el código de la app ya está terminado, evita que la última semana se convierta en una carrera contra el tiempo.

Se necesitan capturas de pantalla antes del envío y deben coincidir con una de las dimensiones en píxeles aceptadas para cada tamaño de pantalla. A octubre de 2026, App Store Connect exige capturas de iPhone para la categoría de pantallas de 6,9 pulgadas (por ejemplo, iPhone 16 Pro Max), o para la categoría de 6,5 pulgadas (por ejemplo, iPhone 14 Plus) si no proporciona las de 6,9 pulgadas, además de capturas de iPad de 13 pulgadas (por ejemplo, iPad Pro (M4) o iPad Pro de 12,9 pulgadas (6.ª generación)) si la app funciona en iPad. Generarlas en el simulador es sencillo, pero lleva tiempo si se deja para el último día. Una configuración sencilla de snapshot de Fastlane puede automatizarlo.

La sección de detalles de privacidad de la app en App Store Connect exige declarar cada tipo de dato que recopila la app, para qué se utiliza y si está vinculado a la identidad del usuario. No son metadatos opcionales: el envío falla si la información está incompleta. Si su app utiliza Supabase con autenticación, recopila como mínimo direcciones de correo electrónico e identificadores de usuario, y debe declarar ambos. Los SDK de terceros y las herramientas de analítica amplían esa lista. Identificar con precisión los datos recopilados antes del envío evita tener que actualizar esos detalles después del lanzamiento.

Apple indica que suele revisar el 50 % de los envíos en menos de 24 horas y el 90 % en menos de 48 horas; se puede solicitar una revisión acelerada en circunstancias excepcionales, como una corrección de un error crítico o un lanzamiento vinculado a un evento. Una persona contrasta la app con las directrices de Apple. Los motivos más habituales de rechazo en el primer envío son funciones de cuenta ausentes (eliminación de cuentas desde la app o una opción de inicio de sesión equivalente junto con el inicio de sesión social), credenciales de una cuenta de demostración no proporcionadas en apps con inicio de sesión y fallos que cierran la app en casos límite que los revisores encontraron y quienes la probaron no.

Qué recortar y cómo hacerlo

Lo más difícil de un ciclo rápido de publicación es que los recortes parezcan deliberados y no apresurados. Los usuarios distinguen entre una app sencilla por decisión y una app sin terminar. La diferencia está sobre todo en que lo que existe esté completo —cada pantalla debe estar terminada—, más que en el número de pantallas.

Recortes prácticos que rara vez perjudican una primera versión: notificaciones push (complejas de configurar correctamente, y los usuarios necesitan confiar en la app antes de aceptarlas con agrado), funciones sociales (seguir a otros usuarios, compartir y clasificaciones: útiles a escala, pero una distracción en el lanzamiento), ajustes avanzados de personalización (la mayoría de los usuarios nunca cambia los valores predeterminados) y cualquier función que requiera una infraestructura de backend considerable que el MVP no necesite ya.

Recortes prácticos que sí perjudican una primera versión: gestión de errores (una app que se cierra por un tiempo de espera máximo de red causa una frustración duradera), estados de carga (una app que se congela sin indicaciones visuales parece averiada) y funciones básicas de gestión de cuentas (los usuarios deben poder restablecer su contraseña y eliminar su cuenta, incluso en el MVP).

Después del lanzamiento: las dos primeras semanas son decisivas

Las dos primeras semanas tras el lanzamiento son el periodo en el que las valoraciones del App Store son más vulnerables. Un grupo inicial de reseñas de una estrella por un fallo que no apareció en las pruebas perjudica de forma desproporcionada la valoración de la app a largo plazo. Durante la primera semana, se deben revisar a diario Instruments y el organizador de informes de fallos de Xcode. Una versión que corrija cualquier fallo crítico que cierre la app debe enviarse dentro de las 24 horas siguientes a su detección: App Review ofrece una vía acelerada para estas correcciones.

Conviene resistir durante al menos dos semanas el impulso de publicar las funciones pospuestas inmediatamente después del lanzamiento. Entender cómo interactúan realmente los usuarios con la experiencia principal antes de añadir complejidad aporta más valor que demostrar un ritmo de desarrollo constante. Las funciones de la segunda versión se diseñarán mejor después de dos semanas de observar patrones de uso reales que si se hubieran desarrollado en paralelo al lanzamiento.