Declarative Device Management (DDM)
Apple's modern device management framework for autonomous policy enforcement.
The device enforces settings on its own. No more waiting for MDM commands.
What is DDM?
Declarative Device Management (DDM) is Apple's next-generation approach to managing devices. Instead of the MDM server telling the device what to do step-by-step, DDM tells the device the desired state, and the device figures out how to get there on its own.
Think of the difference this way:
Traditional MDM (Command-Based)
The MDM server sends commands to the device. The device does exactly what it's told, then waits for the next command.
Like a recipe: "Step 1: Preheat oven. Step 2: Mix ingredients. Step 3: Bake for 30 minutes." The device follows each step when told.
DDM (Declarative)
The MDM tells the device "here's what should be true." The device continuously ensures those things stay true, even without further commands.
Like a thermostat: "Keep it 72 degrees." The device handles everything needed to maintain that state, automatically adjusting when conditions change.
Why DDM Matters
DDM vs Configuration Profiles
You might wonder: "How is DDM different from the configuration profiles we already use?" Here's the key distinction:
Configuration Profiles are installed on the device and enforced by macOS. They work great, but the MDM has to install them, and the MDM decides when to check on things.
DDM Declarations go a step further. The device itself becomes responsible for maintaining the declared state. It reports its status to the MDM proactively, and it reacts to changes immediately without waiting for an MDM command.
Practical Example
Let's say you want to require a 12-character password:
With Traditional Profiles:
- MDM pushes a profile with password requirements
- macOS enforces the requirement
- If you want to change to 14 characters, MDM removes old profile and pushes new one
- Device waits for MDM to initiate the change
With DDM:
- MDM sends a declaration: "Password must be 12 characters"
- Device acknowledges and enforces
- If you update declaration to 14 characters, device immediately knows and enforces new requirement
- Device proactively reports its compliance status to MDM
What MACE Generates
When you enable DDM in MACE's build options, it creates three types of files:
Configurations
JSON files that define the actual settings you want on devices. These are the "desired state" declarations.
Example: A configuration declaring that screen lock must activate after 5 minutes of inactivity.
Activations
JSON files that control when configurations apply. They can enable configurations based on conditions or device properties.
Example: An activation that enables security configurations only on devices in a specific group.
Assets
Supporting files that configurations reference including scripts, certificates, or other resources the device needs.
Example: A script asset that a configuration references to run a compliance check.
Inside a DDM Declaration
DDM declarations are JSON files with a specific structure. Here's what a configuration declaration looks like:
{
"Type": "com.apple.configuration.screensaver.settings",
"Identifier": "com.mace.screensaver.askpassword",
"ServerToken": "1.0.0",
"Payload": {
"askForPassword": true,
"askForPasswordDelay": 0,
"loginWindowIdleTime": 300
}
}
Type: The kind of configuration. Apple defines these types, similar to profile payload types.
Identifier: A unique ID for this declaration. Each declaration needs a unique identifier.
ServerToken: A version string. When you update this, the device knows the declaration changed.
Payload: The actual settings. This is where you define what you want configured.
How Activations Work
Activations are like switches that turn configurations on or off. Here's an example:
{
"Type": "com.apple.activation.simple",
"Identifier": "com.mace.activation.security",
"ServerToken": "1.0.0",
"Payload": {
"StandardConfigurations": [
"com.mace.screensaver.askpassword",
"com.mace.firewall.enable",
"com.mace.passcode.requirements"
]
}
}
This activation says: "Turn on these three configurations." The device receives the activation and immediately begins enforcing those configurations.
How Assets Work
Assets provide external resources that configurations can reference:
{
"Type": "com.apple.asset.data",
"Identifier": "com.mace.asset.compliance-script",
"ServerToken": "1.0.0",
"Payload": {
"DataURL": "https://your-server.com/compliance.sh",
"ContentType": "application/x-sh",
"Hash-SHA-256": "abc123..."
}
}
The device downloads the asset and makes it available for configurations to use.
Output Structure
After building with DDM enabled, you'll find this structure in your build folder:
declarative/
├── configurations/
│ ├── screensaver-settings.json
│ ├── passcode-requirements.json
│ ├── firewall-settings.json
│ └── ...
├── activations/
│ ├── security-activation.json
│ └── ...
└── assets/
├── compliance-script.json
└── ...
Each folder contains JSON files that show the exact settings and values for each declaration.
Deploying DDM
MDM GUI Configuration Required
Currently, no MDMs support directly importing DDM JSON declaration files. All MDMs require you to configure DDM settings through their own graphical interface.
The JSON files MACE generates serve as a reference showing you the exact configuration values needed. Use these files to understand what settings to configure, then enter those values manually in your MDM's DDM section.
What Happens on the Mac
When your MDM sends DDM declarations to a device:
During check-in, the MDM sends declarations to the device.
The device validates the declaration format and immediately applies the settings.
The device proactively reports its compliance status back to the MDM.
The device maintains the declared state autonomously, even when offline.
MDM Compatibility
DDM is supported by major MDM solutions. Each MDM has its own interface for configuring DDM settings:
Check Your MDM's Documentation: DDM is still evolving. Each MDM implements DDM differently and supports different declaration types. Always check your specific MDM's documentation for current capabilities.
DDM Requirements
DDM was introduced in macOS 13. Older Macs running macOS 12 or earlier cannot use DDM. Use configuration profiles instead.
Devices must be enrolled in an MDM that supports DDM. Unenrolled devices cannot receive declarations.
Certain DDM capabilities require the device to be supervised. User-enrolled devices may have limited DDM functionality.
Devices need network access to receive declarations. However, once received, enforcement continues offline.
When to Use DDM vs Profiles
DDM isn't a replacement for everything. It's another tool in your toolbox:
| ✅ | Use DDM when... | You need immediate enforcement, self-healing, or want to reduce MDM server load |
| ✅ | Use DDM when... | Your MDM and macOS version support the specific setting you need |
| 📋 | Use Profiles when... | You're managing older Macs (macOS 12 or earlier) |
| 📋 | Use Profiles when... | The setting you need isn't available as a DDM declaration |
| 📜 | Use Scripts when... | You need to check/audit settings that can't be managed by profiles or DDM |
Most deployments use a combination. DDM for what it supports, profiles for broader coverage, and scripts for auditing and edge cases. MACE can generate all three from the same rule set.
Best Practices
DDM behavior differs from profiles. Always test declarations on a small group before broad deployment.
Use meaningful ServerToken values. Increment them when you make changes so devices know to apply updates.
Check your MDM's reporting regularly. DDM provides detailed status about each declaration's state on each device.
Begin with a few declarations for well-understood settings. Expand as you gain confidence with DDM behavior.
Keep your profiles and scripts ready. If a DDM declaration doesn't work as expected, you can fall back to traditional methods.
Troubleshooting DDM
Common issues and solutions:
- Verify the device is running macOS 13 or later
- Check that the device is enrolled in your MDM
- Confirm the declaration type is supported by your MDM
- Look for errors in the MDM's declaration status report
- Check the JSON syntax is valid
- Verify the declaration Type is correct
- Ensure required Payload keys are present
- Check if the setting requires supervision
- This is expected DDM behavior. The device enforces the declared state
- If you need users to modify the setting, remove the declaration
- DDM declarations and profiles can conflict if they manage the same setting
- Remove conflicting profiles before deploying DDM for the same settings
- Choose one method per setting: DDM or profile, not both