Enable App Sandbox deliberately

App Sandbox is a containment system. A sandboxed app starts with almost no access: no reading the user’s files, no network, no camera. You then declare, capability by capability, exactly what the app needs.

Why accept that restriction? Damage control. If your app is ever compromised — through a malicious file it parses, a bad dependency, anything — the attacker gets your entitlements, not the whole Mac. The Mac App Store requires the sandbox, and it’s worth considering for direct distribution too.

Enable it in Xcode under Signing & Capabilities by adding the App Sandbox capability. Then add only what the app really needs. For our Notes app, that’s reading and writing files the user explicitly picks:

<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>

Notice the shape of that second entitlement. It doesn’t grant access to the whole disk. It grants access to files the user selects through an open or save panel. User intent is the permission.

Verify the built app actually carries the sandbox entitlement:

codesign -d --entitlements :- Notes.app

You can also open Activity Monitor, add the Sandbox column, and confirm the running app shows “Yes”.

Then test every real workflow with the release entitlement set: opening files, saving, networking, spawning helpers. Sandbox denials show up as failed operations in the app and as denial messages in Console.

When something is denied, resist the reflex to grant broader entitlements until the error goes away. A denial is information: which resource, which operation, and was there user intent behind it? If the feature genuinely needs the access, add the narrowest capability that unblocks it. If you can redesign the feature around a user-selected file instead, do that.