TestFlight: qué es, pruebas beta y trabajo con builds

Qué es TestFlight

TestFlight es la forma legítima y única oficial de distribuir aplicaciones iOS para pruebas sin publicarlas en App Store. El servicio fue lanzado por Apple en 2014 después de adquirir la empresa del mismo nombre. Antes de TestFlight, los desarrolladores usaban distribución Ad Hoc con un límite de 100 dispositivos por temporada — TestFlight eliminó esta limitación y simplificó el proceso a unos pocos clics.

Por qué necesitas TestFlight

iOS tiene una política de seguridad estricta: una aplicación solo puede instalarse en un dispositivo a través de App Store o mediante certificados especiales. TestFlight resuelve el problema de las pruebas beta actuando como proxy entre el desarrollador y el tester: Apple verifica el build contra requisitos básicos, después de lo cual los testers reciben la aplicación a través de la aplicación TestFlight desde App Store, lo que no requiere confiar en archivos sin firmar.

TestFlight vs Ad Hoc vs Enterprise

Existen tres formas de distribuir aplicaciones iOS fuera de App Store: Ad Hoc (límite de 100 dispositivos, requiere el UDID de cada dispositivo), Enterprise (distribución interna sin límites, requiere un certificado Enterprise de Apple por $299/año) y TestFlight (hasta 10,000 testers, gratuito, no requiere recopilar UDID). TestFlight es la opción óptima para pruebas beta, Ad Hoc es adecuado para pruebas específicas de dispositivos y Enterprise para aplicaciones corporativas.

Cómo funciona TestFlight

El proceso de publicación de un build a través de TestFlight consta de cinco pasos: compilación en Xcode, carga en App Store Connect a través de Archive Organizer, procesamiento de Apple, invitación de testers e instalación de la aplicación a través de la aplicación TestFlight. Cada paso toma desde unos minutos hasta una hora dependiendo de la complejidad del proyecto.

Requisitos de Apple para el build

El build debe crearse con un certificado de distribución y un perfil de aprovisionamiento válido. Apple verifica: validez del certificado, coincidencia del bundle identifier, ausencia de API privadas, iconos correctos (1024×1024) y presencia del icono de App Store. Si el build no pasa la verificación, TestFlight muestra un error con una descripción del problema.

Procesamiento del build

Después de la carga, el build pasa por la verificación automatizada de Apple: análisis estático del código binario, verificación de la firma digital, escaneo de uso de API privadas y malware. El procesamiento toma de 15 minutos a 2 horas para el primer build y generalmente de 15 a 30 minutos para los siguientes. El estado del procesamiento se muestra en Activity en App Store Connect.

// Configuración de TestFlight en Swift AppDelegate
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Verificar: si la aplicación está instalada a través de TestFlight
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Versión beta a través de TestFlight")
        }
        return true
    }
}

Testers internos y externos

TestFlight divide a los testers en dos grupos: Testers Internos (Internal Testers) y Testers Externos (External Testers). La diferencia radica en la cantidad de participantes, el acceso a los builds y la necesidad de revisión de Apple. Elegir el grupo correcto acelera el proceso de prueba y cumple con las políticas de App Store.

Testers internos (Internal)

Hasta 100 participantes del equipo del programa Apple Developer. Para invitar a un tester interno, basta con añadir su Apple ID en App Store Connect — obtiene acceso inmediato a todos los builds. No se requiere revisión de Apple. Ideal para pruebas smoke diarias y verificación temprana de funcionalidades.

Testers externos (External)

Hasta 10,000 participantes que no forman parte del equipo de desarrollo. El primer build para testers externos pasa por una revisión básica de Apple (generalmente de 1 a 2 días). Los builds posteriores con cambios que no afectan la funcionalidad principal pueden pasar sin una revisión repetida. Los testers externos se invitan a través de correo electrónico o un enlace público.

Cómo cargar un build en TestFlight

La carga de un build en TestFlight se realiza a través de Xcode, Application Loader o la línea de comandos con xcrun. El método más común es a través de Xcode Archive Organizer después de crear un archivo del proyecto. Un método alternativo es la automatización a través de Fastlane para CI/CD Pipeline.

Carga manual a través de Xcode

