Adopt declarative device management

♪ instrumental hip hop music ♪ ♪ Welcome to the "Adopt declarative device management" session.

My name is Cyrus Daboo, and I am an engineer on the Device Management team.

I am here to tell you about the exciting new features in declarative device management.

At WWDC21, my colleague Melissa introduced declarative device management, a new paradigm for managing Apple devices, reenvisioning the MDM protocol itself.

As we learned in that session, declarative device management is powerful because it enables devices to be autonomous and proactive.

The device is autonomous, as it reacts to its own state changes and then applies management logic to itself, without prompting from the server.

The device is proactive, with the status channel asynchronously reporting to the server when important state changes occur, avoiding the need for servers to poll devices.

There are two key elements to the declarative device management data model: declarations and status.

Declarations encompass activations and predicates, configurations, assets, and management types.

And status covers status items and status reporting.

Let's take a moment to talk about why this matters, what it means for you, and the organizations that use your products.

We have created this technology to support new complex management strategies, enhance the overall user experience of managed devices, alleviate the repetitive and tedious tasks of an IT admin, and empower devices to be the driver in their own management state.

For you, as a developer of a device management solution, the declarative approach allows your servers to be lightweight and reactive.

And with the declarative data model more closely mapping to how organizations are structured, that means changes to devices becomes more intuitive.

Status reports provide a rich feedback channel, which enable your servers to monitor devices more closely, and present pertinent information in a more timely and reliable fashion, without the need for complex strategies used to implement polling.

All of this means a simpler development effort, enabling you to focus on the device management features that add value where it matters most, and create a solution your customers will love.

For IT admins, the declarative approach inspires more confidence that the device is in the expected state.

And in the situations where it is not, that it is in a safe state that protects any sensitive organization data, even when connectivity to the server is lost.

It provides critical feedback from devices via status reports, that also improves efficiency for admins through less utilization of resources such as network bandwidth.

For the organization's users, device management becomes a more responsive and reliable experience with faster onboarding, quicker recovery times and better support from their organization.

With all these benefits in mind, know that the focus of future protocol features will be declarative device management, making it even more important for you to adopt declarative device management in your products today.

For an in-depth introduction to declarative device management and the steps needed to adopt it, make sure you watch the WWDC21 session video.

In this release, we have three focus areas: expanding the scope of declarative device management, enhancing status reports, and enhancing predicates.

Let's start with expanding the scope of declarative device management.

When declarative device management was introduced, it was supported on only iOS with user enrollments.

Now, declarative device management is available for every enrollment type MDM supports: automatic device enrollment, which includes supervised devices; profile-based enrollment; and profile and account-based user enrollments.

Declarative device management is now also available on Shared iPad.

In iOS 16, users can now find configurations in the MDM profile details view in the Settings app.

Tapping the Configurations row reveals details about the active configurations.

And I am also pleased to announce that declarative device management is available on every platform MDM supports.

macOS Ventura now supports declarative device management, for all MDM enrollment types supported on macOS.

tvOS 16 now supports declarative device management for MDM device enrollment types.

Where supported by the OS, the same set of declarations and status that are available on iOS are also available on macOS and tvOS.

On macOS, a Configurations section is present in the MDM profile details view, revealing the active configurations.

The same goes for tvOS, where a Configurations section is present in the MDM profile details view.

One last thing to note here: both macOS and Shared iPad devices each have two MDM channels.

These are the device and user channel.

The device channel allows management of device level state, whereas the user channel targets management state for specific users.

To use declarative device management on any channel, it must be enabled separately for that channel.

That means sending the DeclarativeManagement command on the corresponding channel.

Also, declarative device management status reports are separately generated for each channel, so they need to be separately monitored as well.

Now on to our second focus area: status reports.

Let's do a quick review of status reports.

Devices can incrementally report status to the server, for subscribed status items.

The device tracks successful responses from the server to ensure status updates are reliable and not missed in the case of networking or other types of problem.

Status reporting makes the device proactive.

There is no need for servers to continuously poll the device to watch for state changes.

In iOS 15, we introduced a set of status items for device properties, such as model type and operating system version.

For this release we are expanding status in three areas: passcode state, accounts installed by configurations, and MDM installed apps.

Let's start with passcode status.

In iOS 15, we introduced a passcode policy configuration.

There can be some lag between the policy being applied, and the passcode becoming compliant when changed by the user, just as there is with MDM passcode policy profiles.

So, MDM servers have to poll the device to determine when the passcode becomes compliant.

But with the new declarative device management passcode status items, there is no need to do that.

We have added two status items: Passcode.is-compliant and passcode.is-present.

Compliance indicates if the passcode is compliant with all passcode policies applied via MDM profiles or configurations.

These status items have Boolean values that mirror the equivalent properties that can be retrieved via MDM queries.

Let's explore a typical server behavior.

