Bundle ID and capabilities App Review checklist

Inventory every enabled capability

List Sign in with Apple, Associated Domains, Push Notifications, App Groups, iCloud, HealthKit, HomeKit, Wallet, Apple Pay, Network Extensions, Background Modes, Keychain Sharing, and any other enabled entitlement.

Mark whether each capability is used by the main app, an extension, a widget, an App Clip, watchOS target, or a hidden server-controlled feature.

Map capabilities to reviewable features

• Each capability has a user-facing purpose or a platform requirement.
• Unused capabilities are removed before submission unless a documented target needs them.
• Privacy labels and permission prompts reflect the data exposed by the capability.
• Provisioning profiles and bundle identifiers match the submitted binary.
• Reviewer notes explain gated, hardware-dependent, or account-dependent capability paths.

Treat sensitive capabilities as policy evidence

Capabilities that touch identity, health, home, payments, network traffic, location, notifications, or shared containers can change how the app is reviewed. A build with stale entitlements may raise questions even if the visible UI looks simple.

AppReviewReady interpretation: entitlement cleanup is part of review readiness. The safest capability is the one that clearly supports a tested user task.

Run build and provisioning checks

1. Compare App Store Connect app record, bundle ID, provisioning profile, and exported archive.
2. Install the final build on a clean device and trigger each capability path.
3. Test signed-out, denied-permission, unavailable-region, no-network, and removed-account states.
4. Check extension targets do not inherit access they do not need.
5. Retest after account transfer, team migration, or target rename.

Capability ledger

The ledger helps engineering, privacy, and release owners discuss the same configuration instead of chasing Xcode, account portal, and App Store Connect separately.

After launch, revisit the ledger when adding SDKs or extensions. Capabilities often accumulate during experiments and remain enabled long after the experiment is removed.

For inherited codebases, treat unknown capabilities as suspect until proven. A previous contractor may have enabled Push Notifications, iCloud, App Groups, or Associated Domains for an experiment that no longer exists.

When capabilities differ across targets, test target boundaries explicitly. A widget, extension, or App Clip should not read shared secrets or containers simply because the main app needs them.

If a capability is required only for a future release, leave it out until the feature is reviewable. Premature entitlements create policy questions without giving the reviewer a user-facing reason.

When a capability requires Apple approval or special entitlement history, keep the approval context with the release record. A new app target, transfer, or bundle ID change can break assumptions that were true for the old identifier.

Capability ledger:
Capability: [name]
Target: [app/extension]
User-facing purpose: [feature]
Data touched: [none/list]
Reviewer path: [steps]
Privacy/support impact: [notes]
Remove if unused: [yes/no]