Most explanations of Apple’s Declarative Device Management (DDM) start with the same comparison, and it’s applicable regardless of the use case.
Apple’s legacy device management is command and response. The server sends an instruction, the device carries it out, and the server checks what happened. The server owns the logic. As a fleet grows, that model creates more traffic and more work because the server has to keep asking questions.
DDM moves more of that work from the server onto the device. The server publishes declarations that describe the state a device should maintain. The device stores those declarations, enforces them locally, and reports when its state changes. That means less polling, faster convergence, and enforcement that doesn’t depend on a live round trip to the server.
For software updates, an organization can now declare a target OS version and an enforcement deadline. The device downloads and prepares the update, tells the user what is coming, and increases the urgency of its notifications as the deadline approaches. If the user has not installed the update by then, then the device enforces it.
That description is accurate, but assumes somebody is using the device.
Esper’s customers’ devices are bolted to restaurant order counters, mounted in hotel rooms, suspended above kitchen lines, and strapped to warehouse carts. Nobody goes to Settings to check for an update. Nobody chooses a convenient time to install. If a notification appears at all, the person who sees it may be a customer completing their order. In that context, the notification intended to communicate becomes a defect.
Remove the person facing a screen from the DDM model and familiar terms start taking on different meanings.
The desired state isn’t just a compliance target. It is the known-good OS build against which the application was certified. The deadline isn’t the end of a courtesy period — it’s the mechanism that makes unattended enforcement possible. Notifications are something to minimize. And an update, however necessary, is also a production change. On the other side of a surprise OS update may be a restaurant that can’t take orders.
For an employee device, DDM reduces the amount of attention an update requires from IT and the user. For a dedicated device, it can remove the user from the update path altogether. That is the more consequential change.
The industry has mostly described DDM as an efficiency improvement: less polling, less network traffic, fewer admin hours. That framing makes sense for conventional fleets. A managed laptop usually had a fallback when automation failed: a person could respond to a prompt or open Settings.
An ordering kiosk, on the other hand, has no such fallback. It may run in single-app mode, sit behind a locked enclosure, and operate hundreds of miles from the nearest technician. In those environments, an update process that eventually asks for human attention is incomplete. DDM gives the operating system enough capability to keep moving without that intervention.
Three DDM properties for unattended devices
The first property is local enforcement. A declaration stored on the device remains active when the management server is unreachable. That’s useful for any fleet, but it maps especially well to the unreliable reality of a retail back room, a basement kiosk, or a tablet on a property network.
The second is device-driven status reporting. Instead of repeatedly interrogating the fleet, the server subscribes to relevant status and receives updates when values change. At a few hundred devices, polling may be tolerable. At several thousand devices across hundreds of sites, the difference appears in infrastructure load, API traffic, and the time it takes operators to see what’s actually happening.
The final property is persistence. It’s useful but it isn’t schedule-aware. If a device is powered off at the target time, the declaration stays active. Apple says the update is enforced one hour after the device restarts, or when conditions such as minimum battery level are met. A device that sat dark for three weeks won’t fall out of the campaign, but it could begin updating when a restaurant powers it on for the lunch rush. Apple provides an enforcement deadline, not a bounded installation window. We are working on the layer above that behavior, using device readiness, site operating hours, and rollout state to prevent a missed window from becoming a surprise update during service.
Apple also added a setting that makes the intended use case unusually clear. On iOS 18, iPadOS 18, and tvOS 18.4 or later, an organization can suppress the normal update-notification sequence. The device then shows only the notification one hour before enforcement and the restart countdown. Apple's deployment guide gives an example: devices that are not assigned directly to a user, such as kiosks.
Apple has accounted for devices with nobody standing in front of them. Much of the DDM conversation is still catching up.
Device autonomy without another application to manage
Declarative management is not new, and Apple did not invent the desired state. Linux administrators have used configuration-management systems such as CFEngine and Puppet for decades. Ansible applies a similar model without installing an agent on the managed node. Android Enterprise relies on an on-device policy controller. Windows declared configuration uses an operating system client stack that processes batches of settings asynchronously and maintains the requested state.
The important distinction is that Apple put the declaration engine in the operating system and connected it to the existing MDM relationship, but it’s not the first platform to combine autonomy with an agentless architecture. There’s no separate management application or third-party daemon to deploy, update, monitor, or exempt from the lockdown policy.
That architecture also defines the limit of every Apple MDM. Esper Deploy can use only the commands, declarations, status items, and payloads Apple exposes. If Apple has yet to implement a capability (such as a bounded installation window) an MDM vendor can’t simply add it to an on-device agent, because there is no agent to add it to. Any Apple MDM can build scheduling, orchestration, and safeguards around Apple’s primitives, but the device itself will only do what the operating system supports.
What it costs
Declarative management is asynchronous. The server knows that a declaration was accepted, but the requested state may take time to arrive. A device may be powered down overnight, waiting for Wi-Fi, below the required battery level, or short on storage. Operations teams that treat a synchronous success response as proof of completion need a different habit: watch the status channel and measure convergence.
The physical preconditions remain in place. Wall-powered kiosks are usually straightforward. A 32 GB tablet with almost no free storage is not. DDM can report why an update has stalled, but it can’t conjure up disk space or restore a network connection.
Local autonomy comes with another hard edge. Esper can change or remove a declaration, but the device must reconnect and synchronize before that change takes effect. Until then, an offline device continues to hold the target and deadline it last received. Once installation begins, it can’t be stopped, and an installed OS update cannot be rolled back. Rollout controls need to catch a bad target or deadline before the device acts on it.
How Esper is rolling out support for DDM
Posture comes before conversion. The update-settings surface ships first so an operator can define the fleet's intended behavior before any device begins enforcing it. Local autonomy is only useful after the desired state is clear.
Activation follows intent. We are not converting every eligible device in one pass. A device enters the declarative model when an operator takes an action that requires it, such as configuring update posture or sending an enforcement command. Fleets move over as their operators make decisions, at a pace they control.
Standing policy and update campaigns remain separate. In Esper, a Blueprint holds the configuration a device should maintain across iOS/iPadOS/tvOS, Android, Windows, and Linux. That is where update posture belongs. Moving a fleet to a particular OS version is a campaign, with rollout rings, monitoring, and the ability to stop. Treating a one-time production change as permanent configuration removes controls that operators need when something goes wrong.
The API came first because that is where the largest fleets already operate. Their device plane runs through pipelines and automation, not just a console. Esper's update commands have been available through the API since spring, months before iOS 27 shipped.
For dedicated fleets, the OS version no longer has to be determined by Apple's release calendar or by whether someone can physically reach the device. It becomes an operational decision, backed by a mechanism that can carry it out even when nobody is standing there.