Often, an organization has security sensitive state to apply to a device.

For example, VPN or Wi-Fi profiles to allow access to protected networks.

That state should only be active on a device, when a strong passcode policy is present, and the passcode is compliant with that policy.

With traditional MDM, a server has to send a passcode policy profile then poll the device, to wait for the passcode to become compliant when the user changes it.

Initially the passcode is likely not compliant, so the Wi-Fi profile cannot be sent.

Eventually, the user changes the passcode to bring it into compliance.

On the server's next poll, it detects the changed compliant state and determines it is OK to send the Wi-Fi profile, which then gets installed on the device.

Declarative device management removes the need for the server to poll by using an activation predicate that is triggered by the passcode compliance state.

The server sends both the passcode policy and the Wi-Fi profile as configurations, with the Wi-Fi configuration tied to an activation predicated on the passcode compliance.

The passcode configuration is immediately activated and applies a strong passcode policy.

Initially, the passcode is likely not compliant, so the activation predicate evaluates to false, and the Wi-Fi configuration is not activated.

At some point, the user updates the passcode to be compliant.

This triggers reevaluation of the activations and the predicate now evaluates to true, resulting in the Wi-Fi configuration being activated.

All this happens without any intervention from the server, and in fact can happen without any connection to the server being present.

The server does automatically get a status report from the device when the configuration activates, so it knows when the change takes place.

This illustrates how we have successfully moved business logic from the server to the device, to avoid the need to poll and get a more responsive and reliable device behavior.

Now, let's turn to account status.

In iOS 15, we introduced account configurations to install accounts of various types on a device.

These are typically organization accounts, giving the user access to organization data.

It is useful for the admin to know when accounts have been successfully installed, and what state they are in, to help support users who might be having problems.

This release adds eight account status items for mail, calendar, and other account types.

Note, that status is only reported for accounts installed by configurations and won't include accounts created manually or installed via MDM profiles.

Each new status item corresponds to an account configuration type, with status for incoming and outgoing mail accounts reported separately.

The new status items each use a different type of JSON object, to represent the status of the corresponding account type.

Here are examples of an incoming mail status item, and a subscribed calendar status item.

The value of the identifier key is a unique identifier for an object within the array of status item objects -- more on this in a minute.

The value of the declaration identifier key, matches the identifier property value of the configuration that installed the account, making it easy to cross-reference the status item object and its associated configuration.

These two keys are always present in all types of account status item object.

The other keys are specific to the type of account.

For example, hostname and port for the mail server, or calendar-URL for the subscribed calendar.

This release introduces status items whose value is an array, to support reporting on one or more accounts of the same type.

Such array values have special behavior.

Each item in the array is a JSON object with the same schema used for all objects in a single array.

Each object type always has an identifier key, acting as the primary key for locating objects within the array.

Other keys are present and tied to the underlying type of status being reported.

To ensure forwards compatibility with any keys added in future OS releases, your server must accept unknown keys in array objects.

Changes to an array value are always reported incrementally to the server on a per-object basis, for performance reasons.

Let's run through an example that shows how this new feature works.

In this example, the server sends two mail account configurations to the device.

These are both active resulting in two mail accounts present on the device.

The server now sends a status subscription for the mail account status item.

When the subscription is activated, status for the accounts is collected, and the device sends a status report to the server.

The status report will include the two account status objects in the status array, giving the server a complete picture of what is currently present on the device.

Each array object has a different identifier.

After processing this report, the server has status for two mail accounts, matching what is on the device.

When the server adds a mail account on the device by sending a new configuration, the status item on the device has a new object added to its array value, and another status report is sent to the server.

Only the new item is reported.

The value of the identifier key does not match any the server already has, so the server can infer this corresponds to a new account.

After processing this report, the server has status for three mail accounts, the two initial ones and the new one, again matching exactly what is on the device.

When account status changes, such as when a user toggles the mail or notes enabled state, the status item on the device will have an updated object in its array value, and again, a status report is sent to the server.

Only the changed item is reported.

In this case, the user turned off the notes feature for the account.

The value of the identifier key matches one the server already has, so the server can infer that this is an update to an existing account.

Consequently, it replaces the existing status item array object with the new one.

After processing this report, the server has status for three mail accounts, but one has changed.

When an account configuration is removed from the device, the status item on the device has the corresponding object marked for removal, and another status report is sent to the server.

Only the removed item is reported.

To indicate removal, the array item object contains only two keys: the identifier key -- whose value matches one the server already has -- and the removed key, set to the value true.

This allows the server to update its representation of the device state by removing the existing item.

After processing this report, the server has status for only two mail accounts, correctly matching the state of the device.

One last point about status reports.

The device will limit the rate at which status reports are sent to avoid performance issues.

The device aggregates changes to status items over a variable interval of up to one minute before sending a status report to the server.

