# apple/device-management: Apple's MDM and Declarative Device Management schema data > Apple's device-management repository publishes the YAML schema data behind the MDM protocol and Declarative Device Management, versioned against OS releases, with example payloads and no pull request path. It is a contract for tools, not a tool. **apple/device-management** — Device management schema data for MDM. - Repository: https://github.com/apple/device-management - Stars: 1,004 · Forks: 137 - Language: Unknown - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/apple-device-management ## Schema data, not a management server The apple/device-management repository holds one thing: schema data for the MDM protocol and for the Declarative Device Management feature. There is no daemon to install, no client library to link and no API server to start. The short description reads: Device management schema data for MDM. That framing matters if you arrived looking for a device management tool. A management agent is the code that lives on a Mac, iPhone, iPad, watch or Apple Vision Pro and receives commands from a management platform. This repository is not that agent. It is the written contract such an agent has to satisfy, expressed as YAML schema files arranged in a directory tree. So the audience is the people writing the management side of the conversation: engineers assembling check-in payloads, generating profiles, or implementing Declarative Device Management status reporting. The value is that those payloads are built against a definition of the protocol rather than against guesswork. A reader expecting a runnable console will find a data set and its documentation. ## One release line covers five operating systems at 27.0 The schema set is versioned against operating system releases rather than against a version number of its own. The release described in the README covers iOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0 and watchOS 27.0, and that table is how a reader tells which generation of the data is in front of them. The detail that matters for a pipeline is where change history lives. The README points to CHANGES.md for the significant changes in a release, so the difference between two schema revisions is read from a Markdown file inside the repository rather than from a tag or a published artefact. The repository has no GitHub releases, and its default branch is named release. Anyone who wants a stable input therefore has to pin a commit or a branch and read CHANGES.md by hand to learn what actually moved. That arrangement has a cost. There is no release list to diff against and no upgrade note written for operators, only a per-release changelog for people who already know where to look. ## mdm/ splits commands, check-in, profiles and errors Classic mobile device management is the part of the protocol most teams touch first, and the tree is split into four directories for it. Commands live in mdm/commands, the payload a device sends when it first contacts a server lives in mdm/checkin, configuration profiles live in mdm/profiles, and the error catalogue lives in mdm/errors. The split is the useful part for implementers. Command definitions and error definitions change for different reasons and on different schedules, and a payload generator that reads both from one directory has to reconcile two unrelated update streams. Separating them lets a tool subscribe to the subset it actually needs, and it makes an error lookup a small local read rather than a search across the whole protocol. The tree is the only index the repository offers. There is no generated API listing and no cross reference table beyond the OpenAPI specifications for select services in the openapi directory, so a new reader maps the protocol by walking directories. ## declarative/ adds declarations, status and protocol Declarative Device Management is a separate Apple mechanism, and the repository keeps it away from the command-and-response part of MDM. Three directories carry it: declarative/declarations for the declarations, declarative/status for the status items, and declarative/protocol for the protocol itself. As the names imply, the declarations describe a desired configuration and the status items describe what a device reports back, while the protocol directory describes the exchange itself. Keeping that trio under one parent makes the difference from the imperative model visible in the layout: nothing in declarative/ shares a directory with mdm/commands, and the two styles of management are versioned and reviewed separately. A catch-all also exists. Beyond the named directories there is other device management data formats, a bucket whose contents are not itemised in the README, so anyone hoping for a complete index of the protocol will not find one here. ## Getting the data and reading the YAML schema definition There is no installation step, and the repository does not present one. The project is distributed as data in a Git repository, so the practical first move is to clone it and read the tree. The default branch is release, and the directories below are the ones the README lists as available schema items and data formats: ```text mdm/commands mdm/checkin mdm/profiles mdm/errors declarative/declarations declarative/status declarative/protocol ``` Once you have the files, the definition of the schema format itself sits in docs/schema.md, and the significant changes for the current release sit in CHANGES.md. Both live in the repository, so a reader can confirm the format before parsing anything. The MIT licence in LICENSE.txt allows you to copy the YAML into your own tooling, which is what most consumers end up doing, since there is no package to depend on and no published release to install. No alternative source for the same data is named anywhere in the documentation, so a comparison has no second reference point to weigh against. ## examples/ mirrors the schema tree through an examples key The examples directory exists so that every schema item ships with a runnable shape instead of a paragraph of prose. It contains three sub-directories, declarative, mdm and other, and each one mirrors the structure of the corresponding schema directories. Below that level every schema item has its own directory holding the example files for that schema object. The mechanism that ties examples to definitions is a key inside the YAML. Each YAML schema file contains an examples key that lists relative file paths to its example files. That is the part worth copying in your own tooling: because the reference is relative and lives in the schema file itself, a validator can resolve example payloads against the definition without a hardcoded path table that drifts out of date. The cost is duplication. Every schema item is described twice, once in the definition and once in the example tree, so a rename in one place leaves the other stale until someone updates it. ## Feedback Assistant replaces the pull request path The contribution model is unusual and worth knowing before you plan any patch. Pull requests are not accepted on this repository. All feedback on the data is supposed to go through the Feedback Assistant app or website, where the request is filed under Enterprise & Education and then under the Mobile Device Management (MDM) area. The repository ships no homepage, no issue template and no public roadmap, so the feedback path is a support channel rather than a development queue. Practically that means you can read the data, copy it and build on it, but you cannot merge a fix yourself, and you have no public place to see whether a similar report is already known. For teams that need a specific schema correction on a deadline, that is a real constraint rather than a paperwork detail. The repository is not archived and the last push was on 2026-10-07, so the data is refreshed, but the refresh comes as a new state of the release branch and a CHANGES.md entry rather than as a published release you can subscribe to. ## Conclusion Adopt it if you generate MDM or Declarative Device Management payloads and need Apple's current schema definitions; skip it if you want a management agent, a console or a server. Before wiring the YAML into a build, read CHANGES.md for the 27.0 changes and confirm the relative paths under the examples key still match the examples directories in your checkout. ## FAQ ### What does the apple/device-management repository actually contain? It contains Apple's Device Management Client schema data for the MDM protocol and for Declarative Device Management, laid out as YAML schema files under mdm/, declarative/, openapi/ and other/, with an examples tree and a CHANGES.md file. ### Which operating system versions does the current schema data cover? The current release corresponds to iOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0 and watchOS 27.0. ### How do I report a problem or request a change to the device management schema? Pull requests are not accepted. Feedback goes to the Feedback Assistant app or website, filed under Enterprise & Education and the Mobile Device Management (MDM) area. ### Does apple/device-management publish GitHub releases I can pin against? No. The repository has no GitHub releases; the default branch is release, and CHANGES.md records the significant changes for each schema release. ## Sources - [apple/device-management on GitHub](https://github.com/apple/device-management) - [Issues](https://github.com/apple/device-management/issues) - [License: MIT](https://github.com/apple/device-management/blob/release/LICENSE) - [README](https://github.com/apple/device-management/blob/release/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apple-device-management