Cómo distribuir apps de iOS y Android a testers

Para distribuir apps de iOS a testers, usa TestFlight (testers internos al instante, externos tras una breve Beta App Review) o un build ad hoc para dispositivos registrados. En Android, usa un track de pruebas de Google Play (interno, cerrado o abierto), Play internal app sharing para enlaces únicos, o comparte un APK firmado vía Firebase App Distribution o mediante descarga directa. La opción ideal depende de quiénes sean tus testers, cuántos sean y si necesitas que el build pase por la infraestructura de la tienda.

Esta guía compara cada opción, muestra cómo configurar cada una para una app Capacitor y enumera los errores más comunes que encuentran los testers.

Elegir un método

Reglas generales:

• ¿El mismo build que enviarás a la tienda? Usa TestFlight y los tracks de Play. El binario que usan los testers es el mismo que se promociona.
• ¿Builds diarios para QA? Testing interno en ambas tiendas o Firebase App Distribution.
• ¿Necesitas probar un cambio en la capa web en minutos? Envía un live update a un canal de prueba en lugar de un nuevo binario.

Antes de distribuir: firma

Cada build de prueba debe estar firmado.

• iOS los builds de prueba usan un perfil de App Store Connect perfil (TestFlight) o un Ad Hoc profile (instalación directa). Ambos usan un certificado de Apple Distribution. Ver Certificados de iOS y perfiles de aprovisionamiento explicados.
• Android los builds para los tracks de Play son AAB firmados con tu upload key. Para instalaciones directas necesitas un APK firmado con cualquier release key. Un APK de debug también se instala, pero se comporta distinto (es debuggable y tiene otra firma) y luego no se podrá actualizar con tu build de Play.

iOS: TestFlight

Sube un build

Desde Xcode: Producto > Archivo, luego Distribuir App > App Store Connect > Upload. Desde la CLI o CI, exporta un .ipa y súbelo con una clave API de App Store Connect, o deja que un servicio de cloud build lo haga.

Desde abril de 2026, los uploads deben compilarse con Xcode 26 o superior.

Añade esta clave a ios/App/App/Info.plist si tu app solo usa cifrado HTTPS estándar, App Store Connect no te preguntará sobre el cumplimiento de exportación en cada build:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

El procesamiento tarda entre unos minutos y una hora. Recibirás un email cuando el build esté listo.

Pruebas internas

1. En App Store Connect, abre tu app, TestFlight > Pruebas internas, y crea un grupo.
2. Añade miembros del equipo. Deben tener un rol en App Store Connect (Admin, App Manager, Developer, Marketing…). Hasta 100 personas.
3. Activar distribución automática así cada nuevo build va al grupo.
4. Los testers instalan la TestFlight app desde la App Store y aceptan la invitación.

No requiere revisión. Es la vía más rápida desde el upload hasta el teléfono.

Pruebas externas

1. TestFlight > Pruebas externas > + para crear un grupo.
2. Añade testers por email o habilita un enlace público con un límite opcional de testers.
3. Añade el build al grupo y completa Información de prueba (qué probar, email de feedback, descripción de la app beta y login de demo si hace falta).
4. Enviar para Revisión de la app beta. Se revisa el primer build de cada versión, normalmente en un día. Builds posteriores de la misma versión suelen aprobarse sin revisión completa.

El testing externo admite hasta 10.000 testers. Los testers pueden enviar capturas con feedback directamente desde TestFlight, que verás en App Store Connect.

Límites de TestFlight

• Los builds caducan después de 90 días.
• Los testers necesitan versiones de iOS compatibles con tu build (Capacitor 8 requiere iOS 15 o superior).
• Los builds de TestFlight usan la firma de producción de App Store, así que las notificaciones push usan el producción Entorno de APNs.
• Las compras in-app en TestFlight usan el sandbox y no generan cargos.

iOS: distribución ad hoc

Los builds ad hoc se instalan directamente en los dispositivos registrados en el portal de Apple Developer, sin TestFlight ni revisión de Apple.

