Cómo distribuir aplicaciones iOS y Android a los probadores

Para distribuir aplicaciones iOS a los probadores, utilice TestFlight (probadores internos de inmediato, probadores externos después de una breve revisión de la aplicación beta) o un build ad hoc para dispositivos registrados. Para Android, utilice un track de prueba de Google Play (interno, cerrado o abierto), compartir una aplicación interna de Play para enlaces uno a uno, o compartir un APK firmado a través de Firebase App Distribution o un descarga directa. ¿Cuál es el correcto depende de quiénes son los probadores, cuántos hay y si necesita que el build pase por la infraestructura de la tienda.

Esta guía compara todas las opciones, muestra cómo configurar cada una para una aplicación Capacitor y enumera los errores que los probadores suelen encontrar.

Elige un método

Consejos generales:

• La misma compilación que enviarás a la tienda? Utilice TestFlight y Play Store. El binario que utilizan los probadores es el que se promociona.
• ¿Construcciones de QA diarias? Pruebas internas en ambas tiendas, o Firebase App Distribution.
• ¿Necesita probar un cambio en la capa web en minutos? Envíe un live update a un canal de prueba en lugar de un nuevo binario.

Antes de distribuir: firmado

Cada construcción de prueba debe estar firmada.

• iOS Las construcciones de prueba utilizan ya sea un perfil de App Store Connect perfil (TestFlight) o un Ad Hoc perfil (instalación directa). Ambos utilizan un certificado de distribución de Apple. Consulte certificados y perfiles de configuración de iOS explicados.
• Android los compilados para Play tracks son AABs firmados con su clave de carga. Para instalaciones directas necesita un APK firmado con cualquier clave de liberación. Un APK de depuración también instala, pero se comporta de manera diferente (depurable, firma diferente) y no puede ser actualizado por su compilado de Play más tarde.

iOS: TestFlight

Subir una compilación

Desde Xcode: Archivo > Product, luego Distribuir aplicación > App Store Connect > Subir. Desde la línea de comandos o CI, exporte un .ipa y subir con una clave de App Store Connect API, o deje que un servicio de compilación en la nube lo haga.

Desde abril 2026, los subidos deben ser construidos con Xcode 26 o posterior.

Agregue esta clave a ios/App/App/Info.plist Si su aplicación solo utiliza la cifrado HTTPS estándar, entonces App Store Connect no le hará la pregunta de cumplimiento de exportación para cada compilación.

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

El procesamiento toma desde unos minutos hasta alrededor de una hora. Recibirá un correo electrónico cuando la construcción esté lista.

Pruebas internas

1. En App Store Connect abra su aplicación, TestFlight > Pruebas internas, y cree un grupo.
2. Agregue miembros del equipo. Deben tener un rol de App Store Connect (Administrador, Gerente de Aplicación, Desarrollador, Marketing…). Hasta 100 personas.
3. Habilite distribución automática para que cada nueva construcción vaya al grupo.
4. Los probadores instalan el TestFlight app desde la Tienda de Aplicaciones y aceptan la invitación.

No se necesita revisión. Este es el camino más rápido desde la carga hasta el teléfono.

Pruebas externas

1. TestFlight > Pruebas externas > + para crear un grupo.
2. Add testers by email, or enable a enlace público con un límite de probadores opcional.
3. Agregar la compilación al grupo y rellenar Información de prueba (what to test, feedback email, beta app description, and demo login if needed).
4. Enviar para Revisión de Aplicación Beta. La primera compilación de cada versión se revisa, generalmente dentro de un día. Las compilaciones posteriores de la misma versión a menudo salen sin una revisión completa.

La prueba externa admite hasta 10,000 probadores. Los probadores pueden enviar capturas de pantalla con comentarios directamente desde TestFlight, que se muestran en App Store Connect.

Limitaciones de TestFlight para saber

• Las compilaciones caducan después de 90 días.
• Los probadores necesitan versiones de iOS compatibles con su compilación (Capacitor 8 requiere iOS 15 o posterior).
• TestFlight utiliza la firma de la tienda de aplicaciones de producción, por lo que las notificaciones push utilizan production Entorno de APNs.
• In-app purchases en TestFlight utilizan el entorno de pruebas y no se cobran.

