What Is Declarative Device Management?

Declarative Device Management (or DDM) is a next-generation device management protocol and framework launched by Apple in 2021. DDM’s value is derived from two changes in particular. First, devices using Apple’s DDM can much more quickly enforce, update, and reapply configuration or security policies using a “proactive” (versus “reactive”) approach. Second, the various content and configurations applied to a given device can now be managed in many-to-many relationships across what Apple refers to as Declarations.

Declarative Device Management primarily serves mobile device management (MDM) providers and large enterprises. Using DDM, they can build new management features, implement more powerful and complex content and configuration management workflows, and greatly decrease unnecessary server-to-device communication on their infrastructure.

What Are the Features of Declarative Device Management?

Before really understanding the “why” of Declarative Device Management, it’s important to understand a bit of the “how.” Apple breaks down DDM into three “pillars” — Declarations, Status Channel, and Extensibility. Declarations are the most important pillar, as they define how settings and content are delivered to devices and logically organized.

Understanding Declaration Types

“Declarations” is Apple’s bundle term for the various settings, content, and logic applied to a managed device. Declarations are a modular, many-to-many framework for implementing device policy. Declarations are delivered to devices as JSON files, and in Apple’s DDM scheme, there are four types of declarations:

• Configurations (settings, accounts, restrictions)
• Assets (content)
• Activations (blueprints)
• Management (organizational information)

It is best to think of the types of declarations in terms of their relationship to a device. A given device may have one or more Activations applied to it. Those Activations are composed of one or more Configurations. Those Configurations may in turn be composed of one or more Assets. (The Management declaration just serves to advertise the managing organization’s information and the MDM’s capabilities, and so is not really relevant to understanding the declaration paradigm.)

How Declarations Work in Practice

Let’s consider an example of how a group of declarations might be applied to a given device. Imagine you have a managed iPad, and you need that iPad to:

• Log in with an org managed user account and password
• Lock to kiosk (single app) mode
• Set the system volume to zero
• Install an enterprise managed application
• Provide Wi-Fi AP credentials and VPN settings

One or more Configurations contain the Wi-Fi and VPN settings, the single app mode restriction, and system volume settings. One of those Configurations may also refer to an Asset that contains the user account name and password that the device will sign into. Another Configuration may refer to an Asset that delivers the enterprise managed application. You may apply multiple Activations to achieve this — one Activation could contain Configurations and Assets for baseline organization security policies (say, password policy, VPN settings, screen timeout, required 2FA app), while another Activation could be specific to the device role (if an iPad is a kiosk, set to single app mode, set volume to zero, and deliver a specific enterprise application). If multiple Activations applied to a given device have overlapping Configuration values (e.g., screen timeout 30 seconds, screen timeout 10 minutes), the Configurations will be merged, and the more strict value be applied (so, screen timeout 30 seconds).

Because of the many-to-many relationship model, Activations often refer to some of the same Configurations or Assets. For example, a device Activation applied to all BYOD devices in the corporate network would contain information about Wi-Fi credentials and minimum organization policies around settings like device password. In this example, those two settings (Wi-Fi credentials, minimum password length) refer to a Configuration. But another Activation applied to corporate-owned iPad kiosks could also refer to those Configurations. That means each Activation would be updated with the latest Wi-Fi credentials or password requirements by updating the individual Configuration (versus needing to update each Activation manually). This greatly reduces manual work.

Activations also can rely on something Apple calls “Predicates,” which are the conditions on the device that must be met for a given Activation to be applied. For example, you can define a required device family (e..g, iPad) or OS version (e.g., iOS 18) for an Activation to apply.

How Is Declarative Device Management Different From MDM?

The remaining two pillars of DDM (Status Channel, Extensibility) really define how Apple’s approach here differs from standard MDM “policy-push” architecture. 

The Status Channel allows devices using DDM to proactively communicate with the MDM server about any changes to their status — and even to apply relevant Activations (so, changes in device configuration) when a change in status results in the conditions of an Activation’s Predicate being met, without needing to first communicate with the MDM server. 

Extensibility lets both device and MDM server communicate when new capabilities may be available and take any applicable action (such as applying a new Activation), such as after a major OS update or a change in MDM settings.

Because of this proactive approach to keeping devices up to date and compliant — largely happening on the device side — organizations can maintain far more dynamic and responsive device fleets. Simply updating a single Configuration or Asset means that any Activation relying on those components will filter those changes down to all of the relevant devices. Or, that a large-scale fleet OS update will automatically trigger any changes in policy defined in Activations for that new software version.

In short, DDM is a highly responsive, intelligent, and flexible framework for device management, requiring much less server-to-device communication, manual intervention, and scripted enforcement than traditional MDM.

Desired State Management vs. Declarative Device Management

Declarative Device Management (DDM) is a major leap forward for iOS — no question. By shifting enforcement to the device itself, it reduces network traffic, improves offline resilience, and allows for modular, scalable configuration management. But for large-scale enterprise fleets — especially when devices are business-critical and purpose-built — DDM still falls short in one key area: control.

That’s where Esper’s Desired State Management (DSM) comes in.

While DDM is about defining what a device should look like and trusting it to comply, DSM takes it a step further. It monitors, validates, and corrects — in real time — from the cloud. It gives IT teams the ability to see exactly what’s happening across the fleet, respond to drift or failure instantly, and orchestrate complex deployments without relying on device behavior alone.

Think of DDM as smart instructions. DSM is a full command center.

A Real-World Comparison:

Let’s say you’re rolling out an app update to 2,000 Android kiosks and 500 iPads in the field.

• With DDM, your iPads will self-configure once the new declarations are pushed and the device checks in. But you won’t get instant visibility into install status, failures, or app crashes unless the device reports them during a status update cycle.
• With DSM, you can roll that update in stages, monitor install success in real time, automatically roll it back if errors spike, and ensure every device hits the exact target state — even if something goes wrong along the way.
  

Declarative is passive with smart automation. Desired is proactive, orchestrated, and visible.

Here's How They Compare Side-By-Side:

Why Not Both?

Here’s the best part: DDM and DSM aren’t mutually exclusive. In fact, they can complement each other beautifully. DDM gives iOS devices the intelligence to apply policies locally, while DSM ensures your entire fleet — Android or iOS — adheres to a single source of truth with the observability and control that enterprise teams need.

With Esper Blueprints and Pipelines, you can define your desired state once and let the platform handle the rest — detecting drift, correcting issues, and maintaining compliance without lifting a finger.

Declarative is smart. Desired is in control. To read more about our Desired State Management philosophy and how we think it’s a game-changer in MDM, read this post.