Las aplicaciones móviles de empresa son apps creadas para uso interno y distribuidas a la plantilla fuera de App Store y Google Play. Partes de trabajo en campo, lectores de código en almacén, listas de verificación en planta, un acceso ligero al CRM para comercial: el público es conocido, los equipos son conocidos y la app depende de sistemas que solo existen en su organización.
La parte difícil rara vez es el desarrollo. Empieza después: cómo llega la app a los equipos, quién recibe qué versión y qué ocurre con ella cuando alguien deja la empresa.
En qué se diferencian de una app de consumo
Una app de consumo compite por millones de usuarios anónimos. La suya atiende a trescientos técnicos cuyos nombres están en su directorio corporativo. Eso condiciona todas las decisiones.
El público es conocido. Sabe qué modelos hay en circulación, qué versión de Android llevan y si en el almacén hay cobertura.
La distribución está controlada. En lugar de publicar en una tienda pública, la entrega pasa por una solución de gestión de aplicaciones o por un catálogo corporativo privado. Usted decide quién ve la app y qué versión está activa.
La app depende de sistemas existentes. ERP, CRM, portal de personal, gestor de incidencias. El inicio de sesión suele ir contra su proveedor de identidad: Microsoft Entra, Okta o Google Workspace. Ahí encallan la mayoría de los proyectos, no en el diseño de las pantallas.
Hay que demostrar qué ocurre con los datos. Tratar datos personales implica responsabilidad proactiva según el artículo 5 del RGPD: quién accedió, cuándo y cómo se eliminan después.
Nativo, multiplataforma, PWA o low-code
No hay un enfoque correcto, solo uno que encaja con su caso.
Desarrollo nativo
Apps separadas para iOS (Swift) y Android (Kotlin). Mejor rendimiento y acceso completo a cámara, Bluetooth, NFC y procesos en segundo plano. La opción sensata cuando la app debe funcionar sin conexión o hablar con hardware, como los terminales de lectura en logística. A cambio, mantiene dos bases de código.
Frameworks multiplataforma
React Native, Flutter y .NET MAUI cubren ambas plataformas desde un único código. Para formularios, listados, validaciones y mensajería, la diferencia con lo nativo ya no se percibe. Para la gran mayoría de apps internas es la opción por defecto razonable.
Progressive Web Apps
Una aplicación web con icono en la pantalla de inicio, caché sin conexión y notificaciones. No necesita tienda ni certificado de firma. Encaja bien en cuadros de mando, catálogos de consulta y flujos de aprobación. En cuanto necesita cámara de calidad, periféricos Bluetooth o procesos reales en segundo plano, se queda corta.
Plataformas low-code
Power Apps, AppSheet o Mendix permiten que un departamento cree por su cuenta formularios de captura sencillos. Funciona sorprendentemente bien para procesos acotados, y mal cuando dos años después alguien tiene que mantener eso. Trátelo como herramienta de prototipo y fije de antemano a partir de cuántos usuarios lo asume TI.
Cómo llega la app sin pasar por la tienda pública
Hay cuatro vías. La mayoría de las organizaciones combinan las dos primeras.
- Catálogo corporativo privado. Un catálogo propio, curado por TI, donde la plantilla instala por su cuenta las apps aprobadas. iOS, Android y aplicaciones web en una sola interfaz. Es la vía adecuada para todo lo que sea opcional.
- Instalación silenciosa vía MDM. La app se envía a los equipos inscritos sin intervención del usuario. En iOS debe estar publicada como app personalizada en Apple Business Manager; en Android, como app privada en Managed Google Play. Es la vía para lo obligatorio: VPN, agente de seguridad, comunicación interna.
- Instalación directa de APK o IPA. Se reparte el archivo y el usuario instala. No exige infraestructura, pero tampoco hay mecanismo de actualización ni datos de uso, y sí un riesgo real de compilaciones manipuladas. Aceptable para una prueba con cinco personas, no para un despliegue.
- Preconfiguración con Managed App Configuration. La URL del servidor, el identificador de cliente y los interruptores de funcionalidad los fija el MDM antes del primer arranque: el usuario abre la app y ya está conectada. Es AppConfig en iOS y configuración gestionada en Android. El punto que más se olvida, aunque evita casi todas las incidencias de la primera semana.
Donde más se nota la diferencia es con los trabajadores de primera línea. Un técnico de servicio, una enfermera de planta o una dependienta en sala no tienen veinte minutos para configurar nada: el equipo debe funcionar al empezar el turno. En tienda y en taller, la app suele ejecutarse en modo quiosco para que el dispositivo quede fijado a una sola aplicación durante la jornada.
Apps internas en dispositivos personales
No todo el mundo lleva un móvil de empresa. Cuando la app interna tiene que convivir con un equipo personal, la gestión cambia de naturaleza. El BYOD se aplica a iOS y Android; los PC con Windows y los Mac se gestionan como dispositivos de empresa.
En Android, las apps y los datos de trabajo residen en un perfil de trabajo, un espacio separado que impone el propio sistema operativo, con icono de maletín y pestaña propia. La consola solo lista las aplicaciones instaladas en ese perfil; lo que se instale en el lado personal no aparece. Cuando la persona se marcha, se elimina el perfil de trabajo, y es el propio Android el que limita el comando de borrado a ese espacio: restablecer de fábrica un equipo personal no es posible desde la consola.
En iOS, la inscripción instala un perfil de gestión que acota la administración a las aplicaciones y cuentas que distribuye la empresa. Las reglas de apertura gestionada mantienen los documentos corporativos dentro de esas apps. Al causar baja, se eliminan los datos gestionados.
Un punto que siempre sale en la negociación con la representación de la plantilla: en modo BYOD no existe localización del dispositivo, ni en Android ni en iOS. No es una opción desactivada, es una función ausente de ese modo. En dispositivos Android propiedad de la empresa sí existen la localización periódica y las zonas de geocerca con alerta, y eso hay que decirlo y acordarlo.
Para el equipo de desarrollo, la consecuencia es una: pruebe pronto dentro de un perfil de trabajo real. Las apps que abren el navegador del sistema, comparten archivos o traen su propio almacén de certificados se comportan de otra manera ahí.
Seguridad, RGPD y derechos digitales
La base técnica conviene montarla desde el principio, no como parche posterior.
- Autenticación contra el proveedor de identidad, con inicio de sesión único y doble factor
- Cifrado en reposo y en tránsito, con las interfaces de la plataforma en vez de una implementación propia
- VPN por aplicación, para que el tráfico de la app circule por su red incluso desde la wifi de un hotel
- Reglas contra la fuga de datos: portapapeles acotado entre apps gestionadas y personales, restricción del menú de compartir
- Borrado selectivo en la baja o en la pérdida del equipo, sin tocar el contenido personal
A esto se suman dos asuntos que en España deciden el proyecto y que las guías en inglés nunca mencionan.
El contrato de encargo de tratamiento. Todo proveedor que trate datos personales a través de su app necesita un contrato conforme al artículo 28 del RGPD. Vale para la solución MDM y para el SDK de analítica incrustado en la app. Un SDK de informes de fallos con servidores fuera de la UE es el hallazgo más habitual en la primera auditoría.
El artículo 87 de la LOPDGDD. La plantilla tiene derecho a la intimidad en el uso de los dispositivos digitales puestos a su disposición, y la empresa debe fijar por escrito los criterios de uso. Cuando esos equipos admiten uso privado, esos criterios se elaboran con participación de la representación de los trabajadores, precisando usos autorizados y garantías de privacidad. Sume el artículo 20.3 del Estatuto de los Trabajadores y tendrá el marco completo. Documentar qué datos recoge la app, para qué y cuánto tiempo se conservan cuesta dos semanas. Dejarlo para después del desarrollo cuesta el despliegue entero.
Ciclo de vida: versiones, pruebas y retirada
Una app firmada todavía no es una app en explotación.
Actualizaciones. Las correcciones de seguridad salen de inmediato; los cambios funcionales, por fases: primero un grupo piloto, luego departamento a departamento. Una solución MDM puede exigir una versión mínima y bloquear el acceso a los recursos corporativos mientras se ejecute una antigua. Es el único mecanismo que pone al día un parque de dispositivos heterogéneo.
Pruebas. En iOS, TestFlight cubre las pruebas internas y externas; en Android hacen lo mismo los canales de prueba de Google Play Console. Fuera de las tiendas públicas, su catálogo corporativo puede mantener un canal beta en paralelo al de producción. Pruebe en el modelo más antiguo que siga en servicio, no solo en el móvil del jefe de proyecto.
Supervisión y retirada. Mida tasa de fallos, tiempo de arranque y, sobre todo, inicios de sesión correctos: una app que tras rotar un certificado deja de autenticar a nadie está caída para el negocio aunque no registre ni un fallo. Y cuando llegue el final de su vida, quítela del catálogo, publique una última versión que apunte a la sucesora y desinstale la antigua desde el MDM.
Las apps internas son la vía por la que sus sistemas llegan a la furgoneta, al almacén y a la planta. La tecnología está madura. Lo exigente es el día después: mantenerlas actualizadas, distribuirlas con orden y recuperarlas en la baja. De eso se ocupa una solución de gestión de aplicaciones.
Preguntas frecuentes
¿Qué es una aplicación móvil de empresa?
Es una app desarrollada para el uso interno de una organización y no para su venta al público. Cubre un proceso de trabajo concreto, como partes de servicio, inventario o comunicación interna, y se distribuye de forma privada a la plantilla mediante Managed Google Play, Apple Business Manager o una solución MDM.
¿Cómo se distribuyen sin usar App Store ni Google Play?
Por tres canales: un catálogo corporativo privado para instalación por el propio usuario, el envío silencioso desde el MDM a los equipos inscritos, y la preconfiguración con Managed App Configuration para que funcione en el primer arranque. Las tiendas públicas quedan descartadas porque una app interna no está destinada al público general.
¿Nativo o multiplataforma para una app interna?
Lo nativo da el mejor rendimiento y acceso completo a las capacidades del equipo, algo que importa con cámara, biometría y procesos en segundo plano. Lo multiplataforma, con Flutter o React Native, recorta plazo y presupuesto cuando la misma app debe correr en iOS y en Android. Para la mayoría de aplicaciones internas es la elección pragmática, y lo nativo se reserva a los casos críticos.
¿Qué pasa si la app interna se instala en el móvil personal del empleado?
En Android se ejecuta dentro del perfil de trabajo, un espacio que separa el propio sistema; en iOS queda marcada como aplicación gestionada. En ambos casos la gestión alcanza solo al lado profesional y en la baja se retira únicamente esa parte. En modo BYOD no hay localización del dispositivo. Aun así, debe fijar por escrito los criterios de uso conforme al artículo 87 de la LOPDGDD y contar con la representación de los trabajadores.