This means status is reported quickly, but it is not immediate.

Next, let's turn our attention to solving a perennial MDM-bottleneck problem: monitoring application install status.

MDM servers often install apps on devices to give users access to the tools needed for their work or education.

Server-side logic is often dictated by whether an app is installed successfully or not.

So MDM servers need to monitor app installation progress and watch for the possibility of users removing managed apps on their device.

Currently, MDM servers can use the InstalledApplicationList or ManagedApplicationList commands to poll the device to observe app installation progress.

We can avoid polling by having the device proactively send app install progress to the server.

And the tool to do that is declarative device management status reports.

This release adds an mdm.app status item.

Its value is an array of objects that each represent an app that has been installed by the MDM server.

Since this value is an array, it is reported incrementally, using the procedure described earlier.

Note that only apps installed by MDM are reported here, even on supervised devices.

This status report includes a status item for an app that has finished installing.

The identifier key is the unique identifier for the array item object, and in this case, is the app's bundle identifier.

The name key indicates the name of the app.

The three version keys provide normal, short, and external version identifiers.

And the state key is an enumeration that indicates the current install phase for the app.

The values of these keys correspond to the equivalent items in the MDM ManagedApplicationList command response.

With all this information, the server can immediately identify which app is being reported and what its state is.

Let's examine an example of the flow of data as an app installs.

On the right side, we have an iOS 16 device that is being managed by an MDM server.

The server has already enabled declarative device management and sent a status subscription for the MDM-installed app status item.

The next step for the server is to install an app using the MDM InstallApplication command.

Since this is a user enrollment, user approval is needed to install the app, so a prompt appears when the device processes the app install command.

At this point, the installation progress is paused, waiting for user input.

The device will send a status report to the server, and that will contain a single MDM-installed app status object, with the bundle ID of the app and the state set to prompting.

At some point, the user taps the Install button, and the app install starts on the device.

As the install proceeds, another status report will be sent, this time with the app state set to installing; indicating the app is being downloaded and installed.

Eventually, the app completes installation and is ready for use.

At that point, another status report will be sent with the app state set to managed, indicating the app is properly installed and managed.

Now, let's say the user manually deletes the app on the device.

Again, a status report will be sent, this time with the app state set to managed-but-uninstalled.

This indicates the app is no longer installed, but its management state is still being tracked on the device.

Let's assume the server wants to remove the app-management state.

It does that by sending a RemoveApplication command to the device.

That removes the internally maintained management state, and if the app were still present, it would be removed too.

Another status report will be sent with the app object marked as removed from the app status array.

This illustrates the power of the new MDM status item to help improve the responsiveness and reliability of app installs, and it only takes a few steps to implement.

Now, let's examine our third focus area: predicates.

Let's quickly review activation predicates.

Activations can include an optional predicate that determines whether the configurations referenced in the activation will be applied to the device.

Predicates can reference status items to allow the values of those status items to be tested.

When a status item referenced in a predicate changes, the device will reprocess all of the activations, reevaluating any predicates.

Predicates are specified as a string using the NSPredicate syntax documented on the Apple Developer site.

To support more complex predicate expressions, we have extended the predicate syntax to make it easier to detect status items in the expression.

The new syntax places the status item name inside an @status term in the predicate string.

In the example, the serial number status item appears in the predicate expression, using the new syntax.

The previous syntax will continue to work for backwards compatibility, however, it is now deprecated, so please switch to the new one.

Let's examine how predicates can be used with status item array values.

As we just described, we now have status item values that are arrays for the accounts and MDM-installed app status items.

It is useful to be able to predicate an activation on an item in the array.

For example, we might want an activation to be triggered when an app with a particular bundle identifier is installed and managed on the device.

NSPredicate has a SUBQUERY term that can be used to operate on arrays.

This NSPredicate expression uses a SUBQUERY targeting the MDM-installed app status item.

The status item is used as the first argument to the SUBQUERY.

The second argument defines a variable that will refer to each element of the array.

The third argument is a predicate expression that tests each element identified by that variable.

The SUBQUERY expression returns an array of elements that match the predicate in the third argument.

The @count operator then returns the length of that array, and the length is checked to determine if there is one resulting match.

When the specified app is installed and managed, this SUBQUERY expression will return an array with a single element, and the predicate will evaluate to true.

When the app is not installed, the SUBQUERY expression will return an empty array, and the predicate will evaluate to false.

Note that in order to reference the keys in the status item array object, the @key extension term must be used to ensure the key paths are properly processed.

The new predicate syntax is extensible, and we will now discuss how it can be used to add predicate terms for a new type of data.

Servers need to be able to more directly control the evaluation of predicates, so that complex server-side logic can translate into simple state changes on the device, without the need to synchronize large sets of configurations to trigger those changes.

