CI signing and provisioning App Review checklist

Inventory signing inputs

Record certificates, provisioning profiles, bundle IDs, entitlements, team IDs, targets, build configuration, export method, and CI secret source. A mismatch in any one can produce a build that differs from review expectations.

Signing inputs should be owned by release operations, not scattered across developer laptops and old CI variables.

Prove CI and App Store parity

• CI archive uses the same scheme and configuration as release.
• Entitlements match App ID capabilities and product features.
• Profiles and certificates are current and scoped correctly.
• The uploaded artifact is the same artifact that passed tests.
• Manual local archives are treated as exceptions with evidence.

Prevent review-only signing surprises

A build can pass TestFlight and still fail a capability path if entitlements, associated domains, keychain groups, or app groups differ between targets. Test signed release artifacts on device.

AppReviewReady interpretation: signing is user-facing when it controls login, payments, notifications, extensions, and shared data.

Operate signing safely

1. Rotate certificates with rehearsal builds.
2. Document who can change CI secrets.
3. Audit profiles after adding targets or capabilities.
4. Keep emergency signing recovery instructions.
5. Review signing changes after app transfer or team migration.

Signing provenance record

The record gives engineering and release owners a common proof trail.

After launch, connect signing incidents to capability failures. Many production access issues begin as quiet provisioning drift.

Validate the signed artifact, not only the project settings. Install the archived build on a clean device and exercise the capabilities that depend on entitlements: Sign in with Apple, push notifications, app groups, associated domains, HealthKit, Wallet, background modes, extensions, and in-app purchases.

Keep emergency recovery realistic. If only one person can replace a certificate, update a profile, or change a CI secret, the recovery plan is incomplete. Release operations should know which access path is available during travel, off-hours incidents, and account transitions.

Treat signing changes as review-relevant even when the UI is unchanged. A new app group, associated domain, merchant capability, or notification entitlement can alter runtime behavior and reviewer access. The submitted build should prove those capabilities work in release configuration.

Avoid mixing signing repair with unrelated release changes. When the goal is to recover a broken certificate or profile, keep code, metadata, pricing, and privacy edits out of the same submission unless they are necessary for the fix.

For apps with extensions, compare entitlements target by target. A correct main app profile does not prove that widgets, notification extensions, share extensions, or watch targets can read the same app group, keychain group, or associated domain.

Signing record:
Build: [number]
CI workflow: [name]
Certificate/profile: [ids]
Entitlements checked: [yes/no]
Artifact uploaded: [id]
Secret owner: [team]
Recovery plan: [link]