The server is not in charge anymore. Apple just made it official.

For fifteen years, mobile device management has worked roughly the same way. The server sends a command. The device receives it, acts on it, and reports back. The server polls again later to confirm. Repeat forever. It’s the IT equivalent of a manager who has to personally check in on every task rather than trusting the team to handle it.

It mostly worked. But “mostly” is doing a lot of work in that sentence. Anyone who’s managed a large Apple fleet knows the failure modes: OS update commands that fire into the void, APNs push notifications that land too late or not at all, compliance checks that reflect state from twenty minutes ago. The model is reactive by design. The server is always asking. The device is always answering. And if anything in that chain breaks — network, APNs, timing — you find out the hard way.

When Apple introduced Declarative Device Management at WWDC 2021, I thought it was the most important announcement in the session. Most of the industry treated it like a beta curiosity. Vendor roadmaps nodded at it. Blog posts called it “promising.” Implementation stalled. For four years, the MDM ecosystem kept shipping legacy profile payloads while DDM sat in the corner waiting to be taken seriously.

At WWDC 2025, Apple ran out of patience.

What actually changed with DDM

The conceptual shift is straightforward, even if the implementation isn’t. Traditional MDM is imperative — you tell the device what to do, step by step, right now. DDM is declarative — you describe the state you want, and the device figures out how to get there and stays there.

Three things make this materially different in practice:

Declarations, not commands. Instead of sending a “schedule OS update” command and waiting for an acknowledgment, you push a declaration that says “this device should be running 18.3.2 by April 1st.” The device owns the execution. It knows its battery level, its network conditions, whether the user is in a meeting. It picks a window. It installs. It reports done. No more 60-second countdown dialogs appearing at the worst possible moment because the server decided right now was fine.

A status channel, not polling. In legacy MDM, the server has to ask the device what’s going on. In DDM, the device tells the server proactively when something changes. This sounds like a small architectural detail. It isn’t. It means your compliance posture is current, not stale. It means you find out about a configuration drift when it happens, not at the next scheduled check-in. At scale, this is the difference between a monitoring system and a live dashboard.

Extensibility by design. The DDM schema is built to grow. New declaration types, new status items, new predicates — Apple can add capabilities without blowing up backward compatibility. Legacy MDM was bolted together over a decade; DDM was designed with the next decade in mind.

The infrastructure world solved this in 1993

Here’s the thing that should embarrass the MDM industry a little: the infrastructure world has been doing declarative state management since before most MDM admins started their careers.

In 1993, a physicist named Mark Burgess was drowning in shell scripts trying to manage a lab full of Unix workstations at the University of Oslo. His insight was simple and, in retrospect, obvious: stop writing scripts that describe how to change a system, and start writing policies that describe what the system should look like. Let the agent figure out the delta and close it. The result was CFEngine — arguably the first declarative configuration management tool, and the direct ancestor of every modern infrastructure automation platform in use today.

The principle Burgess called “convergence” is exactly what Apple is implementing with DDM. You define a desired end state. The agent evaluates current state against that definition. It closes the gap. It self-heals if something drifts. The server doesn’t micromanage the path — it declares the destination.

From CFEngine, the lineage runs directly through Puppet (2005), Chef (2009), and Ansible (2012) — each iterating on the same core idea with different tradeoffs around syntax, architecture, and agent model. By the time cloud infrastructure became the default, declarative management wasn’t a philosophy anymore. It was just how you operated at scale. Terraform, Kubernetes manifests, AWS CloudFormation — all of it is declarative. You write what you want. The platform figures out how to get there.

This is also the heart of Infrastructure as Code: the idea that your environment’s desired state should live in version-controlled, human-readable definitions rather than runbooks and tribal knowledge. You don’t script a sequence of changes — you declare a state, commit it to git, and let the tooling converge toward it repeatedly, reliably, across however many machines you’re managing. The script breaks when the environment is already halfway changed. The declaration just re-evaluates and corrects.

MDM, somehow, missed all of this. While infrastructure engineers were converging server fleets toward declared states with Puppet and Chef, the device management world was still sending commands and polling for acknowledgments — a model that would have felt familiar to an admin in 2005. The MDM protocol wasn’t designed for scale or resilience. It was designed to work, mostly, for a fleet that wasn’t too big and didn’t have too many failure modes.

DDM is Apple catching the device management world up to where infrastructure engineering has been for thirty years. The fact that it took a deprecation announcement to force adoption is, frankly, a little embarrassing in hindsight.