iOS: distribución ad hoc

Construye instalaciones ad hoc directamente en dispositivos que registraste en el portal del desarrollador de Apple, sin TestFlight ni revisión de Apple.

1. Recolecte el UDID de cada tester. Los testers pueden obtenerlo en su propio teléfono con el Finder de UDID de iOS, o puede leerlo desde Finder o Xcode cuando el dispositivo esté conectado.
2. Registre los dispositivos en Certificados, Identificadores y Perfiles > Dispositivos.
3. Crear un Ad Hoc perfil de configuración que incluye esos dispositivos y descargarlo.
4. Construya un .ipa con ese perfil (Xcode: Distribuye la App > Pruebas de Lanzamiento, que es el nombre más nuevo para Ad Hoc).
5. Instálalo:
   • Arrastra el .ipa al dispositivo en Finder o Xcode > Ventana > Dispositivos y Simuladores.
   • O hospédalos con un itms-services manifesto sobre HTTPS para que los probadores puedan tocar un enlace. Servicios como Firebase App Distribution lo hacen por usted.
6. En iOS 16 y posterior, instalar el .ipa desde un Mac (Xcode o Apple Configurator) requiere Modo de Desarrollador On el dispositivo (Configuración > Privacidad y seguridad). Instalaciones desde un itms-services No es necesario. Consulte ¿Cómo habilitar el modo de desarrollador en iOS?.

Al agregar un nuevo tester significa registrar su UDID, regenerar el perfil y reconstruir. Los slots de dispositivo (100 por familia de dispositivo) solo se restablecen cuando se renueva su año de membresía, así que no registre dispositivos con ligereza.

Pruebas de Google Play para Android

El Console de Play tiene tres pistas de prueba más producción. Todas ellas necesitan un AAB firmado con su clave de carga.

Pruebas internas

1. Pruebas > Pruebas internas > Testers: crea una lista de correos electrónicos (hasta 100 direcciones).
2. Crear nueva versión, subir el AAB, agregar notas de versión, guardar y desplegar.
3. Copia el opt-in link y enviarlo a los probadores. Ellos aceptan e instalan desde la Tienda de Juegos.

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

pruebas cerradas

Los tracks cerrados se revisan y se envían correos electrónicos de soporte o a grupos de Google. Este es el track que necesita para 12 probadores durante 14 días regla que se aplica a las cuentas de desarrollador personales creadas después del 13 de noviembre de 2023, antes del acceso a producción. Utilizar un Grupo de Google hace que sea fácil para los probadores unirse. Los detalles están en ¿cómo crear cuentas de desarrollador de Apple y Google Play?.

pruebas abiertas

Cualquiera puede unirse desde tu lista de juegos. Utilízalo para una beta pública una vez que tu lista de tienda esté completa. Los comentarios de los probadores abiertos son privados y no afectan tu calificación pública.

nuestro guía de pruebas de beta de Android compara los tracks con más detalle.

Android: Compartir la aplicación interna

Compartir la aplicación interna es la forma más rápida de obtener cualquier APK o AAB en un dispositivo a través de la tienda Play, sin reglas de versión code y sin revisión.

1. En la consola de Play, abre Compartir la aplicación interna (en Pruebas) y agrega subidores.
2. Sube un APK o AAB. Obtienes un enlace.
3. Los probadores abren la aplicación de la tienda Play, van a ajustes, tocan la Versión de la tienda Play seis veces para revelar ajustes de desarrollador, y activa Compartir la aplicación interna.
4. Los probadores abren el enlace y instalan.

Es útil para la QA de builds de solicitudes de revisión porque los códigos de versión no necesitan aumentar.

Android: distribución directa de APK y Firebase App Distribution

Directo APK

Construya un APK de liberación firmado. Un nuevo proyecto Capacitor no tiene release configuración de firma assembleRelease Produciría un APK no firmado que no se instalará. Agregue un signingConfigs.release block (ruta del keystore y contraseñas, generalmente leídas desde key.propertiesComparte android/app/build.gradle y punto buildTypes.release.signingConfig al principio.

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

Direct APK android/app/build/outputs/apk/release/app-release.apk through a link. Testers allow their browser or file manager to install unknown apps and open the file. If they already have a Play Store version installed, they must uninstall it first because the signatures differ. You can also install over USB with adb install -r app-release.apk (ver) ¿Cómo habilitar opciones de desarrollador en Android).

