The history of Apple device management: where we started

The future of Apple Mobile Device Management (MDM) is declarative device management. But how did we get here?

March 22 2024 by

Haddayr Copley-Woods

Katie English

An iMac G4: an Apple keyboard in front of a screen with a lamp-like design.

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.

Illustration of flow of information with the binary: A cloud and devices have back-and-forth arrows; the devices have a single arrow pointed at a server.

Fig 1: "Forced pull" device management with the binary

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.

Illustration of flow of information with the mdm protocol: A cloud and devices have back-and-forth arrows; a cloud with the Jamf logo also has back-and-forth arrows with the devices, the devices have a single arrow pointed at a server.

Fig. 2: MDM with push notifications.

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.

Depiction of declarative device management: arrow from Jamf server to devices and an arrow from devices to a Jamf server.

Fig. 3: Declarative device management

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.

See what Jamf can do for your organization using DDM.

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.