What gets checked
- Boolean capabilities (sandbox, network, hardened runtime) are real booleans, not strings
- Array keys such as keychain-access-groups and application-groups contain only strings
- Associated domains carry a service prefix (applinks:, webcredentials:) and no http://
- aps-environment is development or production; get-task-allow is flagged for release builds
- Hardened-runtime exceptions like disable-library-validation are flagged as security risks
- Sandbox permission keys without com.apple.security.app-sandbox enabled
Example: fix a type and a domain entry
These are fragments inside a plist dictionary. Both entries below trigger diagnostics:
<key>com.apple.security.app-sandbox</key>
<string>true</string>
<key>com.apple.developer.associated-domains</key>
<array><string>https://example.com</string></array>Use a Boolean for app-sandbox, and a service-prefixed domain for associated-domains:
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.developer.associated-domains</key>
<array><string>applinks:example.com</string></array>This fixes those two local checks. It does not verify the domain’s association file, account permissions, or the app’s signature. Apple’s associated domains setup
Compare with a signed app on macOS
codesign --display --entitlements - --xml "/path/to/App.app" > app.entitlementsOpen the exported file here. Keep build-setting variables in your Xcode source when appropriate; the signed output is useful for comparison. Check permitted capabilities with the provisioning profile viewer.