macOS 10.14 and later includes a system-wide privacy layer (often called TCC) that requires user consent before apps can access sensitive services such as the Microphone, Camera, Screen Capture, Desktop folder, and more.
Swif’s Apple Privacy Preferences Policy lets you centrally manage these permissions and pre‑approve or block access per app. This helps you:
Eliminate confusing pop‑ups for end users
Enforce consistent privacy and security rules across your fleet
Prevent users from tampering with MDM‑managed privacy decisions
Prerequisites
Before you create a PPPC policy in Swif, ensure:
Devices are running macOS 10.14 or later
Devices are supervised and enrolled via MDM (Swif Installer)
Swif Agent v1.XXX+ is installed and connected
What the Apple Privacy Preferences Policy does
When you deploy an Apple Privacy Preferences Policy (PPPC) with Swif:
The privacy decisions no longer appear under
System Preferences → Security & Privacy → Privacy (or System Settings → Privacy & Security on newer macOS versions)Instead, macOS stores and enforces them via the MDMOverrides database, which is reserved for MDM‑managed entries
End users cannot change these decisions in the UI; they only see prompts and entries for preferences they control themselves
You can use this policy to:
Pre‑approve access to protected resources (for example, allow your security tool to access
SystemPolicyAllFiles)Deny access permanently (for example, block Zoom from using the Camera and Microphone)
Fine‑tune access per app and per service using bundle IDs or paths
Supported services
The PPPC policy manages a dictionary of services, each representing a privacy-protected capability. In Swif, you select which services you want to configure and then add one or more app-specific rules to each.
The following services are available:
Accessibility – Controls whether an app can control the computer using the Accessibility subsystem.
Address Book – Access to contact information managed by Contacts.app.
Apple Events – Whether an app can send restricted Apple events (automation) to another process.
Bluetooth Always – Access to Bluetooth devices.
Calendar – Access to calendar data managed by Calendar.app.
Camera – Access to the system camera.
Important: In profiles, Camera can only be denied, not granted. You can use Swif to explicitly block Camera access for certain apps, but you cannot use PPPC to silently grant Camera access.
File Provider Presence – Allows a File Provider app to know when the user is using files it manages.
Listen Event – Whether an app can listen to CGEvents/HID events from all processes.
Important: This can only be denied, not granted, via profile.
Media Library – Access to Apple Music, playback activity, and the media library.
Microphone – Access to the system microphone.
Important: In profiles, Microphone can only be denied, not granted. You can block Microphone use for specified apps but not silently allow it.
Photos – Access to the photo library managed by Photos in
~/Pictures/*.photoslibrary.Post Event – Whether an app can send CGEvents into the system event stream (e.g. simulated input).
Reminders – Access to reminders managed by the Reminders app.
Screen Capture – Ability to capture (read) screen contents.
Important: This can only be denied, not granted, via profile.
Speech Recognition – Access to the system Speech Recognition service and the ability to send speech data to Apple.
System Policy All Files – Access to all protected files, including system‑admin files (often used for security / EDR tools).
System Policy App Bundles – Allows the app to update or delete other apps (macOS 13+).
System Policy App Data – Access to other apps’ application data directories.
System Policy Desktop Folder – Access to the user’s Desktop folder.
System Policy Documents Folder – Access to the user’s Documents folder.
System Policy Downloads Folder – Access to the user’s Downloads folder.
System Policy Network Volumes – Access to files on network volumes.
System Policy Removable Volumes – Access to removable drives.
System Policy SysAdmin Files – Access to certain system administration files.
In case of conflicts, macOS applies the most restrictive (deny) setting.
Key fields in a PPPC rule
For each app + service combination, Swif sends a payload that includes some or all of the following fields:
allowed (Boolean)
If true, access is granted and the user is never prompted
If false, access is denied and the user is never prompted
The user cannot change this in the UI when managed by MDM
Important rule:
Every payload must include either allowed or authorization, but not both.
authorization (String)
Alternative to allowed, with the following values:
Allow – Equivalent to
allowed: trueDeny – Equivalent to
allowed: false
For certain deny-only services (e.g. Camera, Microphone, Screen Capture, ListenEvent), an extended set is supported:
Deny – Denies access
AllowStandardUserToSetSystemService – Lets a standard (non‑admin) user configure that specific permission in the Privacy preferences for services that normally require admin rights (only valid for ListenEvent and ScreenCapture).
Again, you must choose exactly one of allowed or authorization in each entry.
codeRequirement (String, required)
A code requirement that uniquely identifies the app binary.
Swif requires this field.
You obtain it with:
codesign -display -r - {{APP_PATH}}
Replace {{APP_PATH}} with the full path to the .app bundle or binary (for example /Applications/Zoom.us.app).
identifier (String)
Identifies the target process. This can be:
The bundle ID of an app (e.g.
us.zoom.xos,com.apple.Safari)The installation path of a non‑bundled binary (e.g.
/usr/local/swifteam/swifteam)
identifierType (String)
Specifies how macOS should interpret the identifier:
"bundleID"for application bundles"path"for non‑bundled binaries
Helper tools embedded inside an app bundle automatically inherit the permissions of their parent app when you use the app’s bundle ID.
staticCode (Boolean, optional)
If true, macOS statically validates the code requirement
Useful when a process invalidates its dynamic code signature
Creating an Apple Privacy Preferences Policy in Swif
Go to Device Management → Policies and click Create New Policy.
Select Privacy Preferences Policy from the list and click Continue.
Enter a Policy Name (for example, “Apple Privacy Preferences Policy”) and an optional Policy Description.
Under Settings, you’ll see all available macOS privacy services (Accessibility, Calendar, Camera, Microphone, System Policy All Files, etc.).
For each service you want to manage, click the green “+ Add” button.
Configuring an app + service rule
In the Add Privacy Preference dialog:
Application
Enter the app’s bundle identifier (for example,
us.zoom.xos,com.apple.Safari)Or click Browse to upload a custom
.appbundle; Swif will extract the required identifiers.
Access Type
Depending on the service, you’ll see options such as:Allow – Pre‑approve access silently (no user prompt).
Allow with Standard Prompt – Let macOS show its standard “Allow / Don’t Allow” prompt.
Deny – Permanently block access.
Notes:
For Camera, Microphone, Screen Capture, and Listen Event, the policy can only deny these capabilities. You cannot use the profile to silently enable them.
If you choose Allow with Standard Prompt, macOS will still display its normal prompt first; the policy then governs subsequent behavior.
Minimum OS (optional)
Specify the earliest macOS version that this rule applies to (for example,
10.15).
Click Save to return to the Settings list.
Repeat for each service + app combination your organization requires.
Example: Deny Zoom from using Camera and Microphone
To block Zoom from using both the Camera and Microphone:
Service | Bundle ID | Access Type | Minimum OS |
Camera |
| Deny | 10.14 |
Microphone |
| Deny | 10.14 |
Steps:
Click + Add beside Camera
Application:
us.zoom.xosAccess Type: Deny
Minimum OS:
10.14
Click + Add beside Microphone
Application:
us.zoom.xosAccess Type: Deny
Minimum OS:
10.14
After deployment, Zoom will no longer be able to access the camera or microphone on managed devices.
Example: Disallow Google Chrome Access to User Files
Get code sign
codesign -display -r - /Applications/Google\ Chrome.app
result is ;
Executable=/Applications/Google Chrome.app/Contents/MacOS/Google Chrome designated => (identifier "com.google.Chrome" or identifier "com.google.Chrome.beta" or identifier "com.google.Chrome.dev" or identifier "com.google.Chrome.canary") and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = EQHXZ8M8AV
We need:
(identifier "com.google.Chrome" or identifier "com.google.Chrome.beta" or identifier "com.google.Chrome.dev" or identifier "com.google.Chrome.canary") and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = EQHXZ8M8AV
Get identifier
mdls /Applications/Google\ Chrome.app | grep kMDItemCFBundleIdentifier
Result is:
kMDItemCFBundleIdentifier = "com.google.Chrome"
We need:
com.google.Chrome
Steps:
Click + Add beside System Policy All Files
Allowed: False
Authorization: Deny
Code Requirement:
(identifier....Identifier:
com.google.ChromeIdentifier Type:
bundleID
After deployment, the Chrome browser will no longer be able to access user files.
Deploying the policy
After adding all required services and app rules, click Continue.
Select the Devices or Device Groups that should receive this policy.
Click Review, then Create Policy.
Devices will receive the new PPPC profile on their next check‑in. Once applied, apps will be allowed or blocked according to your rules, with no additional user interaction for MDM‑managed entries.
Verifying PPPC rules via MDMOverrides.plist
Because MDM‑managed PPPC entries no longer appear in the macOS Privacy UI, the best way to confirm deployment is to inspect the MDMOverrides database.
On the target Mac, open Terminal.
Grant Terminal Full Disk Access:
System Settings → Privacy & Security → Full Disk Access
Or System Preferences → Security & Privacy → Privacy → Full Disk Access on older macOS versions.
Without Full Disk Access (or the broader
SystemPolicyAllFilesentitlement), reading the overrides file will fail with:Error Reading File: /Library/Application Support/com.apple.TCC/MDMOverrides.plistRun:
sudo /usr/libexec/PlistBuddy -c "print" "/Library/Application Support/com.apple.TCC/MDMOverrides.plist"
This command prints all PPPC entries currently enforced by MDM, including those from your Swif Apple Privacy Preferences Policy.
Why it’s hidden in System Preferences
macOS stores user‑driven privacy decisions in TCC databases (
/Library/Application Support/com.apple.TCC/TCC.dband~/Library/Application Support/com.apple.TCC/TCC.db).MDM‑managed decisions are stored separately in
MDMOverrides.plistand are not shown in the GUI, so end users cannot override them.
What you see under Security & Privacy → Privacy is only what users decided in response to prompts, not what MDM pushed.
Troubleshooting
Policy not applying?
Confirm the device is supervised and properly enrolled.
Verify that the bundle identifier you configured exactly matches the app’s
Info.plist.On the Mac, check System Settings → Privacy & Security → Profiles (or Profiles in older System Preferences) to ensure the Swif PPPC profile is installed.
Confirm the device has recently checked in with Swif.
Prompt still appearing?
If you used Allow with Standard Prompt, macOS will always show the initial prompt.
To completely eliminate prompts (for allowed services), switch to Allow instead.
Managing Apple’s own apps vs custom apps
Native apps like Calendar and Photos are managed using their system bundle IDs (for example,
com.apple.Calendar).For in‑house or third‑party apps, use their bundle IDs or path plus a valid
codeRequirementfrom:codesign -display -r - {{APP_PATH}}
By configuring your Apple Privacy Preferences Policy in Swif, you centralize macOS privacy decisions, reduce end‑user confusion, and ensure your security tools have the access they need—while keeping sensitive permissions locked down.