1. Recopila el UDID de cada tester. Los testers pueden obtenerlo en su propio teléfono con el Buscador de UDID de iOS, o puedes leerlo desde Finder o Xcode cuando el dispositivo esté conectado.
2. Registra los dispositivos en Certificados, Identificadores y Perfiles > Dispositivos.
3. Crea un Ad Hoc perfil de aprovisionamiento que incluya esos dispositivos y descárgalo.
4. Compila un .ipa con ese perfil (Xcode: Distribuir App > Pruebas de Lanzamiento, que es el nombre más reciente de Ad Hoc).
5. Instálalo:
   • Arrastra el .ipa al dispositivo en Finder o Xcode > Window > Devices and Simulators.
   • O alójalo con un itms-services manifest vía HTTPS para que los testers puedan pulsar un enlace. Servicios como Firebase App Distribution lo hacen por ti.
6. En iOS 16 y versiones posteriores, instalar el .ipa desde un Mac (Xcode o Apple Configurator) requiere Modo de desarrollador en el dispositivo (Ajustes > Privacidad y seguridad). Las instalaciones desde un itms-services enlace no lo necesitan. Consulta cómo activar el Modo Desarrollador en iOS.

Añadir un nuevo tester implica registrar su UDID, regenerar el perfil y recompilar. Los espacios de dispositivos (100 por familia de dispositivos) solo se restablecen cuando se renueva tu año de membresía, así que no registres dispositivos a la ligera.

Android: canales de prueba de Google Play

Play Console tiene tres canales de prueba además de producción. Todos requieren un AAB firmado con tu upload key.

Pruebas internas

1. Pruebas > Pruebas internas > Probadores: crea una lista de correos (hasta 100 direcciones).
2. Crear nueva versión, sube el AAB, añade las notas de la versión, guarda y lanza.
3. Copia el enlace de opt-in y envíalo a los testers. Aceptan e instalan desde la Play Store.

Las versiones internas suelen estar disponibles en minutos y no esperan la revisión completa. La primera versión de una app nueva puede tardar más mientras Google procesa la aplicación.

Pruebas cerradas

Las pistas cerradas se revisan y admiten listas de correo o Google Groups. Esta es la pista que necesitas para 12 testers durante 14 días regla que aplica a las cuentas de desarrollador personal creadas después del 13 de noviembre de 2023, antes del acceso a producción. Usar un Google Group facilita que los testers se unan. Los detalles están en cómo crear cuentas de desarrollador en Apple y Google Play.

Testing abierto

Cualquiera puede unirse desde tu ficha de Play. Úsala para una beta pública cuando tu ficha de la tienda esté completa. El feedback de los testers abiertos es privado y no afecta tu valoración pública.

Nuestro Guía de beta testing en Android compara los tracks con más detalle.

Android: Uso compartido interno de apps

Internal app sharing es la forma más rápida de instalar cualquier APK o AAB en un dispositivo vía Play Store, sin reglas de versión code y sin revisión.

1. En Play Console, abre Compartir apps de forma interna (en Testing) y añade usuarios de carga.
2. Sube un APK o AAB. Obtendrás un link.
3. Los testers abren la app de Play Store, van a ajustes y pulsan en la versión de Play Store siete veces para mostrar los ajustes de desarrollador y activar Compartir apps de forma interna.
4. Los testers abren el enlace e instalan.

Es útil para QA de builds de pull requests, ya que no hace falta aumentar los version codes.

Android: APK directo y Firebase App Distribution

APK directo

Genera un APK de release firmado. Un proyecto Capacitor nuevo no tiene release configuración de firma, así que assembleRelease generaría un APK sin firmar que no se instalaría. Añade un signingConfigs.release bloque (ruta del keystore y contraseñas, que normalmente se leen de key.properties) a android/app/build.gradle y apunta buildTypes.release.signingConfig a él primero.

bun run build
bunx cap sync android
cd android && ./gradlew assembleRelease

Compartir android/app/build/outputs/apk/release/app-release.apk a través de un enlace. Los testers permiten que su navegador o gestor de archivos instale apps desconocidas y luego abren el archivo. Si ya tienen una versión de Play Store instalada, deben desinstalarla primero porque las firmas son distintas. También puedes instalar por USB con adb install -r app-release.apk (ver cómo activar las opciones de desarrollador en Android).

A partir del 30 de septiembre de 2026, los dispositivos Android certificados en Brasil, Indonesia, Singapur y Tailandia solo instalarán apps cuyo nombre de paquete esté registrado por un desarrollador verificado, con despliegue global previsto para 2027. Si tus testers están en esos países, registra el nombre del paquete en la Android Developer Console o Play Console. Las instalaciones a través de adb no se ven afectadas.

