PPPC Utility: building macOS privacy payload profiles without a text editor

What the payload does, and why it is a pain to write by hand

The application exists to produce one specific macOS configuration profile payload. PPPC Utility is a macOS application, requiring version 13.0 or newer, for creating configuration profiles containing the Privacy Preferences Policy Control payload, and the profiles can be saved locally, signed or unsigned, and can also be uploaded directly to a Jamf Pro server. The reason an administrator would want a tool rather than a text editor is that the payload is a list of applications and executables with a set of privacy permissions granted to each, and a real deployment covers dozens of applications, each with several consent types, and a specific bundle identifier or executable path. The privacy prompts themselves are the familiar macOS dialogs asking for access to things like the camera, the microphone, the address book or the calendar, and pre-approving them through a profile is what stops a user being asked repeatedly and what lets an application work in a managed environment where the user should not have to make a decision. The tool does that assembly, and the interface is built around a table of applications rather than around XML.

Building a profile is a table of applications

The workflow is short and the documentation describes it in one step. You start by adding the bundles and executables for the payload, either by drag and drop or by selecting the add button in the left corner, and the result is a table of applications in the main window. The screenshots in the repository are labelled for the Building and the Saving steps, and the drag and drop approach is the one that scales, since a list of applications and their executables can come from a spreadsheet or from an export of what is actually running on your fleet. Once the list is there, the profile is saved locally, either signed or unsigned, with the signing identity chosen in the save flow. The distinction between signed and unsigned is not cosmetic, because an unsigned profile will be refused by a Mac with a strict verification policy, and the documentation handles that difference directly in the upload section, where the version of Jamf Pro determines whether signing is required at all. The application is a native macOS app rather than a web tool, which is the right shape for something that needs to hold a signing identity from your keychain.

Uploading to Jamf Pro, and the two version boundaries

The upload path has changed twice and the documentation is careful to give the boundaries, because getting it wrong means a profile that will not install. For any supported Jamf Pro version the utility can use bearer token authentication, with basic authentication as a fallback for versions of Jamf Pro older than v10.34, using the username and password of a Jamf Pro user account. From Jamf Pro 10.49 and higher, OAuth client credentials are an option, using the client ID and client secret that Jamf Pro generates in the API Roles and clients settings, and the utility walks through that during the upload. The older boundary is about signing. Starting in Jamf Pro 10.7.1 the Privacy Preferences Policy Control payload can be uploaded to the API without being signed first, so choosing a signing identity is optional, while for Jamf Pro 10.7.0 and below the profile has to be signed before it is uploaded and a signing identity must be chosen. That is a small operational detail that determines whether a batch of profiles will deploy at all.

The API permissions your account needs, and why one of them exists

The documentation names the two privileges the Jamf Pro user account needs at minimum, and the reasons are given. The first is Create macOS Configuration Profiles, described as the primary permission to upload the profiles, with the note that each upload from the utility creates a new profile, which is worth knowing because repeated uploads accumulate duplicates in the server rather than updating an existing one. The second is Read Activation Code, needed to retrieve the organization name that is placed in the profile, and that is the kind of requirement that looks odd until you know that a configuration profile carries the organization identity of whoever issued it. Both permissions belong in the API Role that is set up for the upload, and the documentation states that the client ID and secret are generated in the API Roles and clients settings. The overall security shape is reasonable for a tool that has to write into your management server, since the two permissions together are narrower than administrative access, and the read permission is read-only.

Importing, and the reverse direction

The utility can also read profiles in, and the documentation notes that both signed and unsigned profiles can be imported. That is a useful capability in a migration, because it means an administrator who already has a PPPC profile in production, whether written by hand or exported from another system, can load it and adjust it rather than rebuilding the application list. In the other direction, a profile saved locally can be imported into the utility and then uploaded to a Jamf Pro server, which is the path for organisations that stage changes on a workstation before pushing them to the management server. The import and export path also means the application list can be moved between tools, and the readme describes the profile formats as the macOS configuration profile format, with the payload inside. The screenshots document the import step in the same visual style as the building and saving steps, which makes the intended workflow reasonably obvious from the documentation alone.

How the project is put together and how to build on it

The repository is a standard Xcode project with a Swift application, and the layout gives you the usual macOS project structure. There is an Xcode project for the app, separate unit test and UI test targets with their own test plans, a Source directory, a Resources directory holding the asset catalogue with the app icon, an Images directory with the documentation screenshots, a docs directory, and a specs directory, plus a git-hooks directory, a .swift-format configuration and a pre-commit configuration. The Swift format configuration is worth noting because it means the project enforces a house style, and the pre-commit hook is the mechanism, installed with a symbolic link to the hook script in the git hooks directory:

ln -sf ../../git-hooks/pre-commit.swift-format .git/hooks/pre-commit

The hook runs swift-format over the Swift files before each commit. There is also an External directory for third-party code and a .claude directory alongside a CLAUDE.md, which suggests the project has been set up for agent-assisted work on it. The licence is MIT, and the changelog tracks all changes to the application, which the readme links as the place to see what changed.

Editorial conclusion

PPPC Utility is a good fit for a Mac administrator who manages privacy prompts across a set of applications and does not want to hand-write configuration profile XML, because it produces the payload, keeps the app list in a table, and can push the result straight into Jamf Pro. It is the wrong tool if you want to deploy profiles through a configuration management system other than Jamf Pro, and it is the wrong tool if you need a profile covering more than the PPPC payload, since that is a different tool for a different job. Before using it, check the Jamf Pro version in your tenancy, because the upload behaviour changed at 10.7.1 and the authentication options changed again at 10.49, and read the required API permissions carefully, since the account you use needs the create profiles permission and the read activation code permission. The app is MIT licensed, the last push was on 2026-08-05, and the current release is 2.0.0 from 2026-05-29.

Frequently asked questions

Official sources

1. Issues
2. jamf/PPPC-Utility on GitHub
3. License: MIT
4. README
5. Releases