LaunchLint Academy

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.