Firebase App Distribution

Firebase App Distribution funciona en ambas plataformas, envía invitaciones por correo y registra quién instaló qué build.

bun add -g firebase-tools
firebase login

firebase appdistribution:distribute android/app/build/outputs/apk/release/app-release.apk \
  --app 1:1234567890:android:abc123def456 \
  --groups "qa-team" \
  --release-notes "Fix checkout crash"

• Los testers de Android instalan desde el enlace del correo o la app App Tester.
• Los testers de iOS deben seguir estando en un perfil ad hoc (o de desarrollo). App Distribution recopila sus UDIDs cuando aceptan la invitación, pero eres tú quien los registra y recompila la app.
• La distribución AAB requiere vincular el proyecto de Firebase con Google Play.

Builds en la nube que dan link a los testers

Si no quieres mantener Macs y firmas en cada runner de CI, Build de Capgo compila apps de Capacitor en la nube. Para builds de prueba, puede omitir el envío a la tienda y subir el binario a un enlace de descarga temporal con un QR code:

# Android APK/AAB for testers, no Play upload
bunx @capgo/cli@latest build request com.example.app \
  --platform android --no-playstore-upload --output-upload --output-retention 2d

# iOS ad hoc build (no App Store submission)
bunx @capgo/cli@latest build request com.example.app \
  --platform ios --ios-distribution ad_hoc --output-upload

# iOS build uploaded to TestFlight for external groups
bunx @capgo/cli@latest build request com.example.app \
  --platform ios --ios-testflight-groups "Beta Testers"

Añadir --output-record build.json y leer el enlace en CI con bunx @capgo/cli@latest build last-output --path build.json --field outputUrl para publicarlo en un pull request o chat. La Docs de Build de Capgo enumera todas las opciones.

Evita recompilar por cambios web

La mayoría de los cambios en una app Capacitor están en la capa web. Recompilar y redistribuir un binario por un fix de texto hace perder un día de procesamiento y revisión de TestFlight. Con actualizaciones Live Update de Capgo, los testers mantienen la build que instalaron y tú envías nuevos bundles de JavaScript a un canal de prueba:

bunx @capgo/cli@latest bundle upload --channel beta

Incluso puedes dar a cada pull request su propio canal y dejar que QA cambie entre ellos en la misma app instalada. Consulta convierte cada pull request en una preview instalable.

Solución de problemas

“Unable to install” en iOS ad hoc. El UDID del dispositivo no está en el perfil o el perfil caducó. Revisa con security cms -D -i profile.mobileprovision.

La app se abre y se cierra inmediatamente en iOS. El Modo de desarrollador está desactivado (builds ad hoc/de desarrollo) o el perfil caducó.

La build de TestFlight atascada en “Processing”. Espera hasta una hora. Si falla, el email indica el motivo, a menudo falta un string de descripción de uso (NSCameraUsageDescription y similares) o un problema con el icono.

“Missing Compliance” en TestFlight. Responde a la pregunta de export compliance en App Store Connect o añade ITSAppUsesNonExemptEncryption a Info.plist.

Android: “App no instalada”. Ya hay una versión con otra firma instalada, o el APK no está firmado o está corrupto. Desinstala la app actual.

El tester no ve la app en la Play Store tras aceptar la invitación. Espera unos minutos, asegúrate de que haya iniciado sesión con la cuenta invitada y comprueba que el release se haya desplegado en el track y que su país esté disponible.

“La versión code ya ha sido usada” al subir. Subir versionCode en android/app/build.gradle. El uso compartido interno de apps es la excepción.

Las notificaciones push no llegan en TestFlight. TestFlight usa el entorno de producción de APNs. Revisa el aps-environment entitlement y la configuración del entorno de tu proveedor de push.

Configuración recomendada para un equipo pequeño

1. Grupo interno de TestFlight con distribución automática, además de una vía de pruebas internas de Play, para cada merge a main.
2. Un grupo externo de TestFlight y un canal de pruebas cerradas de Play para usuarios beta, con actualización semanal.
3. Actualizaciones en vivo en un beta canal para correcciones solo web entre builds.
4. Cuando la beta sea estable, promueve el mismo build a producción en ambas tiendas y sigue la guía para la primera revisión de la app.