Checklist para publicar una app iOS en App Store

Ocho comprobaciones antes de publicar

1. Instala el build previsto y completa el flujo principal desde cero.
2. Revisa privacidad, permisos y enlaces de soporte.
3. Compara capturas y metadatos con la versión real.
4. Prueba compra y restauración en sandbox cuando corresponda.
5. Proporciona acceso e instrucciones a los revisores.
6. Añade la versión y las compras necesarias al mismo borrador.
7. Confirma el envío efectivo a revisión y su resultado.
8. Tras publicar, instala la app desde la ficha pública y verifica producción.

Producto y experiencia

• El flujo principal se puede completar desde una instalación nueva.
• Los estados de carga, vacío, error y sin conexión tienen una respuesta clara.
• La app explica por qué solicita cada permiso antes del diálogo del sistema.
• Los enlaces de soporte, privacidad y condiciones funcionan.
• La interfaz es usable con tamaños de texto mayores y VoiceOver en las acciones críticas.

Calidad técnica

• La versión final se prueba en los modelos y versiones de iOS compatibles.
• No quedan bloqueos, datos de prueba, menús internos ni credenciales en la compilación.
• Se verifican instalación, actualización, cierre de sesión y recuperación de cuenta.
• Los enlaces universales, notificaciones y tareas en segundo plano funcionan en producción.
• La analítica y los informes de errores no recopilan información innecesaria.

Privacidad y datos

• La política de privacidad describe los datos realmente usados por la app y sus proveedores.
• Las respuestas de App Privacy en App Store Connect coinciden con el comportamiento real.
• Los textos de uso en Info.plist explican de forma específica para qué se necesita cada permiso.
• La eliminación de cuenta está disponible dentro de la app cuando se permite crear una cuenta.
• Los SDK de terceros y sus manifiestos de privacidad están actualizados.

Pagos y suscripciones

• Las compras digitales utilizan el sistema admitido por Apple para ese caso.
• Precio, duración, renovación y prueba gratuita se muestran antes de comprar.
• “Restaurar compras” funciona y es fácil de encontrar.
• Se prueban compra, cancelación, renovación, reembolso y periodo de gracia en sandbox.
• La pantalla de pago incluye enlaces a privacidad y condiciones.
• La primera compra de cada tipo acompaña a una nueva versión. Un grupo nuevo de suscripción se envía con al menos una suscripción, dentro del mismo borrador.
• Una prueba local de StoreKit no sustituye una compra y restauración con productos reales de sandbox o TestFlight.

Ficha de App Store

• Nombre, subtítulo y descripción explican el beneficio sin promesas no demostrables.
• Las capturas corresponden a la versión actual y son legibles en cada tamaño requerido.
• Icono, categoría, edad, derechos y datos de contacto están completos.
• Las palabras clave no repiten términos innecesariamente ni incluyen marcas ajenas.
• La URL de soporte lleva a una página donde una persona puede obtener ayuda.

Acceso para la revisión

• Apple recibe una cuenta de demostración activa si alguna función requiere acceso.
• Las notas explican pasos no evidentes, hardware necesario y funciones restringidas por región.
• El backend de producción estará disponible durante toda la revisión.
• Los datos de muestra permiten comprobar el flujo principal sin configuración especial.

Publicación

• El número de versión, build, firma y capacidades corresponden al entorno de producción.
• Se decide entre publicación automática, manual o gradual.
• Soporte y monitorización están preparados para el día del lanzamiento.
• Existe un plan para corregir rápidamente un fallo crítico o pausar una campaña.

Después de la aprobación

Comprueba la ficha pública, instala la versión desde App Store y recorre de nuevo el flujo principal. Vigila errores, rendimiento, conversión y reseñas durante los primeros días. El lanzamiento termina cuando la versión real es estable, no cuando cambia el estado en App Store Connect.

Si todavía estás definiendo la primera versión, empieza por el roadmap para un MVP iOS.

TestFlight, revisión y publicación son etapas diferentes

Subir un build solo confirma la carga. TestFlight permite distribuir una beta; no demuestra aprobación para App Store. Añadir una versión al borrador tampoco la envía: hay que completar el envío a revisión. Después de la aprobación, verifica si queda una publicación manual pendiente y comprueba la ficha y la instalación pública.

¿Se puede garantizar la fecha de aprobación?

No. La revisión es una dependencia externa. Una publicación manual permite separar la aprobación del momento elegido para el lanzamiento.

¿Qué necesito para la primera suscripción?

Comprueba que la nueva versión, el grupo nuevo y las suscripciones necesarias estén incluidos en el mismo borrador antes de enviarlo.

Fuentes y siguientes pasos

Comprobado con la documentación de Apple el 27 de octubre de 2026: envío de una app, compras y suscripciones y pruebas sandbox.

Consulta cuánto cuesta desarrollar una app iOS y los proyectos de desarrollo iOS.