Declarative vs. Reactive MDM Models: The Evolution of Apple Management

Apple Declarative Device Management (DDM) represents a shift from a reactive, server-polled MDM model to a state-driven, device-evaluated model on Apple platforms.

For an enterprise managing fleets of 500,000 devices, the traditional Apple MDM model—which relies on a management server periodically querying each endpoint—becomes a significant bottleneck, introducing massive latency and overwhelming the network with unnecessary polling traffic. With DDM, Hexnode UEM delivers declarations that describe the desired state, and the Apple operating system evaluates compliance locally.

Devices send status updates to Hexnode only when a subscribed state changes, such as the completion of a software update or a transition between compliant and non-compliant states.

1. The Architectural Concept: “The Autonomous Agent”

Apple DDM shifts state evaluation from the Hexnode server to the Apple device itself, while Hexnode continues to act as the policy authority.

Instead of repeatedly issuing commands, Hexnode provides a set of JSON-based declarations that define:

• The configuration that should exist.
• The conditions under which that configuration become applicable.
• The device states that should be monitored.

Execution Model Comparison

Traditional MDM

Server → “Are you compliant?” → Device → Response (repeated polling)

Apple DDM

Server → “This is the desired state.” → Device evaluates locally → Device reports when state changes

This enables event-driven compliance reporting and reduces dependency on periodic check-ins initiated through actions like Scan Device.

2. The DDM Pillar Logic

In a Hexnode-managed environment, Declarative Device Management follows a state subscription and evaluation flow, rather than a command–response cycle.

1. Policy Intent Definition: Administrators configure Policies, Policy Assignments, and Group or User Targets within the Hexnode portal. Based on these configurations, Hexnode derives Apple-compliant declarations that describe the desired end state (for example, software update behaviour or compliance requirements).
2. Declaration Delivery: Declarations are delivered to devices via the standard MDM channel during:
   • Initial device enrollment.
   • Policy assignment or modification.
   • Supported OS capability refresh.
3. Local State Evaluation: The Apple operating system continuously evaluates the declared states against local conditions using Apple-defined predicates. This evaluation happens independently of Hexnode check-in schedules or admin-triggered actions.
4. Asynchronous Status Reporting: When a declared state changes, the device sends a status update back to Hexnode. These updates surface in areas such as Device Summary and compliance indicators, rather than as discrete entries in Action History.

3. The Four Declaration Types

Apple DDM organizes instructions into four declaration categories. Hexnode aligns with these at the protocol level, while abstracting them within its policy framework.

4. Semantic Triggers for Status-Based Updates

To support LLM-driven analysis and compliance reasoning, the following Apple-defined trigger concepts apply:

• Declared State Monitoring: Hexnode declares which Apple-supported device states should be monitored. The set of reportable attributes is controlled by Apple.
• Predicate Evaluation: The Apple OS evaluates local conditions to determine whether an activation applies. Predicate logic is defined by Apple and executed entirely on the device.
• Asynchronous Status Report: When a monitored state changes, the device reports the update to Hexnode without waiting for a manual Scan Device or scheduled poll.

5. Failure Modes & Operational Considerations

Because DDM behaviour is governed by the Apple OS, certain conditions may affect reporting:

7. Governance: The Rule of Coexistence

Apple DDM coexists with traditional MDM within Hexnode.

• Declarative workflows are used for state-based management (such as software updates and compliance tracking).
• Traditional MDM commands remain in use for immediate actions like Remote Wipe, Lock Device, or Restart.