Cree un archivo (Product → Archive), abra Organizer, seleccione el archivo y haga clic en Distribute App. Seleccione TestFlight como método de distribución, especifique el certificado y el perfil de aprovisionamiento. Xcode cargará el build en App Store Connect, donde aparecerá después del procesamiento. Todo el proceso toma de 10 a 20 minutos para la primera carga.

Automatización a través de Fastlane

Fastlane es la herramienta más popular para automatizar la carga de builds en TestFlight. El comando fastlane pilot carga el build y gestiona los testers sin abrir Xcode. La integración de Fastlane con un servidor CI/CD permite publicar builds en TestFlight automáticamente después de pasar todas las pruebas.

# Fastfile — carga de build en TestFlight
default_platform(:ios)

lane :beta do
    # Obtención de certificados mediante match
    match(type: "appstore")

    # Compilación y firma
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # Carga en TestFlight
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot carga automáticamente el IPA en App Store Connect, espera el procesamiento (si skip_waiting_for_build = false) y asigna el build a los grupos de testers seleccionados. El comando distribute_external: true envía inmediatamente el build a los testers externos después del procesamiento.

Carga a través de línea de comandos

Sin Fastlane, puede usar xcrun: xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD. altool es compatible con Apple para entornos CI y no requiere interfaz gráfica. La contraseña se pasa a través del llavero o una contraseña específica de la aplicación — no use contraseñas en texto plano.

Recopilación de comentarios y diagnóstico en TestFlight

TestFlight proporciona varios mecanismos de retroalimentación: un formulario de comentarios integrado, recopilación automática de registros de fallos, métricas de uso y capturas de pantalla. El equipo obtiene todos los datos en App Store Connect sin necesidad de integrar SDK de terceros para pruebas beta.

Formulario de comentarios integrado

El tester abre la aplicación TestFlight, selecciona su build y hace clic en Send Feedback. El formulario permite enviar un comentario de texto, adjuntar una captura de pantalla e indicar la gravedad. Todos los comentarios se recopilan en App Store Connect en TestFlight → Feedback. El desarrollador puede responder al comentario y el tester recibirá una notificación en la aplicación TestFlight.

Registros de fallos y diagnóstico

Cuando una aplicación falla, TestFlight recopila automáticamente un informe de fallo: pila de llamadas, versión del SO, modelo del dispositivo y hora del fallo. Los registros de fallos están disponibles en Xcode Organizer (Crashes) y App Store Connect (TestFlight → Crashes). Para obtener registros de fallos simbolizados, debe cargar los archivos dSYM con el build o por separado a través de Xcode.

Monitoreo de uso

TestFlight muestra métricas: número de instalaciones, testers activos, sesiones y fallos. Los análisis se actualizan diariamente y ayudan a evaluar la participación de los testers. Si ningún tester ha abierto la aplicación en una semana, vale la pena reconsiderar la comunicación con el grupo o la calidad del build.

De TestFlight a la publicación en App Store

TestFlight es una parte integral del proceso de publicación en App Store. El mismo build que pasó por pruebas beta a través de TestFlight puede enviarse a revisión de Apple sin recompilar — basta con hacer clic en un botón en App Store Connect. Esto elimina el riesgo de que el build de producción difiera del probado.

Enviar a revisión de la App

En App Store Connect, seleccione el build que superó las pruebas y haga clic en Submit for Review. Apple usa el mismo build de TestFlight — no se requiere volver a cargarlo. El tiempo de revisión suele ser de 1 a 3 días. Si el build es rechazado, corrija los problemas, cargue un nuevo build en TestFlight y repita el proceso.

Build final antes del lanzamiento

Se recomienda esperar de 24 a 48 horas después de la ronda final de pruebas en TestFlight antes de enviar a revisión. Este tiempo permite a los testers encontrar errores críticos que podrían pasar las pruebas automatizadas. El build release candidate (RC) en TestFlight es una práctica estándar para equipos iOS maduros.

Qué hacer después de la publicación

Los builds de TestFlight se vuelven automáticamente no disponibles para nuevas instalaciones después de que la versión de lanzamiento se publique en App Store. Los testers que ya instalaron la versión beta pueden seguir usándola durante 30 días después de la publicación del lanzamiento, después de lo cual la aplicación deja de abrirse. Asegúrese de que los testers actualicen a la versión de App Store.