Apple has made a very exciting (for me) announcement today at WWDC 2021. I am back writing about stuff from WWDC like I did before. Apple is introducing a new way of delivering, processing, and evaluating everything we do on mobile devices known as “Declarative Device Management.” We are going to discuss this new paradigm on the well-established MDM protocols that many companies use to deliver things to our Apple devices today. We are going to discuss at high-level what declarative device management is, how it integrates into a MDM solution, and the requirements at this point in the Beta.

What is Declarative Device Management?

The idea behind Declarative Device Management (DDM) is similar to how VMware Horizon can let a device locally process video for Microsoft Teams “sort-of.” DDM will enable a device by making it autonomous and proactive. By leveraging the existing MDM protocols, DDM will increase performance and scalability.

DDM empowers a mobile device by letting it reach to its own state changes. The iOS device can now run more lightweight and reactive and eliminate the constant MDM polling. The device will now be:

Characteristic		How it Helps	Some Thoughts
Autonomous		Reacts to its own state changes and applies logic to itself without the server telling it to do something	Devices can now potentially act when offline based on predicates (more on that later).
Proactive		Status channel asynchronously reporting to the server when state changes happen eliminate a need for constant polling	This could be a huge game changer. I expect this will improve battery life and help MDM samples update far faster than ever before.

Let’s shift and discuss the declarative data model around DDM, which provides the building blocks that makes Declarative Device Management a potential game-changer for enterprises.

The Declarative Data Model

Every technology needs a structured data model to make things run more efficiently. Let’s check out what the code in a .mobileconfig profile looks like today:

<dict>

<key>AutoSelectCertificateForUrls</key>

<array>

