The history of Apple device management: where we started

In the beginning, there was the binary.

In 2003, before Apple released its MDM framework, most Apple admins managed macOS devices with Casper Suite — later known as Jamf Pro.

Mac admins would:

1. Enroll organizational devices in Apple services
2. Receive local binaries with root privileges
3. Send data about the Mac to a management server on a defined schedule

Mac admins could also cause the local client to take programmatic action by downloading packages and running local scripts.

This was "forced pull" device management.

iPhones changed everything.

With the introduction of iOS in 2007, life got more interesting.

The very thing that made iPhones attractive to users also made them more of a challenge to manage. A heavily sandboxed device rarely physically connected to a network meant more freedom and safety for users, but more headaches for IT.

Initially, IT managed organizational iOS devices manually through iTunes. Apple introduced profiles — .xml files that apply configuration settings to an iOS device — with the iPhone Configuration Utility in 2008.

This helped, but Apple administrators still needed a way to manage macOS and iOS with more finesse.

When Apple released the iPhone 4 they also introduced MDM capabilities with their MDM protocol. This opened the door to all kinds of possibilities for macOS and iOS.

Moving at the speed of Apple, Jamf developed MDM capabilities for customers right alongside them.

Gone was an agent with root-level access periodically contacting a management server.

A persistent connection

MDM necessitated push notifications. So, instead of a local agent periodically phoning home to a management server to ask: "Should I be doing something? How about now?", servers maintained a persistent connection to Apple.

When the management server wanted something to happen, it pinged Apple's core services and asked Apple to have the device phone home to receive a setting or command.

The MDM protocol has grown a great deal since Apple introduced it, with far more commands and more and more detailed settings available. It's the tech Jamf has been using alongside the Jamf Management Framework for nearly 13 years. In fact, Jamf Pro still uses binary-related pull actions and MDM push commands as well.

Legacy MDM workflows

MDM structure was an improvement on relying exclusively on the binary, and both Apple and Jamf did loads with this structure to make work simpler for everyone.

But it was not without its problems.

Remember that traditional MDM relies on a device having a persistent connection to Apple, and a management server asking Apple to have a managed device phone home to receive a command or a query.

The command might be:

• Update your OS.
• Apply this setting to connect to company Wi-Fi.
• Install these managed apps.

Then the subsequent query to ensure that the device executed the change correctly might be:

• What's your OS right now?
• Did you apply that Wi-Fi setting?
• Tell me what apps you have installed.

So in traditional MDM, IT gets acknowledgments when commands have been received or completed, and they can get a lot of information back from the device when they ask— but they do have to ask. Repeatedly.

IT also can get scads of duplicative information back. Repeatedly. And if an Apple admin is queuing up complex or conditional workflows, they are asking for quite a bit of information, quite a bit of the time. After they get this information, IT asks the management server to:

• Ingest and parse the information
• Possibly do calculations against it
• Trigger resulting commands and resulting queries
• Trigger resulting polling

. . . and on and on and on.

It boils down to this: Legacy MDM is very chatty and can use a lot of network resources.

What's so great about DDM?

Simply put, declarative device management (DDM) cuts back on all that chatter, allowing for better performance and scaleability.

It allows a device to independently apply settings and report to the MDM server without being asked.

This means that devices can stay compliant and secure, even without input from the MDM. Because it's faster and more autonomous than MDM without declarative device management, it provides a better, more responsive user experience.

A macOS or iOS device proactively shares information about its current state (and any changes) with the MDM server, which means devices can respond immediately to prevent malware attacks, keep in compliance and ensure all users are trusted users.

Learn more information about DDM from Apple.

DDM workflows are smoother.

With declarations, IT can take advantage of far more detailed up-front instructions that tell the device how to behave under a set of conditions. That set of instructions combines with status reporting to alert the management server when certain values change on the device.

So, rather than the lengthy and repeated back-and-forth, the management server can compose a set of instructions and send it to the device directly. After receiving the instructions, the device can behave autonomously without nearly as much traffic back to MDM, and without nearly as much calculation-intensive behavior on the management server itself to tell the device what to do next.

The server doesn't have to wait for a full inventory update or parse out the delta of particular values from a big .xml file. IT just designates the ideal device state and requests that the device take remedial action and report in when those values have changed.

DDM: the future of MDM is now.

We've come a long way from Apple's introduction of local binaries in 2003. Each step has opened the door to better, faster and more detailed capabilities.

Declarative device management is a giant leap ahead in this history. We can't wait to find out what's next.

This blog post is adapted from portions of Katie English's JNUC 2023 presentation "What's Next for MDM?" Additional sources are linked to their origins from within the text of this post.