DDM is a device protocol. GitOps is a workflow. The difference matters.

Most organizations don’t want to engineer how devices reach desired state. They want a platform that takes them there reliably, without the workflow becoming the job.

There has been an uptick in discussion recently about Apple’s Declarative Device Management, also known as DDM. Some of it has been helpful. Some of it has been overly academic. And some of it reflects a worldview that does not match how most organizations actually manage devices in practice.

DDM is a major step forward for the ecosystem. It is not a religion or a lifestyle. It is a protocol evolution. Protocol evolutions do not dictate how people prefer to work.

The value of DDM comes from the device model, not the workflow

DDM is powerful because of what it enables on the device.

Devices can evaluate their own state, reconcile asynchronously, reduce dependence on server sequencing, and report richer, more accurate results.

This is the advancement that improves reliability, reduces friction, and creates more predictable outcomes.

None of this requires Git or YAML. None of this requires an admin to understand declarations or protocol layers.

The protocol is where the change occurs. The workflow is how the admin expresses intent. These are separate concerns and they should stay separate.

A platform that forces admins to think about the protocol has shifted complexity to the wrong place.

DDM is not the same thing as GitOps or "config as code"

A recent narrative suggests that “real” declarative management means storing configurations in Git, pushing changes through pipelines, and treating an MDM solution as little more than a proxy for a repository.

That workflow works well for teams with dedicated DevOps or client platform engineering (CPE) resources who choose to operate that way. Most IT organizations do not.

The typical IT admin wears many hats. They manage endpoints alongside many other responsibilities. They do not want to maintain configuration files or build automation pipelines just to enforce device state. Their job is to define intent and ensure the fleet stays compliant, secure, and functioning.

Treating GitOps as the definitive expression of DDM ignores reality. DDM is a device protocol, not a workflow requirement. Git is an option, not the definition. Confusing the two limits the conversation instead of expanding it.

A UI does not make DDM "less declarative"

Some commentary frames declarative management through a UI as inferior, as if the only legitimate experience is raw code in a repo. This misidentifies the layers involved.

DDM defines how devices receive intent, evaluate state, reconcile toward the intended outcome, and report their understanding.

A UI defines how humans express that intent, collaborate, and make decisions.

Conflating the two is like insisting that the only real way to use Kubernetes is to write raw YAML by hand. Some people enjoy that workflow. Most do not.

Modern systems rely on abstraction. The presence of a UI does not change what happens on the device; it only affects how accessible the platform is for the admin.

If the admin has to think about the protocol, the platform failed

Administrators should care about outcomes, not protocol mechanics. Protocols are plumbing. Plumbing should disappear behind the walls.

TLS protects the web because nobody has to hand-select cipher suites every time they visit a URL. DNS works because nobody thinks about record lookups unless they break. We do not write assembly anymore because abstraction is progress.

DDM should be the same. The protocol should disappear behind the outcome.

If a platform forces administrators to understand the protocol just to get reliable results, it is solving the wrong problem. That’s nostalgia for a world where tools forced people to feel smart by doing unnecessary work.

The platform should absorb complexity, not expose it

Some parts of the industry expose complexity to administrators on purpose. Raw files, manual pipelines, and workflow purity can create the impression of sophistication. But sophistication is not the goal. Reliability is the goal.

Most organizations want the opposite. They want guardrails, templates, best practice defaults, automation that works without handholding, and a system that interprets intent instead of turning admins into compilers.

Abstraction is not the enemy and it is not a shortcut. Abstraction is the foundation of well-designed device management.

If abstraction is "fake", then by that logic, writing assembly code is the only "real" programming. Modern computing exists because we stopped doing that. Device management is no different.

How we think about DDM at Iru

The admin defines the intended outcome. The platform chooses the right mechanism to achieve it. The device maintains that state continuously.

We do not ask admins to choose between MDM and DDM. We do not require them to understand protocol differences. We do not require them to rebuild their workflows around declarations.

DDM strengthens our desired-state approach because it aligns with principles we have believed in from our inception: continuous verification, reliable convergence, and reducing the burden on administrators.

The real measure of a system is not whether it uses DDM or MDM. It is whether devices consistently reach the intended state and stay there.

The future of device management is practical and outcome-focused

The industry is healthiest when discussions expand instead of contract.

The future is not Git only, or UI only, or declarative only, or imperative only, or vendor-driven, or customer-built. The future is hybrid. It is practical. It is aligned to outcomes, delivered with the least friction.

The platforms that succeed will be the ones that get customers to their desired state on every device, without requiring them to hire specialized engineers or rebuild their process around a specific protocol or workflow. For most organizations, that level of complexity is simply not an option.

DDM is important. It is not everything. It is one tool in a larger architectural toolbox focused on reliable results.

The vendors who focus on outcomes instead of workflow ideology will define the next decade of device management.