Entitlements are the capabilities your iOS app declares it is allowed to use, App Groups, Keychain sharing, push, associated domains, HealthKit, and more. They are necessary for the features that need them, and a liability when you declare ones you do not use. Over-provisioned entitlements widen your attack surface, can raise questions in review because Apple expects you to use the capabilities you declare, and in the case of restricted entitlements require justification you will not have. Least privilege applies here just as it does to permissions. Here is what entitlements are and how to keep them to only what your app needs.
Short answer
Entitlements are the capabilities your iOS app is granted, declared in its entitlements file and tied to your App ID and provisioning profile, such as App Groups, Keychain sharing, push notifications, associated domains, and HealthKit. Per Apple's documentation, you should declare only the entitlements your features actually use, because over-provisioning expands your attack surface, can prompt review questions since Apple expects capabilities to match the app's purpose, and restricted entitlements require explicit approval. Audit your entitlements, remove any your app does not use, and request a sensitive entitlement only when a real feature depends on it. Least privilege applies to entitlements as much as to runtime permissions.
What you should know
- Entitlements are declared capabilities: what your app is allowed to use.
- They are tied to your App ID and profile: configured and provisioned.
- Least privilege applies: declare only what your features use.
- Over-provisioning is a liability: more attack surface and review scrutiny.
- Some entitlements are restricted: they require Apple's approval.
What are entitlements?
They are the capabilities your app declares, which the system and App Store enforce. An entitlement grants your app access to a specific capability, sharing data through an App Group, sharing Keychain items, receiving push notifications, handling associated domains for Universal Links, accessing HealthKit, running a network extension, and so on, and they live in your app's entitlements file, tied to your App ID and provisioning profile. The system uses them to allow or deny those capabilities at runtime, and App Review considers them when assessing your app. Entitlements are not inherently a problem; they are how features that need extra access are authorized. The issue arises when an app declares entitlements it does not actually use, often left over from experimentation or copied configuration, which grants capabilities with no purpose behind them.
Why is over-provisioning a problem?
Because every unused entitlement is risk and scrutiny with no benefit. The table lists the downsides.
| Downside | Why it matters |
|---|---|
| Larger attack surface | More capabilities available if the app is compromised |
| Review scrutiny | Apple expects declared capabilities to match the app's purpose |
| Restricted-entitlement friction | Some entitlements need approval you will not have for unused ones |
| Confusion and drift | Unused entitlements obscure what the app actually needs |
The core point is least privilege: an entitlement you declare but do not use gives an attacker more to work with if they compromise the app, and it can draw questions in review, since Apple expects the capabilities an app declares to correspond to functionality it provides. Restricted or sensitive entitlements compound this, because they require justification, and declaring one without a feature behind it is both pointless and a problem. Unused entitlements also make it harder to reason about what your app genuinely requires.
How do you request only what you need?
Audit your entitlements and keep them tied to real features. Review the entitlements your app declares and confirm each maps to a feature you actually ship, removing any that are left over from experiments, templates, or capabilities you turned on but never used. For sensitive or restricted entitlements, only request them when a genuine feature depends on them, and be ready to justify their use in review, since Apple expects declared capabilities to match the app's purpose. Keep your entitlements file and your App ID configuration in sync with what the app does, and revisit them when you remove a feature, so a capability does not linger after the feature that needed it is gone. The principle is the same as for permissions: declare the minimum set that supports your features, and nothing speculative.
What to watch out for
The first trap is leftover entitlements from experimentation or a copied configuration, which declare capabilities your app does not use; audit and remove them. The second is enabling a sensitive or restricted entitlement without a feature behind it, which adds risk and can draw review questions. The third is letting entitlements drift out of sync when you remove a feature, leaving a capability with no purpose. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the entitlements your app declares, so you can confirm they match your features and spot over-provisioned ones before you ship. Trimming the entitlements to what you use is the fix.
What to take away
- Entitlements are the capabilities your iOS app declares, like App Groups, Keychain sharing, push, and HealthKit, tied to your App ID and provisioning profile.
- Over-provisioning, declaring entitlements you do not use, widens your attack surface, can prompt review questions, and is pointless for restricted entitlements that need approval.
- Apply least privilege: declare only the entitlements your features use, request sensitive ones only when a feature depends on them, and remove leftovers.
- Use a pre-submission scan such as PTKD.com to surface the entitlements your app declares and confirm they match what it actually does.