Why this matters beyond Apple

You could read DDM as an Apple-specific story. Don’t.

The underlying shift — from server-driven imperative control to client-side declarative state management — is the direction endpoint management is heading across the board. Google’s Android Management API has been moving this way for years. Windows has its own version of the tension between SCCM-style push-and-pray and modern cloud-native management. The question every platform is grappling with is the same: how much do you trust the device to manage itself?

Apple’s answer, increasingly, is: a lot. More than you might be comfortable with if you grew up in the era where the network perimeter was the security model and the MDM server was the source of truth. DDM assumes the device is a capable, trusted participant in its own management — not a passive recipient of instructions.

This has real implications for how endpoint management platforms are built. RMM tools that grew up on Windows — where the agent model gives you deep OS access and the server is genuinely in control — have to rethink what “management” means on an Apple device. You can’t just install a heavier agent. Apple’s framework is the API surface. You work within it, or you don’t work. And increasingly, working within it means thinking like an infrastructure engineer, not like an MDM vendor from 2010.

What vendors need to get right

The gap between “we support DDM” and “we’ve actually thought through DDM” is wide right now, and four years of soft adoption pressure didn’t close it. Here’s what the latter looks like:

Don’t expose the protocol to the admin. An IT admin managing 200 MacBooks for a client shouldn’t need to know what a declaration is. They should see a toggle that says “enforce OS updates” with a deadline picker. The DDM machinery should be invisible. Vendors who surface DDM vocabulary in their UI are just moving complexity from the protocol layer to the admin layer. That’s not simplification.

The status channel is the product. Real-time state reporting is DDM’s most underrated capability. An MDM that implements DDM just to handle software updates and ignores the status channel is leaving the best part on the table. Compliance dashboards that are actually current. Alerts that fire on state change rather than on schedule. This is where the admin experience gets genuinely better — not just more reliable under the hood.

Think GitOps. If DDM declarations are the Apple equivalent of Kubernetes manifests or Terraform configs — and they are — then the natural next step is treating them like infrastructure code. Version-controlled, peer-reviewed, deployed through a pipeline. Fleet is already headed this direction with GitOps-native MDM workflows. That’s the right instinct. The vendors who bring IaC discipline to device management policy will have something meaningfully different from the field.

Predicates deserve attention. DDM’s predicate system lets you apply declarations conditionally — only enforce this update if the device is on a certain OS version, or if the user is in a specific group. This is where management policy starts to look less like a blunt instrument and more like something intelligent. Most vendors haven’t gotten here yet. The ones that do will have a real differentiator.

The organizational reckoning

DDM also changes something for IT teams, not just vendors. If the device is maintaining its own declared state, the question shifts from “did we push the right command?” to “did we declare the right intent?” That’s a subtle reframe with real consequences.

An update command either worked or it didn’t. A declaration is continuously active. If the device drifts — user downgrades, setting changes, whatever — the declaration drives remediation automatically. That’s powerful. It’s also a prompt to think more carefully about what you’re declaring and why, because the device will keep trying to honor it regardless of context.

For MSPs especially, this matters. Managing dozens of client environments means management policy needs to be durable, not brittle. DDM’s resilience — declarations that survive network interruptions, that self-remediate, that report proactively — is exactly what an MSP needs from a fleet they can’t physically touch. The vendors who understood this in 2021 and built accordingly are well positioned. The ones treating the 2026 deprecation as their starting gun have a harder road ahead.

Where this goes

DDM is still maturing. Apple is adding declaration types incrementally — software updates, disk management, service configurations, Safari extensions. Full parity with legacy MDM capabilities isn’t there yet, and the coexistence period adds its own complexity for vendors supporting both. That’s been true since 2021 and it’s still true today. The difference is that Apple has now set a hard deadline on one side of the coexistence.

The endpoint management platforms that thrive in this environment will be the ones that stopped thinking about MDM as “sending commands to devices” and started thinking about it as “declaring and maintaining state” — the same shift the infrastructure world made a generation ago. The tools that get there will look less like traditional MDM consoles and more like what you’d expect from a platform built by people who grew up writing Puppet manifests and Terraform configs. Declared intent, convergent enforcement, GitOps-native policy management. The device management world is finally catching up to where infrastructure has been for thirty years.

Turns out the device was always going to be in charge. The infrastructure engineers knew it first.