TestFlight es la herramienta de Apple para distribuir una aplicación antes de que esté en la App Store. Usted sube el binario firmado a App Store Connect, invita a personas y ellas lo instalan en su propio iPhone a través de la app TestFlight. Lo que reciben no es una vista previa ni un simulador: es exactamente el build que enviará después a App Review, con su icono, sus permisos y su código nativo.
Tres cifras enmarcan todo el servicio. Hasta 100 testers internos que son miembros de su equipo de App Store Connect, hasta 10.000 testers externos invitados por correo electrónico o mediante un enlace público, y 90 días de validez para cada build. Todo lo demás, desde la revisión beta hasta las capturas de pantalla de feedback, se deriva de la forma en que esos dos grupos reciben un trato distinto. Esta guía recorre el camino desde el envío hasta el teléfono de un tester, y después enumera los límites y los errores que retrasan un lanzamiento.
TestFlight es una etapa de un recorrido más largo. Si necesita la secuencia completa, desde la cuenta de desarrollador hasta el lanzamiento, lea nuestra guía sobre cómo publicar una app en la App Store.
Qué es TestFlight y dónde se sitúa
TestFlight vive dentro de App Store Connect, en la pestaña del mismo nombre, y en los dispositivos de los testers como una app gratuita de la App Store. Exige una membresía del Apple Developer Program por su parte, y nada más que una cuenta de Apple por parte del tester. Cubre iOS, iPadOS, macOS, tvOS, watchOS y visionOS, así que un build para Mac o Vision Pro sigue el mismo flujo que un build para iPhone.
Su lugar en la cadena está entre el build y la revisión. Las herramientas anteriores muestran su código en un teléfono más rápido, pero no como su app real: Expo Go solo carga su JavaScript dentro de una carcasa compartida, y un development build incorpora su código nativo pero con las herramientas de desarrollo dentro. TestFlight es el primer momento en que tiene en las manos el binario de producción. Nuestra guía para probar con Expo Go cubre esa etapa anterior y sus límites.
Del envío al teléfono de un tester, paso a paso
1. Envío y procesamiento
Un build llega a App Store Connect desde Xcode, desde la app Transporter de Apple, desde un servicio de compilación como EAS Submit o desde una plataforma como Cadrant que maneja EAS por usted. Una vez subido, el build pasa por un procesamiento: Apple comprueba el paquete, indexa los símbolos y lo analiza, lo que lleva de unos minutos a alrededor de una hora en momentos de mucha carga. Después aparece en la pestaña TestFlight de su app con un estado.
La primera parada suele ser «Missing Compliance». Apple pregunta si la app usa un cifrado más allá del que iOS proporciona; para la mayoría de las apps que solo hacen llamadas HTTPS, la respuesta es no, y puede definir la clave ITSAppUsesNonExemptEncryption en la configuración de la app para que la pregunta no vuelva a bloquear un build. Hasta que la respuesta queda registrada, nadie puede instalar el build.
2. Testers internos: su equipo, sin revisión
Los testers internos son las personas que tienen un rol en su equipo de App Store Connect: Admin, App Manager, Developer, Marketing o Customer Support. Puede tener hasta 100 por app, y reciben cada build minutos después del procesamiento, sin revisión de Apple. Incluso puede marcar «distribuir automáticamente» en un grupo interno para que cada nueva subida salga por sí sola. Este es el bucle de su propio equipo: subir, probar, corregir, volver a subir, varias veces al día si hace falta.
3. Testers externos: hasta 10.000 personas y una revisión beta
Los testers externos son todos los demás: clientes, amigos, una lista de espera. Los organiza en grupos, los invita por correo electrónico o comparte un enlace público, y cada grupo puede recibir builds distintos. El límite es de 10.000 testers externos por app entre todos los grupos. La presentación de TestFlight de Apple fija las reglas de ambos círculos.
La diferencia con las pruebas internas es la Beta App Review. El primer build que añade a un grupo externo se envía a App Review para comprobar que respeta las App Review Guidelines, en la práctica una comprobación más ligera que la revisión de lanzamiento, que suele resolverse en menos de un día. Los builds posteriores de la misma versión suelen salir sin una nueva revisión completa, salvo que cambie cosas que a Apple le importan. Para que esa revisión pase, rellene la información de prueba: qué probar, un correo de contacto y una cuenta de demostración si la app exige iniciar sesión.
4. Del lado del tester
Un tester instala la app TestFlight, abre el correo de invitación o el enlace público, acepta y pulsa Instalar. La app aparece en la pantalla de inicio con un punto naranja junto a su nombre, la señal de que es una beta. Cuando usted sube un nuevo build, TestFlight le avisa y puede actualizar automáticamente. Para enviar comentarios, hace una captura de pantalla y usa la hoja de compartir, o agita el dispositivo si usted lo ha activado; la captura y su comentario llegan a App Store Connect, junto con los registros de fallos de cualquier cierre inesperado que sufra la app durante las pruebas.
Límites, plazos y los errores que cuestan una semana
| Regla | Valor | Consecuencia |
|---|---|---|
| Testers internos | 100 por app, usuarios de App Store Connect | Añada primero a sus compañeros al equipo; necesitan un rol, no solo un correo |
| Testers externos | 10.000 por app, correo o enlace público | Un enlace público puede limitarse y cerrarse; los criterios del enlace reducen quién entra |
| Beta App Review | Primer build por grupo externo, normalmente en menos de un día | Planifique el primer build externo un día antes de necesitar testers en él |
| Validez del build | 90 días | Pasado ese plazo, la app deja de abrirse para los testers hasta que se sube un nuevo build |
| Procesamiento | De unos minutos a alrededor de una hora | No vuelva a subir un build porque «todavía no está»; espere el correo |
| Coste | Gratuito con el Developer Program | La membresía de 99 USD al año es la única tarifa |
Los retrasos de los que la gente se queja rara vez vienen de Apple. Vienen de estos errores:
- Dejar la pregunta de cifrado sin responder. El build se queda en Missing Compliance y las invitaciones nunca salen. Defina la clave de cifrado en la configuración una sola vez.
- Esperar que las pruebas externas sean instantáneas. Las internas son instantáneas; las externas esperan a la Beta App Review. Use un grupo interno para las primeras horas y el grupo externo para los primeros días.
- Sin notas de prueba, sin cuenta de demostración. La Beta App Review necesita una forma de entrar, exactamente igual que la revisión de lanzamiento. Un inicio de sesión que funciona ahorra un build rechazado.
- Invitar a la cuenta de Apple equivocada. La invitación va ligada al correo; si el dispositivo del tester usa otra cuenta de Apple, la invitación nunca coincide. Los enlaces públicos evitan el problema.
- Tratar TestFlight como un canal de distribución. Las guidelines prohíben usarlo para entregar una app al público en lugar de la App Store, y los builds mueren de todos modos a los 90 días.
TestFlight con Cadrant
Si su app se construyó con el creador de apps móviles de Cadrant, los pasos previos a TestFlight ya están resueltos: el build de iOS se ejecuta en su propia cuenta de Expo (el plan gratuito cubre 15 builds de iOS al mes), y Expo envía el binario terminado a su cuenta de App Store Connect, donde la ficha de la app y el certificado de distribución se crearon durante un flujo guiado. A partir de ahí, está en el camino estándar de TestFlight: abra App Store Connect, responda a la pregunta de cifrado si se la hacen, añada testers internos o un grupo externo e instale en sus dispositivos.
Lo que hay que comprobar ahí es lo que la vista previa del editor y Expo Go no pueden mostrar: las API nativas como la cámara, las notificaciones push y los selectores de archivos, los flujos de inicio de sesión y de datos contra su proyecto de Supabase, el rendimiento en un dispositivo real, y el comportamiento con permisos denegados o sin conexión. ¿Un error? Corríjalo en Cadrant, publique un nuevo build, distribúyalo y repita hasta estar listo para App Review. La documentación Probar con TestFlight enumera los clics exactos.
En resumen
- Subir, esperar el procesamiento, responder a la pregunta de cifrado: solo entonces puede instalar alguien.
- Los testers internos (100 miembros del equipo) reciben los builds al instante; los testers externos (10.000) esperan una Beta App Review en el primer build de una versión.
- Rellene las notas de prueba y una cuenta de demostración, invite mediante enlace público cuando pueda, y recuerde la caducidad a los 90 días.
- Pruebe en TestFlight lo que Expo Go no puede mostrar, porque el revisor sí lo verá.
Usado así, TestFlight no es un paso más antes del lanzamiento: es el lanzamiento, ensayado con personas reales en teléfonos reales, unos días antes.