Entitlements, capabilities, and extensions

An entitlement is a signed claim that lets an app request a protected capability. A capability is the broader Apple service or feature configured for an App ID and project. The provisioning profile must authorize what the final signature requests.

The three-way match

For a protected feature to work, these normally need to agree:

1. the capability configured for the developer team's App ID;
2. the entitlement embedded in the provisioning profile;
3. the entitlement applied to the signed app or extension.

Adding an entitlement to a plist does not grant it. Apple notes that capabilities depend on platform and program membership, and changing an App ID's capabilities invalidates affected profiles until they are regenerated (Apple Developer).

Common capability casualties

• Push notifications need a distribution certificate and the app's original bundle identifier. A development certificate registers the app for Apple's sandbox push environment, which the app's own servers do not send to.
• Associated Domains and universal links depend on both entitlements and website association files.
• App Groups and keychain groups depend on team-scoped identifiers.
• VPN and Network Extensions require authorized entitlements and compatible extension signing.
• iCloud containers belong to the original developer's configuration.
• Sign in with Apple and Game Center may not accept a rewritten app identity.
• In-app purchases belong to the original developer and usually fail.
• CarPlay and some media and notification entitlements need Apple's case-by-case approval. Bought certificates rarely carry them, so the app installs but those features stay off. Ask your provider for its entitlement list first.
• JIT normally needs get-task-allow, but that alone is not enough on current releases.

Apple publishes a live iOS capability matrix by membership type.

Extensions consume identities

Widgets, share extensions, notification service extensions, keyboards, watch apps, and other plug-ins are separate bundles nested inside the IPA. They need identifiers, profiles, entitlements, and signatures compatible with the parent app.

With a free Personal Team, extensions may consume more of the ten-App-ID budget. Removing extensions can make an app fit, but it also sacrifices the capabilities they provide. Use a signer's “remove extensions” control only when you accept that trade.

Why a signer can report success anyway

Many tools can cryptographically seal every bundle while preserving an entitlement/profile mismatch. Installation or runtime behavior then fails later. A post-signing audit should compare:

• every nested bundle identifier;
• every executable's entitlements;
• the profile application identifier;
• team identifier and keychain groups;
• device list and expiry;
• extension-to-parent relationships.

When one app fails but simple apps work with the same certificate, nested extensions and capabilities are high-value suspects.