La respuesta corta
Para una app que solo usan tus empleados hay cinco vías en iOS, y la que te toca casi nunca es la que la gente asume. Por defecto es Custom Apps a través de Apple Business Manager: la app pasa App Review, no aparece en el App Store público y se distribuye a organizaciones concretas por MDM o por códigos de canje. El Apple Developer Enterprise Program —el que todo el mundo pide— exige 100 empleados o más y Apple lo reserva por escrito a los casos que las otras vías no cubren. En Android el equivalente es una app privada de managed Google Play, que se publica en unos diez minutos y no pasa por las mismas comprobaciones que una pública.
La decisión no es un trámite de última semana: cambia el proyecto. Elegirla mal significa descubrir en el mes de lanzamiento que el modelo de identidad, el de actualizaciones y hasta el de firma están construidos para el canal equivocado.
Las cinco vías, y cuál te toca
| Vía | Quién puede instalarla | Pasa App Review | Sirve para producción |
|---|---|---|---|
| App Store público | Cualquiera | Sí | Sí, pero tu app interna queda expuesta |
| Custom Apps (Apple Business Manager) | Organizaciones que tú autorizas | Sí | Sí — el caso por defecto |
| Unlisted | Cualquiera con el enlace directo | Sí | Sí, con autenticación propia |
| Enterprise Program | Solo empleados de tu organización | No | Sí, si cumples los requisitos |
| Ad Hoc / TestFlight | Dispositivos o testers registrados | TestFlight, revisión ligera | No |
1. Custom Apps: el camino por defecto
Una Custom App es una app que existe en el catálogo de Apple pero solo es visible para las organizaciones que tú indicas. La organización cliente te da su Organization ID —lo encuentra en Apple Business Manager, en Preferencias → Información de inscripción— y tú la marcas como privada en App Store Connect, en Pricing and Availability → App Distribution Methods → Private.
Desde ahí la organización la despliega de dos maneras: automáticamente por MDM sobre los dispositivos inscritos, o con códigos de canje que reparte a quien decida.
Dos cosas que conviene saber antes de empezar, porque las dos han costado semanas a más de un equipo:
App Review se aplica igual. Una Custom App se revisa como cualquier otra. Si la app requiere autenticación corporativa —y una app interna siempre la requiere— hay que entregar credenciales de prueba y datos de ejemplo al revisor. Sin eso, el rechazo es automático y se pierde el ciclo. Esto conecta con el problema general de los rechazos de App Review y su texto exacto: la mayoría no son discusiones de criterio, son requisitos operativos que nadie preparó.
La opción privada solo está disponible antes de que la app se apruebe. No es un interruptor que se pulse después. Si la app ya está aprobada como pública, cambiarla a privada no es una casilla: es rehacer el camino. Por eso la elección de canal es una decisión de arranque de proyecto y no de la semana de publicación.
2. Unlisted: cuando el público no es tu plantilla
Una app unlisted vive en el App Store pero no aparece en búsquedas, categorías, rankings ni recomendaciones. Solo se llega a ella por enlace directo, y también se puede servir desde Apple Business Manager o Apple School Manager.
Encaja cuando el destinatario no es exactamente tu plantilla: red de franquiciados, distribuidores, partners comerciales, asistentes a un congreso, estudiantes de un programa. Gente que no está en tu MDM y a la que no vas a inscribir dispositivos.
Cómo se pide: la app tiene que estar ya en el App Store o haberse enviado a App Review. Se añade una nota en Review Notes declarando la intención y se envía la solicitud de distribución unlisted. Apple rechaza la petición si la app no se ha enviado a revisión todavía o si está en estado beta o preproducción. Una vez aprobada, el ajuste se aplica a todas las versiones futuras.
La advertencia importante viene de la propia documentación de Apple: cualquiera con el enlace puede descargarla. Un enlace no es un control de acceso. La app tiene que implementar su propia barrera de identidad, porque el canal no la aporta.
3. Enterprise Program: el último recurso, y lo dice Apple
Es el programa que todo el mundo pide primero y el que Apple coloca explícitamente al final. Los requisitos, textuales:
- 100 empleados o más.
- Ser una entidad legal: no se aceptan nombres comerciales, marcas ni sucursales.
- Usar el programa solo para apps propietarias de uso interno, distribuidas de forma privada a empleados de la organización.
- Tener sistemas que garanticen que solo los empleados pueden descargarlas.
- Pasar la entrevista de verificación de Apple y su proceso de evaluación continua.
- D-U-N-S Number y web pública con dominio propio.
Cuesta 299 USD al año. Y Apple acota el uso con una frase que conviene leer entera: el programa es "solo para casos de uso específicos que no se resuelven adecuadamente con apps públicas en el App Store, custom apps a través de Apple Business o distribución Ad Hoc, ni con pruebas beta en TestFlight".
Traducido: si tu caso lo cubre una Custom App, pedir el Enterprise Program es pedir el camino que Apple vigila más y revoca más rápido. A cambio ganas una sola cosa —no pasar App Review— y aceptas dos riesgos: la evaluación continua y la dependencia de certificados que caducan y que, si se gestionan mal, dejan sin app a toda la plantilla el mismo día.
4. Ad Hoc y TestFlight no son distribución
Los dos aparecen en todas las conversaciones y ninguno es un canal de producción.
Ad Hoc exige registrar cada dispositivo por UDID, con un tope anual por tipo de dispositivo. Funciona para un piloto de veinte personas y se rompe el día que entra la segunda oficina.
TestFlight es beta testing: las compilaciones caducan, el tester recibe avisos de que está en una prueba y el canal no está pensado para que una herramienta de trabajo viva ahí indefinidamente. Que técnicamente aguante no lo convierte en el sitio correcto.
Usarlos como distribución permanente es la decisión que parece que ahorra tiempo en el mes uno y que en el mes nueve obliga a rehacer el despliegue con la app ya en manos de la gente.
5. Android: managed Google Play y las quince al día
En Android el equivalente es la app privada de managed Google Play: se publica y queda aprobada automáticamente para tu organización, sin visibilidad pública.
Dos formas de publicarla. Desde el iframe de managed Google Play integrado en la consola de tu EMM, donde basta el título y el fichero (AAB o APK) y la app suele estar lista para distribuir en unos diez minutos. O desde Play Console, restringiendo la segmentación a tu empresa. No todos los EMM soportan el iframe, así que esa es la primera comprobación.
Los límites que hay que conocer antes de diseñar el proceso de release:
- 15 apps privadas al día por organización.
- Las apps privadas no pasan las mismas comprobaciones que una pública. De ahí los diez minutos.
- No se pueden convertir en públicas más adelante.
- No son transferibles entre cuentas de desarrollador de Play.
Ese último punto es el que muerde en las fusiones y en los cambios de proveedor: si la app privada se publicó bajo la cuenta equivocada, no se mueve. Se vuelve a publicar y se vuelve a desplegar.
El error que cuesta un mes de calendario
El patrón se repite: el equipo construye la app asumiendo App Store público, y en la recta final alguien pregunta cómo la va a instalar la gente. A partir de ahí aparecen tres trabajos que nadie presupuestó.
Identidad. Una app pública asume registro; una interna asume que el usuario ya existe en el directorio corporativo. Cambiar de una a otra en el último mes toca el onboarding entero, no solo la pantalla de login.
Actualizaciones. Con MDM el despliegue lo controla el administrador y puede ser silencioso; con códigos de canje o enlace, actualiza quien quiere. La estrategia de versiones mínimas soportadas y de migraciones de datos depende de cuál de las dos sea, y es una decisión de arquitectura.
Titularidad de la cuenta. La cuenta de desarrollador debe ser del cliente, no de la agencia. Es la diferencia entre poder cambiar de proveedor y no poder. Lo tratamos aparte en quién debe custodiar los certificados de firma, porque es la misma familia de problema.
El caso típico de este tipo de producto: una herramienta de catálogos para un equipo comercial de mil personas, como la que construimos para Lactalis-Nestlé. Un producto así no tiene ningún público en el App Store — y sin embargo su canal de distribución se decide, con demasiada frecuencia, la penúltima semana.
Cuándo no usar cada una
- No uses Enterprise Program si tu caso lo resuelve una Custom App. Asumes evaluación continua y riesgo de revocación a cambio de saltarte una revisión que ibas a pasar igual.
- No uses Unlisted como si fuera un control de acceso. El enlace circula; la autenticación la pones tú.
- No uses TestFlight como canal permanente. Las compilaciones caducan y el usuario sabe que está en una beta.
- No uses Custom Apps si tu destinatario no tiene Apple Business Manager. Sin Organization ID no hay canal, y montar ABM en el cliente es un proyecto con sus propios plazos.
- No uses app privada de Play si algún día quieres abrirla al público. No se convierte.
Qué mirar antes de escribir la primera línea
Cuatro preguntas, y las cuatro son de la semana uno:
- ¿Quién instala la app: empleados en dispositivos gestionados, o gente fuera de tu MDM?
- ¿Existe Apple Business Manager en la organización cliente, y quién es su administrador?
- ¿A nombre de quién van las cuentas de desarrollador de Apple y de Google?
- ¿Quién decide cuándo se actualiza: el administrador o el usuario?
Responderlas antes condiciona el modelo de identidad, el de actualizaciones y el de firma. Responderlas después significa rehacerlos.
Si estás en ese punto —una app corporativa que hay que poner en manos de la plantilla y ninguna certeza sobre el canal— eso es exactamente lo que revisamos en la primera llamada de un proyecto de Flutter para empresas.
Fuentes primarias, consultadas el 14 de agosto de 2026: Apple Developer Enterprise Program, Custom Apps, Unlisted App Distribution y apps privadas en managed Google Play.
