ProfileManifests: the shared preference manifests behind ProfileCreator and iMazing

What a preference manifest actually is

ProfileManifests is a preference manifest repository for Apple devices system and application domains that powers ProfileCreator and iMazing Profile Editor.

The underlying format is Apple's own. The payload manifest files use Apple's Preference Manifest File format to describe the payloads and their keys, and the README links to Apple's Preference Manifest Files for Managed Clients Overview as the reference for the format itself.

That format is the machine-readable description of what a configuration profile payload can contain. A payload is the unit that macOS management actually consumes: a set of keys with a specific type, a description of what each key does, and the domain it belongs to. The manifest is what makes a payload editor possible, because the editor needs to know the valid keys, their types and their defaults before it can show you a form for them.

So a manifest repository is really a schema repository with a friendly front end. That framing matters for evaluating it, because what you are looking at when you browse Manifests/ is not a set of profiles to deploy but a description of the settings that exist, so that tooling can build profiles from them.

The format has been extended. To meet all required functionality that format has been extended with more keys and options, and the README points to a ProfileManifest Format page in the project's wiki as the reference to use when creating manifests. So the canonical reference is Apple's, but the actual specification the community works against is the extended one, and the difference between the two is where the project's real content lives.

The primary language is listed as Python, the default branch is master, the last push was on 2026-10-07, and the repository has no GitHub releases. The licence is not stated in the repository metadata, which matters for a data repository whose contents are redistributed by other tools, and the LICENSE question is something to raise with the maintainers rather than assume.

Two consumers, one source of truth

The stated purpose of the repository is to provide administrators with a central, common collection which makes it possible to easily configure and manage any available settings in Apple products and supporting third-party software.

The word central is doing the work. Apple configuration profiles have a long history of divergent descriptions: the same payload documented differently by different vendors, keys whose types are guessed rather than known, and profiles that break when a new OS release changes a default. A single shared collection means one place to look, one place to fix, and one place to see whether a key is already documented.

Two tools consume it. ProfileCreator is the open source profile editor, and iMazing Profile Editor is the commercial one from the iMazing team. Both read the manifests from here rather than shipping their own copies, which is what makes the collection central in practice rather than only in principle.

That also means the repository is a dependency of other people's software in a way that is easy to miss. If a manifest is wrong or a key is missing, the effect appears in ProfileCreator's form or in iMazing's, not here, because this repository has no behaviour of its own to observe.

The contribution model follows from that. By contributing to this repo, you are helping make the lives of all members of the Mac Admin community easier and lowering the barrier to entry for those who are new to managing Apple devices in the process. The README asks contributors to review two wiki pages first, Getting Started and Contributing to an Existing Manifest, and to ask questions in the #profilemanifests channel in the MacAdmins Slack if they need help.

The MacAdmins Slack being the named support channel is a reasonable choice for this project. It is where the Apple management community already lives, and a manifest contribution is a question about what a key does, which is a question for people who manage Apple devices professionally rather than for a general issue tracker.

The Jamf mirror and what it gives Jamf administrators

There is a second output from the same source, and it is the part with the broadest reach.

All changes and improvements made here are also immediately converted into Jamf's JSON Schema in the ProfileManifestsMirror repository for use with Jamf. The README explains that this provides an intuitive interface for managing payloads and preferences not natively supported in Jamf.

That last clause is the important one. Jamf's own interface covers the payloads Jamf supports. The mirror covers the ones it does not, so an administrator who wants to set a preference inside a payload that Jamf has no form for can still do it through a schema-driven editor rather than by hand-editing XML.

The conversion being automatic and immediate is the design point. A single source means the schema form and the profile editor form cannot drift apart, because both are derived from the same manifests on every change rather than being maintained separately.

The README attributes this work explicitly. A debt of gratitude is owed to Elliot Jordan for his efforts in extending the functionality of this project, with a link to a post about the mirror. So the Jamf schema pipeline is a contributed extension rather than something that shipped with the original format work.

For an administrator choosing between tools, the practical question becomes which of the two consumers to use rather than which manifest set to use, because the manifest set is shared. The differences are in the editors, and the mirror is the bridge for the largest vendor in the space.

Getting the manifests into your workflow

There are no install steps for this repository, and that is the correct shape for it. It holds no code to run and no package to fetch, so the README points you at the two wiki pages instead: the Getting Started guide for a quick start on creating your own manifest, and the Contributing to an Existing Manifest page for extending one that already exists.

In practice the acquisition path is through the consumer tools. You install ProfileCreator or the iMazing Profile Editor in the normal way for those applications, and they fetch the manifests from this repository. If you want the collection locally for tooling of your own, you clone the repository and read the Manifests/ directory, which is the same content the editors consume.

