En todos los sistemas operativos numerados 27, Apple ha eliminado la gestión clásica de actualizaciones de software. No la ha marcado como obsoleta: la ha eliminado. Los comandos MDM, las consultas y las restricciones que su plataforma ha usado durante diez años para desplegar actualizaciones de iOS y macOS dejan de funcionar en iOS 27, iPadOS 27 y macOS 27. La gestión declarativa (DDM) es ahora la única vía para imponer una actualización en un dispositivo Apple actual.
Ese único cambio convierte el DDM en una fecha límite y no en un debate de arquitectura. Esta guía explica qué es la gestión declarativa, qué cambia de verdad para quien administra y para quien tiene el dispositivo en la mano, y qué movió la WWDC 2026.
Lo esencial en seis puntos
- El MDM clásico es imperativo: el servidor envía comandos y consulta el estado. El DDM es declarativo: el servidor envía el estado deseado, el dispositivo lo aplica y notifica los cambios por su cuenta.
- La gestión clásica de actualizaciones ya no funciona en ningún sistema 27.0. La actualización declarativa es el único camino.
- La declaración gana. Cuando una declaración y un comando MDM antiguo gestionan el mismo ajuste, prevalece la declaración.
- El trabajo se traslada al dispositivo. Las políticas siguen aplicándose sin conexión, surten efecto en segundos y se reparan sin resincronización.
- Se avisa al usuario, no se le tiende una emboscada. Los avisos pueden empezar 14 días antes del plazo, el aplazamiento va de 1 a 90 días, y la cuenta atrás forzada de 60 segundos ha desaparecido.
- Es aditivo, y su MDM debería ocultar la costura. Declarativo donde el dispositivo lo admite, imperativo donde no, desde una política que configura una sola vez.
Qué es realmente la gestión declarativa
El MDM clásico es una conversación. El servidor envía un comando, el dispositivo confirma, y luego el servidor pregunta si el estado se aplicó de verdad. Cada ajuste es un intercambio aparte. Multiplique eso por unos miles de dispositivos y su MDM se pasará el día persiguiendo estados en lugar de gestionar nada.
El DDM invierte la lógica. El servidor envía declaraciones: enunciados sobre el estado en el que debe estar el dispositivo. El dispositivo las almacena, las aplica él mismo, las mantiene tanto si alcanza el servidor como si no, y solo informa cuando algo cambia.
La diferencia es la que separa a un responsable que llama cada hora para saber si la tarea está hecha de uno que entrega el objetivo y confía en que le avisen si algo se atasca. Apple presentó el modelo en la WWDC 2021 con iOS 15 y ha ampliado su alcance cada año desde entonces. Con las versiones 27 ha empezado a cerrar la puerta antigua detrás de sí.
Los bloques del DDM
Una declaración no es un objeto monolítico. Apple la divide en tipos que se referencian entre sí, y eso es lo que hace el modelo combinable y no solo más rápido.
| Tipo | Qué contiene | Por qué importa |
|---|---|---|
| Configurations | Los ajustes reales: política de código, VPN, regla de actualización, app a instalar | Es la carga útil. Una configuration, reutilizable en varias activations |
| Activations | La lógica. Un conjunto de configurations más un predicado opcional que decide cuándo se aplican | La política condicional pasa al dispositivo. Se acabó reconstruir grupos dinámicos en el servidor |
| Assets | Datos reutilizables a los que apuntan las configurations: credenciales, certificados de identidad, perfiles alojados | Definido una vez, referenciado en todas partes. Renovar un certificado deja de ser un envío a todo el parque |
Por debajo de todo funciona el canal de estado. El dispositivo se suscribe a los valores que gestiona y envía un informe en el instante en que uno de ellos cambia. El servidor se entera de la desviación cuando ocurre, no en el siguiente contacto programado.
El predicado de activación es la parte que más se subestima. Como los predicados se evalúan en el dispositivo, contra informes de estado y propiedades de gestión personalizadas, puede entregar una política antes de que la condición sea cierta y dejar que el dispositivo la active más tarde por sí solo. Una configuration que solo se aplica a partir de una versión de sistema, o únicamente si el dispositivo se declara supervisado, no necesita lógica en el servidor.
Imperativo frente a declarativo, lado a lado
Supongamos que despliega diez apps gestionadas en un dispositivo.
| MDM imperativo | Declarativo | |
|---|---|---|
| Lo que envía el servidor | Diez comandos de instalación | Una declaración que lista las diez apps |
| Confirmación | Un acuse por comando, luego consultas | El dispositivo informa de su estado a medida que cambia |
| Un usuario borra la app número siete | Sigue ausente hasta que alguien lanza una resincronización | El dispositivo la reinstala por su cuenta |
| Sale una actualización de una app | Un comando nuevo, en cola por dispositivo | El dispositivo la actualiza, sin acción del servidor |
| Dispositivo suspendido o sin conexión | Los comandos esperan en la cola | La declaración se aplica y se mantiene en local |
| Detección de desviación | En el próximo contacto, quizá horas | Envío inmediato desde el dispositivo |
| Su panel | Un mar de «pendiente» | El estado actual |
Una aclaración, porque suele malinterpretarse: una declaración se sigue entregando a cada dispositivo de forma individual. La ganancia no es un mensaje para todo el parque. La ganancia es que una sola declaración sustituye un flujo de comandos y un bucle de consultas, por dispositivo, durante toda la vida de esa política.
Qué cambia para quien administra
Actualizaciones que llegan de verdad
Las actualizaciones de macOS en modo imperativo eran famosas por su poca fiabilidad. Comandos que se quedaban colgados en silencio, dispositivos que ignoraban el plazo, usuarios que aplazaban sin fin y un informe de cumplimiento que se creía a medias. La actualización declarativa entrega al Mac una versión objetivo y una fecha de aplicación, y es el Mac el que conduce. Descarga en segundo plano, se organiza alrededor del usuario e informa de su progreso por el canal de estado.
La diferencia práctica se ve en los informes. Se deja de preguntar si el comando pasó y se empieza a leer un estado que el dispositivo afirma sobre sí mismo.
Cumplimiento demostrable en presente
La consulta periódica lleva una mentira dentro. Entre dos consultas no sabe qué hace un dispositivo. Alguien desactiva un ajuste, sale de la red, incumple la política, y usted lo descubre en la siguiente consulta, que puede estar a cuatro horas.
El canal de estado cierra esa ventana. Para una auditoría, pasar de «lo comprobamos esta mañana» a «lo sabemos ahora» vale más que la ganancia de velocidad. Y es la respuesta a lo que los auditores preguntan de verdad, que no es si existe una política sino si puede demostrar que se aplicó de forma continua. Para el Esquema Nacional de Seguridad y para NIS2, ese matiz es justo el que se evalúa.
Menos objetos que mantener
Como los assets se referencian y no se incrustan, y las configurations se reutilizan en varias activations, el número de objetos deja de crecer al mismo ritmo que su matriz de políticas. Renovar un certificado de identidad pasa a ser una actualización de asset en lugar de un reenvío de todos los perfiles que lo contenían. Retirar una política pasa a ser eliminar una activation.
Despliegue de apps que se repara solo
Las declaraciones de gestión de aplicaciones cambiaron el modo de fallo. Con MDM imperativo, una app cuya instalación fallaba, que un usuario borraba o que se quedaba a medias en una actualización seguía rota hasta que alguien se daba cuenta y lanzaba una resincronización. Una app gestionada en declarativo lleva consigo su estado previsto. Si falta, el dispositivo la reinstala. Si está desactualizada y la actualización automática está impuesta, el dispositivo la actualiza. Sin ticket, sin resincronización, sin nadie de IT en el bucle.
Los controles que la acompañan son los que los administradores piden por su nombre: forzar la actualización automática al margen del ajuste de App Store del usuario, restringir las descargas a Wi-Fi para que un equipo de campo no se gaste su plan de datos en una actualización de 400 MB, y bloquear u ocultar una app gestionada para que no se pueda quitar.
Menos servidor, menos diagnóstico
La carga del servidor baja, lo que suena a nota al pie de infraestructura hasta que pasa de unos miles de dispositivos y su MDM empieza a resentirse de sus propias consultas. Y cuando algo se rompe, un informe de estado espontáneo le dice qué cambió y cuándo, sin que tenga que construir una consulta para ir a buscarlo.
Qué cambia para quien tiene el dispositivo en la mano
Del DDM se habla casi siempre desde la consola. Pero las personas que llevan estos dispositivos también notan el cambio, y lo que ellas viven es lo que decide si su despliegue se recuerda como una mejora o como una molestia.
Las actualizaciones dejan de emboscar
El desenlace antiguo era una cuenta atrás de 60 segundos y un reinicio, muchas veces en medio de algo importante. La actualización declarativa sustituye la emboscada por una pista de aterrizaje. Los avisos pueden empezar hasta 14 días antes del plazo, y usted controla su frecuencia y su redacción. Las ventanas de aplazamiento van de 1 a 90 días, y puede fijar plazos distintos para una actualización menor y para un salto de versión mayor.
El buen resultado es el aburrido: el Mac descarga e instala en una franja en la que nadie lo usa, y el usuario no ve ninguna cuenta atrás. Su equipo simplemente está al día. Y cuando el plazo llega de verdad, llega como el último paso de una conversación en la que el usuario participa desde hace dos semanas, no como una sorpresa.
Apps que se reparan sin ruido
Visto desde el usuario, el despliegue autorreparable significa que la app que necesita está ahí, en la versión prevista, sin abrir un ticket para explicar que ha desaparecido. El control de solo Wi-Fi también cuenta aquí. Nadie quiere gastar sus datos personales en la actualización de una app gestionada en un aeropuerto.
Menos dudas sobre lo que IT puede ver
Este punto es sutil y conviene decirlo en voz alta a sus usuarios. Las declaraciones describen una intención y están limitadas por lo que autoriza la declaración de gestión. En un dispositivo personal, la frontera entre gestionado y privado la fija el tipo de inscripción, no la insistencia con la que consulta el servidor. Saber explicar esa frontera con claridad es media batalla en un programa BYOD, y también el punto que más se mira desde el RGPD aplicado a la gestión de dispositivos móviles.
Actualizaciones de software: el caso que se cierra solo
Es el ámbito de mayor rendimiento, el único cuya vía imperativa Apple ha cerrado, y el más fácil de demostrar.
Una configuration de actualización declarativa toma una versión objetivo y una fecha de aplicación. A partir de ahí, la secuencia es del dispositivo: comprobar disponibilidad, descargar en segundo plano, avisar al usuario según el calendario que haya fijado, instalar y reiniciar. El progreso y los estados de error vuelven por el canal de estado, de modo que un dispositivo atascado es visible como un estado y no como una ausencia de confirmación.
Nuestra guía sobre la gestión de dispositivos Apple cubre la inscripción y las políticas de base.
Qué hay de nuevo en iOS 27, iPadOS 27 y macOS 27
La WWDC 2026 fue la edición en la que Apple dejó de añadir cosas al DDM y empezó a mover cosas dentro. Anunciadas el 8 de junio de 2026 y publicadas en septiembre de 2026, las versiones 27 traen el mayor traslado de capacidades fuera de los perfiles clásicos hasta la fecha.
La red se ha mudado. Seis configurations nuevas sustituyen los antiguos payloads de red: network.vpn-plugin, network.ikev2, network.ipsec, network.always-on, network.dns-proxy, network.dns-settings y network.relay. Si mantiene perfiles VPN a mano, este es el año en que ese trabajo cambia de forma.
El filtrado de contenido web se ha mudado a webcontent-filter.plugin. La caché de contenido en Mac supervisados pasa a content-cache.settings, en sustitución del antiguo perfil com.apple.AssetCache.managed.
Siri, Apple Intelligence y los ajustes de teclado salen del payload de restricciones hacia siri.settings, intelligence.settings, external-intelligence.settings y keyboard.settings. Las claves de restricción correspondientes quedaron obsoletas ya en las versiones 26.4, así que la ventana de migración lleva un tiempo abierta.
Los perfiles clásicos ya se pueden entregar como assets. Una clave ProfileAssetReference permite apuntar una declaración de perfil clásico o interactivo a un perfil alojado, lo que convierte «nos quedan cuarenta perfiles sin convertir» en una etapa de transición y no en un bloqueo.
Han llegado nuevos elementos de estado: mdm.enrollment-type, mdm.is-awaiting-configuration, mdm.is-return-to-service, device.system.health y security.lockdown-mode. Son combustible para predicados. Poder condicionar una configuration al tipo de inscripción o al modo de aislamiento, evaluado en el dispositivo, elimina toda una categoría de lógica de grupos en el servidor.
Y el titular otra vez, porque es el que lleva fecha: la gestión clásica de actualizaciones de software ya no funciona en ningún sistema operativo 27.0, incluidos los comandos, consultas y restricciones asociados.
Qué no cambia el DDM
La inscripción. Los dispositivos siguen entrando por la inscripción automatizada y Apple Business Manager, y el DDM funciona sobre esos cimientos. Si su configuración de ABM está desordenada, la gestión declarativa no la va a ordenar.
Su MDM sigue siendo además lo que entrega las declaraciones, así que no es una herramienta que abandone. Lo que cambia es cómo habla su herramienta actual con los dispositivos. Y el DDM convive con el MDM imperativo en lugar de sustituirlo de un día para otro. Si las siglas de alrededor se difuminan, nuestra guía sobre qué es una solución MDM ordena la relación entre MDM, EMM y UEM.
Lo que Appaloosa gestiona por usted
El orden de migración, el choque entre una declaración y un perfil antiguo, la cuestión de qué dispositivo puede hacer qué: de eso se encarga Appaloosa de forma transparente. Las políticas que ya ha configurado se entregan en declarativo en los dispositivos compatibles, y los dispositivos con versiones más antiguas siguen recibiendo el equivalente imperativo. Usted no elige un modelo dispositivo a dispositivo ni mantiene dos conjuntos de políticas.
Dos decisiones siguen siendo suyas, porque son operativas y no técnicas. Apunte a una versión concreta del sistema en lugar de «la última», para que su parque aterrice en una compilación conocida y el soporte diagnostique una configuración en vez de seis. Y escalone las fechas de aplicación por grupo, para que un grupo piloto llegue al plazo dos semanas antes que el resto y encuentre la app interna que se rompe antes de que la encuentren 3.000 personas por usted.
Preguntas frecuentes
¿Hay que volver a inscribir los dispositivos para usar DDM?
No. El DDM funciona sobre la inscripción MDM existente. Si un dispositivo está inscrito y en un sistema compatible, puede recibir declaraciones.
¿Qué versiones de sistema necesito?
La base para las declaraciones es iOS 17, iPadOS 17 y macOS 14. La cobertura se amplía con cada versión posterior, y en las versiones 27 varios ámbitos pasan a ser exclusivamente declarativos.
¿El DDM es solo para dispositivos corporativos supervisados?
No, aunque el alcance cambia. Los dispositivos corporativos supervisados tienen la cobertura más amplia, incluida la instalación de apps. Los dispositivos personales en inscripción de usuario reciben un conjunto más estrecho, limitado a propósito.
Hacia dónde va esto
Apple ha dejado de insinuar. Las capacidades de gestión nuevas llegan ya en declarativo primero, las existentes se trasladan versión a versión, y con los sistemas 27 la vía imperativa ha empezado a desaparecer en lugar de simplemente pasar de moda. Si gestiona dispositivos Apple a una escala real, la pregunta ya no es si adoptar el DDM. Es si la plataforma que ya paga lo ha hecho.
Appaloosa admite la gestión declarativa de dispositivos. El canal de estado está operativo, así que los dispositivos notifican sus cambios de estado en tiempo real en lugar de esperar a ser consultados, y las configurations declarativas cubren actualización de software, apps gestionadas, Siri y ajustes de teclado. La cobertura crece declaración a declaración y no en bloque, que es la forma honesta de describir dónde está hoy cualquier plataforma. Appaloosa gestiona iPhone y iPad y Mac a través de Apple Business Manager y la inscripción automatizada, de modo que los cimientos de inscripción de los que depende el DDM ya están puestos.