TestFlight: cómo probar tu app de iPhone antes de enviarla

¿Qué es TestFlight y para qué sirve?

TestFlight es el servicio de Apple que te permite instalar tu app en iPhone reales antes de que salga en el App Store. Envías una build a App Store Connect, invitas a testers y ellos la instalan con la app TestFlight, gratuita en el App Store. Hay dos tipos de testers: los internos, hasta 100 miembros de tu equipo, sin revisión de Apple; y los externos, hasta 10 000 personas, invitadas por correo o por enlace público, después de una revisión beta de tu primera build. Cada build se puede probar durante 90 días.

Criterio	Testers internos	Testers externos
Número máximo	100	10 000
Acceso a tu cuenta	Sí, con un rol	No
Invitación	Se agregan al grupo interno	Correo o enlace público
Revisión beta de Apple	Ninguna	En la primera build
Para quién	Tú, un socio, alguien cercano	Amigos, primeros usuarios

Para usar TestFlight necesitas una cuenta de Apple Developer de pago: el servicio no está disponible con una cuenta gratuita. Todo el resto de esta guía da por hecho que tienes una, con el programa estándar: el programa Enterprise de Apple no da acceso a TestFlight.

En mis apps, cada build enviada con EAS Submit pasa por TestFlight y por mi iPhone antes de mandarla a revisión. Ahí es donde encuentro los problemas que no se ven en desarrollo.

Enviar una build a TestFlight

Una build es una versión compilada y firmada de tu app: si está mal firmada, Apple la rechaza al enviarla con ITMS-90034. Para que aparezca en TestFlight, tienes que enviarla a App Store Connect. Con Expo, es eas build --platform ios y luego eas submit --platform ios, con una imagen de build lo bastante reciente para evitar ITMS-90725. Según la documentación de Expo, la build aparece en TestFlight cuando Apple termina de procesarla, normalmente en 10 a 15 minutos. Puedes hacer todo esto desde una PC: la guía publicar una app iOS sin Mac detalla el proceso completo.

Dos detalles suelen trabar la primera vez:

• El número de build tiene que cambiar en cada envío. Apple rechaza dos builds con el mismo número para una misma versión. Con EAS, activa el incremento automático y te olvidas.
• La pregunta sobre el cifrado. Mientras no respondas la pregunta sobre el uso de cifrado, la build se queda bloqueada con el estado Missing Compliance. Puedes responderla cada vez en App Store Connect o declararlo de una vez por todas en la configuración de tu app.

Testers internos: tu equipo, sin esperar

Los testers internos son usuarios de tu cuenta de App Store Connect con un rol asignado. Apple permite hasta 100, y cada uno puede instalar la app en varios dispositivos, hasta 30.

Su gran ventaja: no hay revisión beta. En cuanto la build termina de procesarse, sin errores automáticos como ITMS-90717, la agregas a tu grupo interno y ya está disponible. Es el grupo adecuado para ti, y para un socio o alguien cercano al que le des acceso a tu cuenta.

Su límite: hay que agregarlos como usuarios de tu cuenta de App Store Connect. No sirve para desconocidos.

Testers externos y revisión beta

Los testers externos no necesitan ningún acceso a tu cuenta. Puedes invitar hasta 10 000, por correo o por enlace público. Es el grupo adecuado para amigos, primeros usuarios, una comunidad.

A cambio, Apple revisa la build antes de abrírsela. Cuando agregas la primera build de una versión a un grupo externo, pasa a revisión beta. Las builds siguientes de la misma versión no siempre requieren una revisión completa.

Antes de ese envío, App Store Connect te pide información de prueba:

• una descripción de la beta, que les dice a los testers qué deben revisar;
• un correo electrónico para los comentarios;
• tus datos de contacto, para que Apple pueda comunicarse contigo.

La revisión beta no es la revisión del App Store. Una build aceptada en TestFlight todavía puede ser rechazada al publicarla.

La revisión beta comprueba que la build cumple las reglas, pero la revisión final también mira tu ficha, tus suscripciones, tus textos legales y la experiencia completa. Ten presentes los motivos de rechazo clásicos, que cuento en por qué Apple rechaza una app.

Invitar testers con un enlace público