Two things are worth doing before you rely on it. The first is checking that the domain you need is covered, by looking in Manifests/ for the relevant application or system domain and seeing whether the keys you want are present. The second is checking whether the manifest you need is in Manifests/ or ManifestsInactive/, because a payload you find in the inactive directory is one the project has moved aside.

If what you need is missing, the contribution route is the one the README describes: read the Getting Started wiki page, follow the ProfileManifest Format reference, and put the manifest up for pull request. The pre-commit configuration will validate the file and regenerate the indexes as part of the commit, so a well-formed manifest needs no manual index editing.

For questions that the wiki pages do not answer, the MacAdmins Slack channel is where the project points people, with the #profilemanifests channel named specifically.

How the repository is organised, and what the index script does

The repository layout is small and tells you what the project is made of.

There is a Manifests/ directory, which is the active collection, and a ManifestsInactive/ directory beside it. The split is the interesting part: a manifest that is deprecated, or that applies to an OS version no longer in support, or that has been superseded, moves to the inactive directory rather than being deleted. That matters because profiles referencing an old payload still exist in the wild, and deleting the manifest would leave those profiles uneditable with no way to see what the key meant.

Icons/ holds the icon assets, ManifestExamples/ holds example manifests, and Resources/ holds shared resources including the icon used in the README. There is an ACKNOWLEDGEMENTS.md, a .pre-commit-config.yaml, and updateIndexes.py at the root.

That last file is the only code of substance in the repository, and the presence of Python as the primary language is explained by it. The manifests are consumed by other tools, but they need indexes: a list of which manifests exist, which domains they cover, and so on, so a consumer can find the manifest it needs without scanning the whole tree. updateIndexes.py generates those indexes, and the pre-commit configuration is what runs it, so an index is regenerated when a manifest is added or changed rather than being maintained by hand.

That is a sensible arrangement for a repository whose content is data. The interesting engineering is in the tooling that keeps the data navigable, and the pre-commit hook means the indexes cannot fall out of step with the manifests.

The README's contribution pointers complete the picture. Read the Getting Started page for a quick start guide if you want to create your own manifest, and the Contributing to an Existing Manifest page if you are extending one that already exists. The distinction matters, because a new manifest and a correction to an existing one are different pieces of work with different validation requirements.

Where ProfileManifests is the wrong approach

There are three limits, and the first is about what a manifest repository can be held to.

The first is that it is a description of settings, not a guarantee about them. A manifest says what key exists, what type it takes and what it is for. It does not say what a particular macOS or iOS release does with that key, and it cannot: the behaviour lives in the OS, and Apple's own documentation is the authority on that. When a manifest and the OS disagree, the OS wins and the manifest is wrong, and the repository's contribution process cannot detect that on its own. Anyone relying on it has to check the release notes for the platform they are deploying to, which is the work the manifest was supposed to save.

The second is that the reference is Apple's, and Apple's reference for preference manifests is an archived document. The link in the README points to the MacOSXServer Conceptual documentation for Preference Manifest Files, which is archive material. That is not a criticism of the project, which has extended the format with its own wiki page, but it does mean the community specification has diverged from the vendor one and the community page is the one to trust.

The third is the licensing question, and for a data repository it is not a formality. The licence is not stated in the repository metadata, and there is no LICENSE file in the top-level entries. The manifests are consumed and redistributed by two third-party tools, one of them commercial, so the terms under which that redistribution happens are exactly the kind of thing that should be written down rather than assumed.

The honest alternative for an administrator who needs to configure a setting today is to write the payload by hand, or to use a vendor's own schema for the products that vendor supports. The trade is speed against clarity. Writing the payload by hand works for every key including the ones no manifest covers, and it works for every OS version, but it is XML by hand and it does not validate itself. Using the manifest gives you a form, a type check and a description, at the cost of depending on the community's accuracy and coverage.

What ProfileManifests offers over both is the accumulation. A key that one administrator worked out, described once, is available to everyone in a form that two established editors consume. That collective value is the entire argument for the repository, and it is why the contribution model, rather than the tooling, is the part that matters most for its future.

Editorial conclusion

Adopt ProfileManifests if you manage Apple devices and use ProfileCreator or the iMazing Profile Editor, since those tools read the manifests from here, and contribute back when you add a key the format does not cover. Do not expect it to be a tool you can install, because it is a data repository with a Python index script. Before you start, read the Getting Started wiki page, and note the licence is not stated in the repository metadata, so check with the maintainers before redistributing the manifest content.

Frequently asked questions

Official sources

1. Issues
2. ProfileManifests/ProfileManifests on GitHub
3. README