Saltar al contenido

Por qué TestFlight no sirve para distribuir la app de la empresa

Pedro Cunha
Pedro Cunha
CTO de Epicora

Publicado el
actualizado el · 13 min de lectura

En resumen

TestFlight es la herramienta de pruebas de Apple: cada build dura 90 días y después deja de estar disponible para quien lo instaló, así que no sirve para que el equipo use la app todos los días. El camino correcto depende de quién la usa. La app para el público va a la tienda; la app del propio equipo va a la tienda con un acceso que entrega la empresa, o sale como app privada o no listada; la app hecha para una empresa cliente sale como app privada para esa organización, en Apple y en Google. El Enterprise Program de Apple no es un atajo: exige 100 empleados o más y es solo para uso interno.

¿Se puede distribuir la app de la empresa por TestFlight?#

No. TestFlight es la herramienta de pruebas de Apple, y cada build (la versión de la app que se sube para probar) dura 90 días. Después, según la propia Apple, el build deja de estar disponible para los testers, y quien usaba la app por esa vía se queda sin ella hasta que alguien suba una versión nueva. Para el uso diario, la app de la empresa necesita salir por un canal de distribución.

La pregunta suele aparecer en el mismo momento del proyecto. La app está lista, el equipo ya la probó por TestFlight y alguien propone dejarla así, sin pasar por la tienda. La idea parece práctica porque funciona el primer día.

La propia Apple dice para qué existe TestFlight. En las pautas de revisión de la App Store, la sección 2.2 indica poner las versiones de prueba en TestFlight y no en la tienda, y dice que toda app enviada a TestFlight debe estar pensada para la distribución pública. Es decir, Apple trata a TestFlight como la etapa previa a la tienda.

Qué pasa cuando el equipo usa la app por TestFlight#

El equipo pasa a depender de un plazo de 90 días, de un límite de personas y de una cuenta que no se hizo para eso. El tester interno tiene que ser usuario de la cuenta de desarrollador, y el externo depende de una revisión de Apple. En los dos casos, alguien tiene que subir un build nuevo antes del plazo, cada trimestre.

Tester internoTester externo
Quién puede serlousuario de App Store Connect con un rol en la cuenta (Admin, Developer, Marketing y otros)cualquier persona invitada por correo o por un enlace público
Límite100 personas10.000 personas
Revisión de Appleno pasael primer build pasa por revisión
Duración de cada build90 días90 días

Los números son de la documentación de TestFlight en App Store Connect. La primera fila es la que más pesa para una empresa: para sumar al equipo de ventas como testers internos, cada vendedor recibe un rol dentro de la cuenta que publica la app. Y las cuentas que la propia empresa administra con Apple Business, creadas en un dominio reservado, no pueden probar builds, también según Apple.

El plazo es el punto que ninguna configuración resuelve. Si nadie sube el build nuevo a tiempo, todo el equipo se queda sin la app el mismo día. En nuestro estándar de publicación, ese es el motivo por el que TestFlight está descartado como canal de producción.

Para qué sirve TestFlight en un proyecto#

TestFlight sirve para que quien va a usar la app vea la versión antes que la tienda. En nuestros proyectos entra en dos momentos: cuando el cliente valida la app mientras la tienda revisa la primera versión, y cuando la revisión se atrasa y alguien necesita seguir probando. El equivalente en Android es la prueba interna de Google Play.

En GT, una empresa brasileña de gestión de mantenimiento de equipos pesados, la app se envió a Apple y a Google el 18 de agosto. Al día siguiente, los responsables de GT recibieron acceso por TestFlight y probaron la app mientras las tiendas hacían la revisión, y las pruebas terminaron esa misma semana. En nuestros planes semanales de proyectos con app, el plan B se repite: si la revisión de la tienda se atrasa, el cliente sigue por TestFlight o por la prueba interna de Google.

La prueba interna de Google Play cumple bien ese papel. Acepta hasta 100 testers, y cada versión queda disponible en minutos. El propio Google advierte que estas pruebas pueden no pasar por las revisiones habituales de políticas y seguridad. Eso agiliza la prueba, y es también el motivo para no usar la prueba interna como canal del equipo: son 100 personas como máximo, cargadas en una lista de correos.

El camino correcto para cada caso#

El camino depende de quién va a usar la app. La app para el público va a la tienda. La app del propio equipo va a la tienda con un acceso que entrega la empresa, o sale como app privada o no listada. La app hecha para una empresa cliente sale como app privada para esa organización, en las dos tiendas.

