Provisioning & signing rejection: Profile, entitlements and capabilities
How the rejection usually reads: "Invalid Provisioning Profile" / "the provisioning profile has expired" / "the app contains entitlements that were not enabled"
Why it happens
Signing problems are rejected by the upload pipeline or by App Store Connect processing, not by a human, and the messages are terse. The usual causes: a development or ad-hoc profile in a build meant for the store (get-task-allow = true), an expired profile, a push entitlement without the matching background mode, or a capability entitlement the app never uses. All of it sits in embedded.mobileprovision inside the .ipa.
What can be checked before you submit
2 of RejectProof’s checks map to Provisioning & signing. Each one reads your .ipa — no upload — and reports the evidence with a fix.
- Provisioning profile expired
PB-23 · guideline provisioning · likely rejection
Create a new provisioning profile in Xcode, re-sign and rebuild. Expo/EAS: run eas build again — EAS renews credentials automatically.
- Push entitlement present but remote-notification background mode missing
PB-24 · guideline provisioning consistency · warning
If you receive push notifications you may need UIBackgroundModes → remote-notification in Info.plist (for background processing of pushes). Expo: app.json → expo.ios.infoPlist.UIBackgroundModes.
What a scan cannot tell you
Static checks read the build; they do not run it. Whether a reviewer likes your design, agrees with your content, or considers the app “sufficiently different” is their call. Fix the mechanical layer first so the human review is about your product, not about a missing plist key.