# 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 s**tate-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.

Declaration TypePurposeTraditional MDM Equivalent**Configurations**Defines enforced settings (passcode rules, update behaviour, restrictions)Hexnode Policies**Assets**Supporting reference data (certificates, identity context)Certificates, user association, enrollment context**Activations**Determines when configurations become applicablePolicy assignment logic**Management**Server and organizational metadata required by AppleGlobal MDM context4. 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:

ConditionLikely CauseHexnode-Valid ActionDelayed status updatesPower or background execution limitsEnsure device has network access and sufficient powerMissing updatesOS or enrollment incompatibilityVerify device OS version and enrollment stateNo recent DDM activityNo state change occurredExpected behaviour in a stable device state7. 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**.