An example of this might be an organization that has users with multiple roles and wants efficient, just-in-time assignment of devices as they are handed out to users, or organizations that need to quickly distribute replacement devices, or quickly put devices into a safe mode to protect organization data.

To support this, I am pleased to say we are adding a new declaration to allow servers to set arbitrary properties on the device, that can be directly used in activation predicates.

This is the new management properties declaration.

The declaration consists of a JSON object whose key names are defined by the server.

The JSON object values can be any JSON value type, including arrays or objects.

The management properties declaration here, includes three properties: the name and age properties that have a string and integer value, and the roles property that is an array of strings.

This is an activation with a predicate that references some management properties.

First, it tests the age property to determine if its integer value is greater than or equal to 18, then it tests the roles property to determine if the string Grade12 is in the property array value.

Each property is referenced using the @property extension term, with the property key name inside the term.

Multiple management properties declarations can be sent to the device, but the keys should be unique across all of them.

If there are duplicate keys, one of the values will be arbitrarily chosen when the property is referenced in a predicate, leading to unpredictable results.

So please avoid using duplicate key names.

Let's explore an example use case.

This example involves a school.

And of course, the school has a set of teachers.

The school has two divisions: Upper and Lower.

Each division has its own campus with its own Wi-Fi network.

Some teachers function as an IT Admin and require access to a shared mail account.

Some teachers also function as a sports coach and should have a subscribed calendar for all the team game schedules.

There are thus four different roles that a teacher may have, and sometimes they have multiple roles.

Each role has a set of configurations that must be applied to devices based on the roles of the teacher assigned to the device.

Let's consider two teachers in our example.

Teacher one teaches in Lower school and is also a sports coach.

Teacher two teaches in Upper school and is also an IT admin.

How might such a use case be handled by a traditional MDM server? Typically, the server has to wait for a device to be assigned to a teacher before it can fully configure that device.

The server has to determine what roles the teacher has.

It then determines what profiles are linked to each role.

It then has to install each profile on the device one at a time.

If a teacher changes roles, the server has to add or remove profiles to match the new roles.

This is time-consuming and can introduce significant bottlenecks to a device-management system particularly at peak times, which in our case would be the first day of school when assignments are done.

With the new management properties declaration, we have a more efficient alternative to this.

This involves preloading a full set of declarations on the device ahead of time.

Configurations are assigned to activations, with predicates that are triggered for different roles via management properties.

When a device is assigned to a teacher, the server sends only a management properties declaration with the teacher's roles, which triggers activation of the configurations for those roles.

This method minimizes the overall server and network traffic and reduces the complexity of making rapid changes to device state.

Let's go back to our school example.

The server will preload the following sets of declarations: two activation/configuration pairs that set up the Wi-Fi network for each division.

Then, we have an activation/configuration pair for the IT admin role, that installs a mail account.

Finally, we have an activation and configuration that installs a subscribed calendar.

Each activation has a predicate that tests the division or function's name using the roles management property.

When initially loaded on an unassigned device, all the predicates evaluate to false, so nothing is applied.

Now, let's examine what happens on the day of assignment.

All the server needs to do is create management properties declarations customized to each teacher.

Teacher one has a roles property that lists Lower and Sports.

Teacher two has a roles property that lists Upper and IT Admin.

When these declarations are separately sent to each assigned device, the preloaded activations will all be reevaluated.

So teacher one's device has the configurations for Lower and Sports roles activated.

And teacher two's device has the configurations for the Upper and IT Admin roles activated.

Only a single declaration is needed to trigger the application of many configurations.

Finally, let's examine what happens when a teacher changes roles.

In this case, teacher two has become a sports coach in addition to their existing roles.

The management properties declaration for the teacher's assigned device is now updated to include the additional role name.

When that declaration is updated on the device, all the activations are reevaluated.

In this case, the subscribed calendar configuration for the new Sports role will be applied.

Again, only a single declaration change is needed as a trigger.

This illustrates how the management properties declaration provides a powerful way to quickly and easily switch between sets of configurations on a device, so that complex server-side logic can translate into simple state changes on the device.

Now, let's wrap up.

We have extended the scope of declarative device management on iOS 16, tvOS 16, and macOS Ventura, as well as making it available for all applicable types of MDM enrollment, including Shared iPad.

This provides full support for declarative device management across all Apple devices that support MDM.

We have added new status items for passcode, accounts, and MDM-installed apps.

The MDM-installed app status provides a great solution for one of MDM's key bottlenecks.

Finally, we have enhanced the predicate syntax to make it more extensible and easy to use and added the new management properties declaration that gives servers even more opportunity to move complex business logic to the device.

Now is the time to add declarative device management to your products.

And we're excited to learn what you'll do to reimagine device management solutions using declarative device management! As always, your feedback is greatly appreciated.

Thank you and enjoy the rest of WWDC.

♪ ♪