This is Part 1 of a three-part series on the architectural shift to Declarative Device Management. This article intentionally stays inside the legacy macOS MDM model. The goal is to establish the mechanical baseline: APNs wake-ups, mdmclient, command polling, status acknowledgements, and the server-side compliance tax that traditional MDM creates at fleet scale.

The Asynchronous Core: APNs Is a Wake-Up, Not a Payload Bus

Traditional macOS Mobile Device Management does not behave like a permanently connected remote-control channel. The MDM server does not usually open a direct management session to the Mac and push a complete command payload over that connection. Instead, the server uses the Apple Push Notification service, or APNs, as a secure wake-up mechanism.

That distinction matters.

An APNs notification is not the configuration profile. It is not the inventory command. It is not a remediation script. It is not the FileVault policy. It is a signal that tells the managed device, “Contact your MDM server. There may be work waiting.”

For a Windows administrator, it is tempting to compare this to SCCM/MECM client notification or a Group Policy refresh trigger, but the macOS MDM model is more constrained. APNs wakes the device. The device then initiates its own connection back to the MDM server. The management payload is retrieved only after the client-side MDM component checks in.

On macOS, the local operating system component responsible for this behavior is mdmclient.

# macOS
# Return information that would normally be returned to the MDM.
sudo /usr/libexec/mdmclient QueryDeviceInformation

There is no exact PowerShell equivalent because this is not a Jamf binary or a third-party agent. It is part of the operating system’s MDM framework. A loose Windows comparison would be forcing a Group Policy update or triggering an MECM policy retrieval cycle, but the implementation model is different. Because mdmclient is used internally for communication with Mobile Device Management (MDM) servers, arguments and outputs change without notice.

# Windows comparison only.
# These are not macOS equivalents.

# Force Group Policy refresh:
gpupdate /force

# Trigger MECM machine policy retrieval:
Invoke-WmiMethod -Namespace 'root\ccm' -Class 'SMS_Client' -Name 'RequestMachinePolicy'

The important point is that APNs does not remove the need for client polling. It only helps trigger the polling cycle sooner.

The Legacy Communication Loop

In traditional MDM, the managed device owns the outbound connection. After receiving an APNs wake-up, or after reaching its normal check-in behavior, the Mac contacts the MDM server and asks for work.

For clarity, this article uses the shorthand GET /mdm/commands and PUT /mdm/status to describe the logical flow. Actual MDM server URLs and HTTP implementation details vary by product, but the mechanical pattern is the same:

1. The server signals the device through APNs.
2. mdmclient wakes and initiates communication with the MDM server.
3. The device asks whether a command is pending.
4. The server returns one command or an empty response.
5. The device executes or evaluates that command.
6. The device reports status back to the server.
7. The server updates its command queue and compliance state.
8. The cycle repeats as needed.

A simplified command response might look like this. The OS version in the example is illustrative, not a version requirement.

<!-- Simplified MDM server command response -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>CommandUUID</key>
  <string>A1B2C3D4-E5F6-7890-ABCD-EF1234567890</string>
  <key>Command</key>
  <dict>
    <key>RequestType</key>
    <string>DeviceInformation</string>
    <key>Queries</key>
    <array>
      <string>OSVersion</string>
      <string>Model</string>
      <string>SerialNumber</string>
    </array>
  </dict>
</dict>
</plist>

The device then reports the result:

<!-- Simplified device status response -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>CommandUUID</key>
  <string>A1B2C3D4-E5F6-7890-ABCD-EF1234567890</string>
  <key>Status</key>
  <string>Acknowledged</string>
  <key>QueryResponses</key>
  <dict>
    <key>OSVersion</key>
    <string>15.5</string>
    <key>Model</key>
    <string>MacBookPro18,1</string>
    <key>SerialNumber</key>
    <string>C02EXAMPLE123</string>
  </dict>
</dict>
</plist>

This is the foundation of legacy MDM: the server asks, the device answers, and the server decides what to do next.

Command Queues and One-Step-at-a-Time Management

A traditional MDM server maintains a command queue for each managed device. That queue might contain inventory requests, profile installation commands, security queries, application management commands, or other device-management actions.

The device does not receive an entire operational plan in one autonomous bundle. It checks in, receives work, processes it, and reports back. The server then decides whether another command is needed.

This is why command acknowledgement matters. The server generally cannot safely assume that a command succeeded just because it was queued. It must wait for the device to report Acknowledged, Error, CommandFormatError, NotNow, or another status result. Only after receiving that response can the server confidently advance its internal state.

