Apple's declarative permission system. An entitlements file lists the system capabilities (push, App Groups, iCloud, HealthKit, Sign in with Apple, etc.) your app is allowed to use, and is embedded into the code signature.
Entitlements.plistCapabilitiesApp capabilities
Entitlements are Apple's mechanism for declaring which system capabilities an app is allowed to use. They live in an .entitlements XML plist next to your project, get baked into the code signature at build time, and have to be granted by a matching provisioning profile or the OS will refuse to enable them at runtime.
Capabilities that go through entitlements
Push notifications (aps-environment).
App Groups (com.apple.security.application-groups).
iCloud containers and CloudKit (com.apple.developer.icloud-container-identifiers).
Sign in with Apple (com.apple.developer.applesignin).
Associated Domains for universal links (com.apple.developer.associated-domains).
Network Extensions and Hotspot Helper.
Mac sandbox switches (com.apple.security.* family).
How they tie to provisioning
An entitlement in your .entitlements file only takes effect if the provisioning profile that signed the build authorizes it. Enabling push in Xcode adds the entitlement to the local file, but you also have to enable push on the App ID in the Apple Developer portal and regenerate every provisioning profile that uses the App ID. Forgetting that last step is the most common cause of 'app installs but push tokens never arrive' bugs, and when the device refuses the install outright you get The executable was signed with invalid entitlements.
Three flavors that confuse people
Development
Push uses aps-environment: development and the sandbox APNs server. Signed by an Apple Development certificate.
Distribution
Push uses aps-environment: production and the production APNs server. Signed by an Apple Distribution certificate.
Capability vs entitlement
A capability is the toggle in the Apple Developer portal and Xcode UI. The entitlement is the resulting plist key and value. The portal-side capability has to match the project-side entitlement.
FAQ
Common questions about Entitlements
Xcode creates <TargetName>.entitlements in the project folder the first time you add a capability in the Signing and Capabilities tab, and points the CODE_SIGN_ENTITLEMENTS build setting at it. If the file seems missing, check that build setting; the file only exists once at least one capability needs it.
Run codesign -d --entitlements - MyApp.app (or the .ipa's extracted .app). It prints the entitlements actually baked into the signature, which is what the OS enforces. Comparing that output with what the provisioning profile grants is the fastest way to debug a capability that will not turn on.
Because the provisioning profile that signed the build does not grant it. The usual sequence of the bug: the capability was enabled in Xcode but not on the App ID in the portal, or it was enabled on the App ID but the profiles were never regenerated afterward. Regenerate the profile and rebuild.
No. Info.plist usage strings (camera, microphone, location) drive the user-facing permission prompts at runtime. Entitlements are granted by Apple at signing time and never prompt the user. A capability like push or App Groups goes through entitlements; access to the camera goes through Info.plist and a runtime prompt.
HexSign tracks every Apple certificate and provisioning profile and alerts you ahead of expiry. The Free plan covers tracking and alerts. Paid plans renew them for you.
