Declarative Device Management explained for IT teams

What DDM is

Apple describes DDM as an update to the existing device management protocol. The administrator defines a target state, and the device applies it and maintains it on its own. Because the device also reports changes asynchronously, the management server no longer has to keep asking whether a setting took effect.

DDM is not a separate product or a replacement for MDM. It runs inside an MDM relationship, so a device still needs to be enrolled with a management service before it can receive declarations. If you are new to enrollment concepts, the glossary covers the basic terms.

From commands to declarations

Traditional MDM is imperative. The server sends a push notification through APNs, the device checks in, receives a command, executes it, and returns a result. To know the current state of a fleet, the server has to send queries and wait for answers. At scale, that means a lot of push traffic and a lot of devices to ask.

DDM flips the direction of work. The server publishes declarations, the device evaluates them locally, applies what is relevant, and tells the server about changes when they happen. A device that is offline when a declaration arrives can still apply it later and keeps enforcing what it already has.

• Command model: server initiates, device executes once, server polls for state.
• Declarative model: server states the desired outcome, device applies and maintains it, device reports status proactively.

The four declaration types

Apple defines four kinds of declarations that the server sends to the device:

• Configurations: the settings themselves, comparable to profile payloads. Accounts, restrictions, and passcode rules are examples.
• Assets: reference data that configurations need, such as credentials or other per-user or large items. One asset can be used by several configurations.
• Activations: groups of configurations and assets that apply together, all or nothing. An activation decides when its contents take effect.
• Management: information about the overall management state, including details about the organization and the capabilities of the management service. It can also carry custom properties that activations can use.

The modular design matters in practice. You can reuse one configuration in several activations, and you can update an asset, such as a credential, without resending the configurations that reference it.

Status reports and predicates

The status channel is how the device talks back. The device sends a status report on its own when a relevant item changes, and Apple documents a full report every 24 hours as well. The server can subscribe to the specific status items it cares about, so it receives only the data it will actually use.

Predicates connect status to behavior. An activation can include a condition that the device evaluates by itself, using its own status items and any custom properties the server provided. Apple's examples include checking the device type or comparing the operating system version. If the condition is true, the activation applies. If the state changes later, the device re-evaluates without waiting for the server.

How DDM coexists with traditional MDM

Declarative management is switched on by a special MDM command sent to an enrolled device, documented by Apple as DeclarativeManagement. On Mac and Shared iPad, which have a device channel and a user channel, the command is sent separately for each channel.

Your existing profiles and commands do not stop working. Apple describes two migration paths for profiles: embed an existing profile in a legacy profile declaration, or have the service take ownership of an installed profile and convert it to a legacy configuration declaration. Both avoid removing and reinstalling the profile.

When a profile and a declarative configuration set the same value, Apple says the operating system merges them and enforces the strictest result, and gives passcode policy as an example. For software updates and app configuration, declarative settings take precedence over the similar device management commands.

A concrete example: software update enforcement

Software updates are the clearest case of a workflow Apple moved to the declarative model. The Software Update configuration is supported on iOS 17, iPadOS 17, Shared iPad, and macOS 14 and later. It does not require supervision, and it works with both Device Enrollment and Automated Device Enrollment.

• You set a target OS version and a local date and time. The deadline is interpreted in each device's own time zone, so one configuration works across regions.
• Users get notifications that become more frequent as the deadline approaches. At the deadline, iOS and iPadOS ask for the passcode, and macOS closes open apps and restarts if needed.
• Status reports show progress, such as waiting, downloading, installing, or failed, along with a reason when an update is pending.
• A device that misses the deadline, for example because it was offline, keeps trying until the install succeeds.

Apple’s current guidance for managing software updates is built on declarative configuration. Check the current Software Update declarative configuration guide before you design update policy.

Practical considerations and planning adoption

DDM support is uneven across OS versions and across management services. Apple's own guidance tells admins to check their service's documentation for feature availability, and not every setting is exposed in every product. Treat DDM as something you adopt in stages, not a switch you flip.

1. Inventory your OS versions. Features such as software update enforcement start at iOS 17 and macOS 14, so older devices will need legacy profiles for the same job.
2. Confirm what your MDM service supports. Ask which declaration types, configurations, and status items it exposes today.
3. Start with a high-value, low-risk workflow, such as update enforcement, on a pilot group.
4. Migrate profiles gradually. Wrap existing profiles as legacy declarations where you can, and test the merge behavior before removing anything.
5. Decide what you will subscribe to. Choose status items that map to decisions your team actually makes, and define the response to each.
6. Keep fallbacks. Devices that cannot use a declaration still need the traditional profile or command path.

Sources

• Apple Deployment Guide: Intro to declarative device management
• Apple Deployment Guide: Use declarative device management to manage Apple devices
• Apple Deployment Guide: Software Update declarative configuration
• Apple Deployment Guide: Install and enforce software updates
• Apple Developer Documentation: DeclarativeManagementCommand

AAMDM is not affiliated with Apple Inc. Apple documentation changes over time; check the linked pages for the latest details.

Related articles