Desde el 30 de septiembre de 2026, los dispositivos Android certificados en Brasil, Indonesia, Singapur y Tailandia solo instalan aplicaciones cuyo nombre de paquete está registrado por un desarrollador verificado, con un lanzamiento global previsto para 2027. Si tus probadores están en esos países, regístrate el nombre de paquete en el Console de Desarrollador de Android o en el Console de Play. Las instalaciones a través de adb no están afectadas.

Firebase Distribución de Aplicaciones

Firebase App Distribution funciona para ambas plataformas, envía invitaciones por correo electrónico y rastrea quién instaló qué versión.

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"

• Android testers install from the email link or the App Tester app.
• Los probadores de iOS deben estar aún en un perfil ad hoc (o de desarrollo). La distribución de aplicaciones recopila sus UDIDs cuando aceptan la invitación, pero tú los registras y los reconstruyes tú mismo.
• La distribución de AAB requiere vincular el proyecto de Firebase a Google Play.

Cloud builds that hand testers a link

Si no deseas mantener Macs y firmas en cada ejecutor de CI Capgo Construcción construye Capacitor aplicaciones en la nube. Para las compilaciones de prueba, puede saltarse la presentación en la tienda y subir el binario a un enlace de descarga temporal con un código 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"

Agregar --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 una solicitud de extracción o chat. El Capgo Documentación de compilación listar todas las opciones.

Saltar la reconstrucción para cambios en la web

La mayoría de los cambios en una Capacitor aplicación están en la capa de web. Reconstruir y redistribuir un binario para una corrección de texto desperdicia un día de procesamiento y revisión de TestFlight. Con Capgo actualizaciones en vivo, los probadores mantienen la compilación que instalaron, y usted envía nuevos paquetes de JavaScript a un canal de prueba:

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

Incluso puede dar a cada solicitud de extracción su propio canal y dejar que QA cambie entre ellos en la misma aplicación instalada. Vea cómo convertir cada solicitud de extracción en una vista previa instalable.

Troubleshooting

“No se puede instalar” en iOS ad hoc. El ID de dispositivo no está en el perfil, o el perfil ha expirado. Verifique con security cms -D -i profile.mobileprovision.

La aplicación se abre y cierra inmediatamente en iOS. El modo de desarrollador está apagado (edición ad hoc/ de desarrollo) o el perfil ha expirado.

TestFlight build stuck in “Processing”. Espera hasta una hora. Si falla, el correo electrónico enumera la razón, a menudo una cadena de descripción de uso faltante (NSCameraUsageDescription y similares) o un problema con un icono.

TestFlight “Falta de Cumplimiento”. Responda a la pregunta de cumplimiento de exportación en App Store Connect o agregue ITSAppUsesNonExemptEncryption to Info.plist.

Aplicación de Android no instalada. Ya está instalada una versión con una firma diferente, o el APK no está firmado o está dañado. Desinstale la aplicación existente.

El tester no ve la aplicación en la tienda Play después de optar por ella. Espera unos minutos, asegúrate de que estén conectados con la cuenta invitada y verifica que la liberación esté disponible en el canal y su país esté disponible.

“Ya se utilizó la versión code” al subir. Incrementar versionCode en android/app/build.gradleLa compartición de aplicaciones internas es la excepción.

Las notificaciones de push no llegan a TestFlight. TestFlight utiliza el entorno de producción de APNs. Verifica la aps-environment permiso y la configuración de su proveedor de notificaciones.

Configuración recomendada para un equipo pequeño

1. Un grupo de TestFlight interno con distribución automática, más un canal de pruebas de Play interno, para cada merge a main.
2. Un grupo externo de TestFlight y un canal de pruebas cerrado de Play para usuarios beta, actualizado semanalmente.
3. Actualizaciones en vivo en un beta canal para arreglos web únicamente entre compilaciones.
4. Cuando el beta esté estable, promueva la misma compilación a producción en ambas tiendas y siga la guía de revisión de aplicaciones para primerizos.