El enlace público es la forma más sencilla de que gente que todavía no conoces pruebe tu app. Estos son los pasos de Apple, con las etiquetas de la interfaz en inglés:

1. En App Store Connect, abre tu app y luego la pestaña TestFlight.
2. En External Testing, selecciona tu grupo externo.
3. Haz clic en Create Public Link.
4. Elige Open to Anyone para abrir el enlace a todos, o Filter by Criteria para limitarlo a ciertos dispositivos y versiones de iOS.
5. Si quieres, fija un límite de testers con Set Limit.

Después compartes el enlace donde quieras: mensaje, red social, correo. La persona instala la app TestFlight, abre el enlace y acepta la invitación.

Dos cosas que debes saber antes de difundirlo mucho:

• Fija un límite. Si tu enlace circula más de lo previsto, mantendrás el control del número de testers.
• Los testers por enlace público son anónimos. App Store Connect solo muestra su fecha de instalación, sus sesiones y sus cierres inesperados. Si quieres saber quién probó qué, mejor invítalos por correo.

¿Cuánto dura una build de TestFlight?

Una build está disponible para los testers durante 90 días. Después caduca y tus testers ya no pueden abrirla. Si tu beta dura más, simplemente envía una nueva build antes de que venza.

En la práctica, vas a enviar builds nuevas mucho más seguido: con cada corrección importante. Cada build nueva que agregas al grupo se les ofrece a tus testers, que la descargan desde la app TestFlight.

Recibir los comentarios de los testers

TestFlight incluye un sistema de comentarios: el tester toma una captura de pantalla en tu app, puede hacerle anotaciones y te la envía. Si la app se cierra inesperadamente, recibes un informe del fallo, y el tester puede agregar contexto. Encuentras todo en App Store Connect.

Es útil, pero no basta para entender un fallo concreto. En mis apps agrego Sentry, que reporta el error con la línea de código responsable, y PostHog, que muestra dónde abandonan los usuarios. Los dos funcionan igual en una build de TestFlight que en producción.

Probar las suscripciones en TestFlight

Si tu app vende una suscripción, TestFlight es donde compruebas que de verdad funciona. Las compras hechas en una build de TestFlight pasan por el entorno de pruebas de Apple: a tus testers no se les cobra. Las renovaciones van aceleradas: cada suscripción se renueva una vez al día, como máximo seis veces en una semana, sea cual sea su duración real.

Comprueba como mínimo que los precios mostrados son los correctos, que la compra desbloquea la app y que el botón de restaurar recupera la suscripción después de reinstalar. Uso RevenueCat para gestionar las suscripciones de mis apps; toda la configuración, desde los productos de App Store Connect hasta el paywall, está explicada en la página suscripciones in-app en iOS.

Lo que debes probar antes de enviar a Apple

Esta es la lista que sigo antes de cada envío a revisión. Cada punto corresponde a un motivo de rechazo o a un fallo evitable.

El primer inicio

• Borra la app, reinstálala desde TestFlight y ábrela. Es lo que hará el revisor.
• Recorre el onboarding completo, sin saltarte nada.
• Rechaza cada permiso (notificaciones, cámara, ubicación) y comprueba que la app sigue funcionando.

El dinero

• El paywall muestra los precios, la duración y los enlaces a los términos de uso y a la política de privacidad.
• La compra funciona, y la restauración también.
• Todos los productos configurados son visibles para el revisor: la guideline 2.1 exige que las compras in-app estén completas, visibles y funcionen.

Las condiciones difíciles

• El modo avión y una red lenta: un mensaje claro, no una pantalla en blanco.
• El iPhone más pequeño que soportas y el más grande: nada cortado, nada tapado por el teclado. Una pantalla cortada en un iPhone pequeño me costó un rechazo en Solys.
• Los textos largos, si tu app está traducida.

El paquete para el revisor

• Si tu app pide iniciar sesión, una cuenta de demostración en las notas de revisión, con tu backend encendido. La guideline 2.1 lo pide explícitamente.
• Notas de revisión que expliquen en dos frases qué hace la app y dónde encontrar la función principal.