El casoEl camino en AppleEl camino en GoogleSi se usa TestFlight
App para el público (clientes, pacientes, alumnos)App StoreGoogle Playla app no aparece en la tienda, y cada build dura 90 días
App del propio equipo, sin gestión de dispositivosApp Store con acceso entregado por la empresa, o app no listadaGoogle Play con acceso entregado por la empresacada empleado pasa a ser usuario de la cuenta o tester externo, y la app deja de funcionar si el build vence
App del propio equipo, con gestión de dispositivosapp privada en el Apple Business de la empresaapp privada en Google Play administradolos mismos problemas, con el camino privado ya disponible
App para una empresa cliente (B2B)app privada para la organización del cliente en Apple Businessapp privada para la organización del clienteel cliente depende de que subas un build cada 90 días

App para el público#

La app para el público va a la App Store y a Google Play, con la revisión de cada versión. En Google, una cuenta personal creada después del 13 de noviembre de 2023 necesita antes una prueba cerrada con al menos 12 testers durante 14 días seguidos. Esa exigencia es de las cuentas personales. Para una app de empresa, la cuenta debe ser de la empresa, porque es la cuenta la que define quién es dueño de la app, como explicamos en de quién debe ser la cuenta de la App Store.

App para el propio equipo#

En la mayoría de nuestros proyectos, la app del equipo va a la tienda pública con acceso cerrado. En Beckers, la app Android de los técnicos está publicada en Google Play como app corporativa, sin registro público, y solo entra quien recibe correo y contraseña de la empresa. Para una app con inicio de sesión, Apple pide en la revisión una cuenta de demostración con el servidor encendido (pauta 2.1).

Cuando la empresa no quiere la app en la búsqueda de la tienda, Apple ofrece la distribución no listada. La app está en la App Store, se instala y se actualiza como cualquier otra, y solo llega a ella quien tiene el enlace. Apple da como ejemplo herramientas de venta para socios y recursos para empleados, y rechaza la solicitud si la app está en fase de prueba.

Cuando la empresa administra los dispositivos del equipo, la app puede ser privada. En Apple, aparece solo en el Apple Business de la empresa, el antiguo Apple Business Manager, que Apple unificó con otros servicios en una plataforma gratuita en abril de 2026. La documentación dice que este camino incluye apps propias para uso interno. En Google, la app privada llega por Google Play administrado, a través del sistema de gestión de dispositivos que la empresa ya usa.

App para una empresa cliente#

Cuando la app se hace para los empleados de otra empresa, el camino es la app privada para esa organización. En Apple, la app se asigna al identificador de la organización del cliente en Apple Business. En Google, la misma app privada puede ir a hasta 1.000 organizaciones, y Google prevé que la empresa de desarrollo publique directo para el cliente con el identificador de organización que él le envía.

Esta decisión se toma antes de la primera publicación. En Apple, el método de distribución no cambia una vez aprobada la app, y pasar de privada a pública exige un registro nuevo. En Google, la app privada solo se vuelve pública como una app nueva, con otro nombre de paquete.

Por qué el Enterprise Program no es un atajo#

El Apple Developer Enterprise Program sirve para que una empresa grande distribuya apps de uso interno a sus empleados, fuera de la tienda. Exige 100 empleados o más, una entrevista de verificación y evaluación continua, y cuesta US$ 299 al año. No sirve para distribuir apps a clientes, y el certificado puede ser revocado, lo que deja sin funcionar todas las apps firmadas con él.

La página del programa dice que es solo para los casos que la App Store, las apps privadas, Ad Hoc y TestFlight no cubren. El contrato del programa, en su versión del 8 de junio de 2026, es directo: para distribuir a terceros, la empresa tiene que usar la App Store o la distribución de apps privadas. En la misma versión, Apple se reserva el derecho de revocar los certificados en cualquier momento, incluso cuando la empresa incumple el contrato.

Lo que implica la revocación está en la documentación de certificados de Apple: los usuarios ya no pueden abrir las apps firmadas con ese certificado. Cuando un proveedor usa una cuenta Enterprise para entregar apps a varios clientes, una revocación causada por un cliente deja sin funcionar las apps de todos los demás.

¿Y Ad Hoc?#

Ad Hoc instala la app directamente en dispositivos registrados, fuera de la tienda. Cada cuenta puede registrar hasta 100 iPhone por año de membresía, uno por uno, y el contador solo se renueva al inicio de cada año de membresía. Sirve para una prueba con pocos dispositivos, y no para un equipo que suma gente nueva todos los meses.