<string>{pattern:https://cas.vidmpreview.com,filter:{ISSUER:{CN:TMApple}}}</string>

</array>

<key>PayloadEnabled</key>

<true/>

<key>PayloadDisplayName</key>

<string>Google Chrome Settings</string>

<key>PayloadIdentifier</key>

<string>com.google.Chrome.4F720473-6832-4CE0-A895-E9C3FC6F8CBD</string>

<key>PayloadType</key>

<string>com.google.Chrome</string>

<key>PayloadUUID</key>

<string>4F720473-6832-4CE0-A895-E9C3FC6F8CBD</string>

<key>PayloadVersion</key>

<integer>1</integer>

</dict>

Upon review, you will notice that the code is fairly clunky. MDM profiles are just a collection of XML tags/strings, etc. They’re very hard to manipulate and people get impacted relatively easily. Apple is proud to announce their new Declarative Data Model for DDM today:

Now, let’s break down the 3 building blocks of the declarative data model so you can see how much potential it has starting with Declarations.

Declarations

Declarations represent policy/profile structure. They can be used for settings, accounts, restrictions, etc. Additionally, declarations may be used for common or specific use e.g. policies sent to everyone or just a subset. Another key to mention is their shift to JSON (enjoy learning JSON now UEM peeps!):

• Type: Identifies the type of policy similar to today
• Identifier: A UUID for the declaration
• ServerToken: A unique revision of the Identifier based on the Identifier value, which can be a counter or unique ID.
• Payloads: That is a collection of settings, which you previously saw in arrays and strings.

Declaration Types

We have various types of declarations we can now discuss:

Configuration Declarations

Configurations represent the policies being applied to the device aka MDM Profiles. You can see a good example below:

The main challenge and theme you are noticing is a need to learn JSON now as a MDM engineer with the whole fun around {}, commas, and [].

Asset Declarations

Asset Declarations refer to the ancillary data needed by a configuration, like:

• MDM URLs
• User Information
• Certificates, etc.

A nice example below is:

Activation Declaration

Activation Declarations are a group of configurations that the device applies atomically. It ALSO means that if ONE of your configuration items is bad then nothing applies.

An example of the payload can be seen below:

On top of all that, activations have a many-to-many relationship meaning you can have multiple activations reference one configuration item. This lets your device work autonomously and process complex business logic.

It’s very exciting as you can have one activation hit multiple configurations at a given time or multiple activations hit a single configuration. This pliability can really drive some potentially amazing productivity at the device level.

Another area of great excitement are predicates. Predicates determine activation state and will process if its true. It’s basically conditional statements, which when true will process activations on the device like below:

This capability lets the MDM send everything down to a device and as things change, it will apply activation declarations just-in-time. Predicates are automatically re-assessed when device state changes happen without anything from the server. It will apply new policies and remove outdated ones allow your device to operate proactively for the first time. Keep in mind, if your predicates are missing then it will automatically process the item.

Let’s check out some code with a predicate:

Management Declarations

Management Declarations represent properties of the overall management state on the device. They will include stuff like:

• Organizational Information
• Server Capabilities
• Can Convey Static Information to the Device

Status Channel

Status Channel is simply a way of subscribing to exactly the exact information your server needs. The client will report to the server after the server subscribes to specific status items. This cuts down on chatter and only gives the server EXACTLY what it needs instead of a shotgun approach to MDM.

Status items themselves use a concept many people are familiar with where attributes are key-paths e.g.:

When subscribing to status items, the protocol will use a status subscription configuration item. The device sends initial and subsequent status reports. The reports are incremental and the declaration status is always reported to the server on a change.

An example of the configuration item can be seen below:

The response looks like this:

Extensibility

Extensibility has a few specific focuses to be aware of and ties all of this together:

• Helps manage compatibility over time.
• Device and server advertise what it supports just like a Client Hello and Server Hello in a SSL handshake.
• Reports Supported Features.
• Reports Supported Payloads.
• Server will indicate support in a management declaration.
• Client will indicate support as a specific status item.

Integrating with MDM

DDM is part of the core MDM protocols and is utilized for enrollment, HTTP transport, and device and user authentication. The integration is not going to be overly disruptive. The DDM commands and current MDM profiles/commands can co-exist nicely. This enables gradual adoption of declarations as a MDM vendors.

One of the nice things from a data perspective is that all declarations are removed on MDM unenrollment along with it not impacting existing MDM behavior. This certainly should lend to an early adoption by MDM vendors unlike other capabilities which took far too long to roll out like APNS v2.

Apple is introducing a new DeclarativeManagement command to activate declarative management. Once deployed, you can’t disable it unless all declarations are removed so that provides nice safeguards. Additionally, they are providing APIs for synchronizing declarations. Let’s discuss the CheckIn Request.

Using the CheckIn Request

The CheckIn request will synchronize declarations and send status reports to the server.

You will see two different types of responses with CheckIn requests: a list of declarations, and single declarations for the device to apply.

Migrating to Declaration Management

The great thing about the migration path is that you can create declarations as profiles, which gives you a really easy way to start the shift. You can see in the example below, you can specify a ProfileURL in the payload of your declaration to deliver really nice co-existence.

Data Flow for Declarative Management

The flow below shows you when a device is already enrolled in MDM and you activate Declarative Management:

This flow shows you after your activation completes and a CheckIn request occurs:

DDM Requirements

Let’s cover the requirements and then we can discuss:

• iOS 15 or iPadOS 15
• User Enrollment (Apparently we will also have a new onboarding flow in iOS 15 which we will discuss soon)

Current supporting DDM features:

• Configuration Declarations
  • Accounts
  • Passcode
  • Profiles
  • Status Subscriptions
• Activation Declarations
  • Simple Activation
• Asset Declarations
  • User Identity
  • User Credentials
• Management Declarations
  • Organization Details
  • Server Capabilities
• Status Items
  • Declaration State
  • Device Properties

Okay, so that’s really interesting. At this juncture, you cannot be a vanilla MDM enrollment and take advantage of this incredible offering. That is definitely cart before the horse! Apple is clearly trying to get you be more user-centric and less enterprise-centric. I can’t blame them for wanting to put user happiness at the forefront. I think these concepts are next level. This is EXACTLY like when HTTP/2 was released. I am blown away by the idea because they are really reinventing MDM as we know it!

Final Thoughts