Si aun así rechazan tu app, la página app rechazada por Apple explica cómo responder sin perder una semana. Y para tener la visión completa de la publicación, de la ficha al lanzamiento, lee publicar una app en el App Store.

Una planilla de pruebas para llenar con tu build

Descarga la planilla de 16 escenarios en formato CSV. Separa la preparación, la acción que hay que hacer, el resultado esperado y la evidencia observada. Impórtala en Numbers, Excel o Google Sheets, y luego anota la versión, el dispositivo y el resultado de cada prueba.

Para un diario de lectura ficticio, "guardar una página" no basta: anota la página 24, cierra la app por completo, vuelve a abrirla y encuentra el valor. Una prueba que no se ejecutó se queda en "Por probar". Si tu app no tiene suscripciones, marca "No aplica" en los escenarios de compra, con ese motivo.

La planilla es un punto de partida que debes adaptar, no una certificación. También encontrarás las notas para App Review y las otras plantillas gratuitas para explicarle al revisor el recorrido que realmente comprobaste.

Pasar de TestFlight al App Store

TestFlight es la etapa en la que tu app se vuelve real: funciona en un iPhone de verdad, en manos de gente de verdad. En el recorrido del iOS Kit, es la segunda etapa: construir el núcleo de la app y probarla en tu iPhone con TestFlight, antes de conectar las suscripciones y preparar la publicación.

Después de TestFlight viene la revisión de Apple: el Apple Review Kit reúne mi checklist antes del envío y las notas para el revisor. La página de inicio muestra las cuatro etapas para crear tu app móvil con Claude Code.

Nadie puede garantizarte que Apple aceptará tu app: la decisión es de Apple.

Preguntas frecuentes

¿Cómo probar tu app de iPhone con TestFlight?

Envía una build a App Store Connect y luego agrégala a un grupo de testers. Con Expo, la compilas con EAS Build y la envías con EAS Submit: aparece en TestFlight cuando Apple termina de procesarla, normalmente en 10 a 15 minutos según Expo. Tus testers la instalan con la app TestFlight, gratuita en el App Store. Necesitas una cuenta de Apple Developer de pago.

¿Cómo generar un enlace de TestFlight para invitar testers?

En App Store Connect, abre la pestaña TestFlight de tu app, selecciona tu grupo en External Testing y haz clic en Create Public Link. Elige Open to Anyone o Filter by Criteria, y luego fija un límite con Set Limit. Los testers por enlace público son anónimos: si quieres saber quién probó qué, mejor invítalos por correo.

¿La revisión beta de TestFlight reemplaza la revisión del App Store?

No. La revisión beta comprueba que la build cumple las reglas, pero la revisión final también mira tu ficha, tu age rating, tus suscripciones, tus textos legales y la experiencia completa. Por eso una build aceptada en TestFlight todavía puede ser rechazada al publicarla. Solo los testers externos activan una revisión beta, en la primera build de una versión: los testers internos no pasan ninguna.

¿Cuántos testers se pueden invitar en TestFlight?

Puedes invitar hasta 100 testers internos y hasta 10 000 testers externos. Los internos son miembros de tu cuenta de App Store Connect, sin revisión beta, y cada uno puede instalar la app en hasta 30 dispositivos. Los externos se invitan por correo o por enlace público, después de una revisión beta de la primera build. Cada build se puede probar durante 90 días.

¿Se puede probar una suscripción en TestFlight sin que te cobren?

Sí, las compras hechas en una build de TestFlight pasan por el entorno de pruebas de Apple: a tus testers no se les cobra. Las renovaciones van aceleradas: cada suscripción se renueva una vez al día, como máximo seis veces en una semana, sea cual sea su duración real. Comprueba como mínimo los precios mostrados, el desbloqueo de la app y la restauración después de reinstalar. La configuración completa está explicada en suscripciones in-app en iOS.

¿Qué hay que revisar en TestFlight antes de enviar la app a Apple?

Reinstala la app desde TestFlight, como lo hará el revisor, y recorre el onboarding completo. Rechaza cada permiso, prueba la compra y la restauración, y luego prueba el modo avión, el iPhone más pequeño y el más grande que soportas. Si la app pide iniciar sesión, prepara una cuenta de demostración en las notas de revisión, con tu backend encendido.