Depending on the command and vendor implementation, a device may receive one command, complete it, report status, and then check again for additional work. The important architectural point is not the literal number of commands per request; it is that the server remains responsible for deciding what the next action should be after each reported result.

That creates a narrow loop:

Server queues command
        ↓
APNs wakes device
        ↓
Device checks in
        ↓
Server returns command
        ↓
Device processes command
        ↓
Device reports status
        ↓
Server recalculates next action

At small scale, this is manageable. At fleet scale, this loop becomes expensive because the server is responsible for interpreting every response and deciding what the next command should be.

The Server Owns the Delta Calculation

The most important limitation of legacy MDM is not merely that devices check in. The deeper issue is that the MDM server owns the delta calculation.

In this context, “delta” means the difference between the device’s reported state and the administrator’s desired state. The server must determine what changed, whether that change matters, whether the device is compliant, and what corrective command should be issued next.

For every meaningful check-in, the server may need to answer questions like these:

• Is this device still in the same static or smart group?
• Is the assigned user still the same?
• Did the operating system version change?
• Did the device fall into or out of a compliance scope?
• Are required configuration profiles installed?
• Are restricted profiles missing?
• Has FileVault escrow completed?
• Is the device eligible for an application deployment?
• Is an inventory update required before policy can be evaluated?
• Should a command be retried, skipped, or marked failed?

A traditional MDM server therefore spends a large amount of time comparing “what the device says it is” against “what the server believes the device should be.”

That comparison is not free.

Why Every Check-In Becomes Expensive

A single device check-in can trigger multiple server-side operations:

1. Validate the device identity and enrollment state.
2. Read the device record from the database.
3. Evaluate group membership.
4. Evaluate configuration profile scope.
5. Evaluate application deployment scope.
6. Evaluate inventory freshness.
7. Evaluate compliance state.
8. Inspect the pending command queue.
9. Determine whether another command should be sent.
10. Store the resulting status and update dashboards or reports.

This is the computational tax of legacy MDM.

The device might be perfectly compliant. Nothing may have changed. The user may not have touched the Mac. The inventory record may be identical to the previous check-in. But the server still has to prove that nothing meaningful changed.

At fleet scale, “nothing changed” is still expensive when the server has to verify it tens of thousands of times.

Compliance Latency Is Often a Server-Side Artifact

Legacy MDM can also make compliance appear slower than the device’s actual capabilities.

For example, a Mac might be able to apply a required FileVault-related configuration quickly. But the compliance workflow may still require several server-mediated steps:

Server requests security state
        ↓
Device reports current state
        ↓
Server evaluates compliance
        ↓
Server queues corrective command
        ↓
Device checks in again
        ↓
Device processes command
        ↓
Device reports result
        ↓
Server recalculates compliance

The device may have completed its local work in seconds, but the management system may not reflect that state until the command cycle, acknowledgement cycle, inventory cycle, and compliance evaluation cycle have all completed.

This is why administrators often see a gap between “the Mac already did the thing” and “the MDM console now shows the Mac as compliant.”

The bottleneck is not always the endpoint. Often, it is the architecture of the reporting and reconciliation loop.

Why Scaling Legacy MDM Is Hard

Traditional MDM scales by making the server more capable: more application nodes, more database capacity, more queue workers, more background processing, more careful scheduling, and more tuning.

Those improvements matter, but they do not change the core model.

The server remains responsible for:

• tracking desired state,
• collecting reported state,
• calculating drift,
• deciding remediation,
• queuing commands,
• interpreting acknowledgements,
• and updating compliance records.

The endpoint remains mostly reactive. It waits for commands, executes them, and reports results.

For small fleets, this is acceptable. For large fleets, the repeated server-side reconciliation becomes the limiting factor. Every device check-in is another opportunity for the server to repeat calculations it may have already performed thousands of times.

The Legacy Baseline

Traditional macOS MDM is reliable, secure, and widely deployed, but its mechanical design is server-centric.

APNs wakes the device. mdmclient checks in. The server returns commands. The device reports status. The server calculates drift. The server decides what comes next.

That model works, but it creates a scaling penalty: the MDM server must repeatedly calculate compliance deltas for every device across the fleet, even when most devices are already in the desired state.

That is the legacy baseline. Before evaluating newer Apple management models, it is essential to understand this bottleneck clearly: traditional MDM is not merely a communication protocol. It is a server-side reconciliation engine.