Guía release iOS

Checklist TestFlight a App Store 2026

TestFlight distribuye la beta, pero no la envía a App Review. Congela el candidato y separa review y publicación.

LaunchLint Academy

16 min de lecturaRevisado editorialmente por el equipo de LaunchLint
Recorrido controlado de un build iOS desde TestFlight hasta review y rollout
TestFlight distribuye betas, pero no envía automáticamente la versión a App Review. Debes elegir el build exacto con metadata, acceso y privacidad completos.
TL;DR

La respuesta breve

  • TestFlight distribuye betas, pero no envía automáticamente la versión a App Review. Debes elegir el build exacto con metadata, acceso y privacidad completos.
  • Convierte el feedback en evidencia, congela el candidato y separa review, publicación y monitoring.
  • Esta checklist no se completa una sola vez. Ejecútala antes del primer upload, después de cambios relevantes en dependencias o configuración y justo antes de publicar. Desarrollo, producto y quien controla la consola deben revisar el mismo build. Las señales estáticas son reproducibles, pero no demuestran el runtime ni las respuestas del backend. Combínalas con pruebas del artefacto firmado, declaraciones oficiales y una decisión documentada.

1. Definir objetivos beta

Especifica riesgos y recorridos para testers internos y externos.

Trata definir objetivos beta como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de definir objetivos beta identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

2. Congelar el build

Relaciona número, commit, entorno, flags y datos de prueba.

Trata congelar el build como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de congelar el build identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

3. Planear la beta review

Los testers externos pueden requerir Beta App Review, distinta de la review final.

Trata planear la beta review como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de planear la beta review identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

4. Clasificar feedback

Separa blockers, regresiones y mejoras y registra el riesgo aceptado.

Trata clasificar feedback como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de clasificar feedback identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

5. Completar la versión

Selecciona build y cierra metadata, privacidad, edad, exportación y acceso.

Trata completar la versión como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de completar la versión identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

6. Probar indicaciones para el equipo de revisión

Un tester nuevo debe llegar a login, compras y funciones protegidas solo con las instrucciones.

Trata probar review notes como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de probar review notes identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

7. Controlar estados

Distingue estados de revisión y responde con ruta y pruebas concretas.

Trata controlar estados como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de controlar estados identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

8. Planear rollout

Publicación automática, manual o gradual necesita responsable, monitoring y criterios de parada.

Trata planear rollout como una propiedad verificable del candidato exacto. Relaciona la decisión con su archivo, campo de la tienda o prueba reproducible. Registra por separado lo esperado y lo observado, asigna responsable y detén la publicación mientras quede una contradicción de seguridad o review.

Pruebas para aceptar la release

  • Estado de producción de planear rollout identificado
  • Archivo o campo responsable enlazado
  • Prueba repetida en un dispositivo limpio
  • Diferencias iOS y Android documentadas
  • Cada duda tiene responsable y fecha
  • La evidencia no contiene secretos ni datos personales

Preguntas frecuentes

¿TestFlight envía a App Review?

No. La versión y el build se envían por separado.

¿La beta es permanente?

No. Los builds tienen un periodo de prueba limitado.

¿Un fix necesita otro build?

Sí, si cambia el binario.

¿LaunchLint ejecuta tests TestFlight?

No. Revisa archivos de forma estática.

Fuentes oficiales

Este artículo se basa en las siguientes fuentes primarias oficiales. Las reglas pueden cambiar; comprueba siempre la versión vigente antes de enviar.