¿Y mandar el APK directo en Android?#

Android todavía instala una app enviada como archivo, pero Google empezó a cerrar ese camino. Desde el 30 de septiembre de 2026, en Brasil, Indonesia, Singapur y Tailandia, las apps instaladas desde las tiendas participantes, entre ellas Google Play y Galaxy Store, tienen que estar registradas por un desarrollador verificado. Google anunció que extenderá la verificación a todas las apps en dispositivos Android certificados a partir de 2027.

Qué decidir antes de desarrollar la app#

Antes del desarrollo, cuatro respuestas definen la distribución, y todas caben en una reunión de alcance:

  1. Quién usa la app: el público, el equipo de la empresa o los empleados de un cliente.
  2. ¿La empresa administra los dispositivos? Si no los administra, la app privada de Google no es una opción, y el camino es la tienda con acceso entregado por la empresa.
  3. En qué cuenta se va a publicar la app, y si es una cuenta de empresa o personal, por la prueba de 14 días de Google.
  4. ¿La app va a cobrar algo dentro de ella? Si es así, entran las reglas de pago de las tiendas, explicadas en cuándo la app paga comisión a Apple y a Google.

Si todavía no está claro si el sistema realmente necesita una app, la pregunta anterior está en app o sistema web.

Preguntas frecuentes#

¿La app instalada por TestFlight deja de funcionar a los 90 días?#

El build deja de funcionar, sí. Según Apple, un build se puede probar durante hasta 90 días y después deja de estar disponible para los testers. Quien usa la app por esa vía solo la conserva si se sube un build nuevo antes del plazo y cada persona instala la versión nueva. Cuando la app se publica en la tienda, ese plazo no existe.

¿Puedo usar la prueba interna de Google Play para distribuir la app al equipo?#

Funciona un tiempo, pero no es el canal correcto. La prueba interna acepta hasta 100 testers, cargados en una lista de correos, y Google advierte que estas pruebas pueden no pasar por las revisiones habituales de políticas y seguridad. Para un equipo que usa la app todos los días, el camino es publicarla en la tienda con un acceso que entrega la empresa, o una app privada por Google Play administrado.

¿Necesito un sistema de gestión de dispositivos (MDM) para tener una app privada?#

En Google, sí: la app privada llega por Google Play administrado, a través de un sistema de gestión de dispositivos, que puede ser el propio Google desde la consola de administración. En Apple, la app privada aparece en el Apple Business de la empresa y se distribuye por gestión de dispositivos o por códigos de canje. Desde abril de 2026, Apple Business es gratuito y ya incluye gestión de dispositivos.

¿Una app interna también pasa por la revisión de Apple?#

Pasa. La app publicada en la tienda, la app no listada y la app privada para una organización son todas revisadas por Apple antes de llegar a alguien. Si la app tiene inicio de sesión, Apple pide una cuenta de demostración con el servidor encendido. La prueba externa de TestFlight también pasa por revisión en el primer build. Dentro de TestFlight, solo la prueba interna, limitada a 100 usuarios de la cuenta, queda afuera.

¿Se puede hacer pública después una app que nació privada?#

No directamente. En Apple, una vez aprobada la app, el método de distribución no cambia: para pasar de privada a pública, o al revés, hay que crear un registro de app nuevo y volver a enviarla. La única excepción es pasar una app pública a no listada. En Google Play, la app privada sigue privada, y hacerla pública exige publicar una app nueva, con otro nombre de paquete.

Fuentes#

Próximo paso#

Si tu empresa va a tener una app para el equipo o para clientes, la forma de distribución entra en el alcance desde el principio, junto con la cuenta y la revisión de las tiendas. Es el tipo de producto que construimos y publicamos en productos SaaS, como la app de campo de Beckers, que está en Google Play con acceso solo para quien la empresa habilita.

Compartir
Pedro Cunha
Quién escribe
Pedro Cunha
CTO de Epicora

Pedro Cunha lidera la ingeniería de Epicora, en Chapecó (Brasil). Escribe sobre las decisiones técnicas de los sistemas que el equipo pone en producción — arquitectura, alcance, estimación e IA aplicada.

Artículos de Pedro Cunha

Contacto

Conversemos sobre tu proyecto

Cuéntanos qué necesitas resolver. Respondemos rápido, con gente que entiende de tecnología y de negocio.

¿Prefieres hablar directamente?

Elige el canal que prefieras. Respondemos rápido, en horario comercial.

De la primera conversación al go-live: eficiencia, seguridad e innovación.