I just purchased the Apple Developer Paid Account on the 3rd of October to start development on an App and hasn't been able to use it even once
I’m having an iOS code-signing/provisioning issue where development/Ad Hoc builds complete successfully, but the app cannot be installed on my registered iPhone. The same issue occurs with builds produced through both Xcode and Expo EAS Build, so at this point I don’t think this is specific to EAS. When installing the app on the device, iOS shows: Unable to Install “Sencard” This app cannot be installed because its integrity could not be verified.
The device logs give a much more specific error. Environment
- Apple Developer account type: Individual
- Team ID: 26K9NDX728
- Main bundle identifier: com.sencard.mobile
- Widget extension bundle identifier: com.sencard.mobile.widgets
- App Group: group.com.sencard.mobile
- Physical iPhone registered in the Apple Developer portal
- Expo SDK: 57
- EAS distribution: Internal / Ad Hoc
- The same device is included in both provisioning profiles
- The issue also occurs when building/installing through Xcode
The application contains a WidgetKit extension, so there are two targets: Sencard com.sencard.mobile
ExpoWidgetsTarget com.sencard.mobile.widgets
Both targets use the same Apple Distribution certificate, with separate provisioning profiles as expected. Current signing configuration I completely reset the signing credentials and let EAS regenerate them. Both targets now use the same distribution certificate: Distribution Certificate Serial: 64FE74F9A8F0091A81671D9CDE9F7CDB
The main application has its own active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile
Provisioning Profile: 7D9CS7B97R
Status: active
Registered device: included
The widget extension has a separate active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile.widgets
Provisioning Profile: DY3D63UHPX
Status: active
Registered device: UDID: 00008130-************001C
EAS reports: All credentials are ready to build @sencard/sencard (com.sencard.mobile, com.sencard.mobile.widgets)
The build itself completes successfully. Device-side failure I captured the device system log while reproducing the installation failure. The important part appears to be Apple’s online provisioning authorization service rejecting the profile: online-auth-agent: The server returned: {"actions":["REJECT_PROFILE"],"authorized":false,...}
online-auth-agent: Permanently rejected profile
This is immediately followed by: installd(libmis.dylib): No online authorization (0x2)
installd(libmis.dylib): validation failed because of failing online authorization (-402620392)
Then MobileInstallation reports: The identity used to sign the executable is no longer valid.
and: Failed to verify code signature of .../Payload/Sencard.app
0xe8008018 (The identity used to sign the executable is no longer valid.)
Finally: Verification stage failed
and the installation fails. What seems particularly significant is that the device contacts the online authorization service successfully, but the response is explicitly: "actions":["REJECT_PROFILE"] "authorized":false
Things I have already tried I have done a fairly extensive clean reset of the signing configuration:
- Deleted the existing Ad Hoc provisioning profiles.
- Removed the existing distribution certificates from EAS.
- Revoked the corresponding distribution certificates in the Apple Developer portal.
- Created a completely new Apple Distribution certificate.
- Generated completely new Ad Hoc provisioning profiles.
- Verified that the provisioning profiles show as active in EAS.
- Verified that both profiles contain the physical iPhone being used for testing.
- Verified that both targets belong to Apple Team 26K9NDX728.
- Configured both the main app and widget extension to use the same distribution certificate.
- Created separate provisioning profiles for:
- com.sencard.mobile
- com.sencard.mobile.widgets
- Confirmed the App IDs still exist in the Developer portal.
- Confirmed the App Group exists and is assigned correctly.
- Confirmed the registered iPhone is present in the Developer portal.
- Rebuilt the app from scratch after regenerating all credentials.
- Confirmed that the EAS build succeeds.
- Reproduced the installation failure again on the physical device.
- Captured the iPhone system logs using idevicesyslog.
- Reproduced the problem with Xcode as well as EAS.
Initially, before resetting the credentials, I also encountered a build-time error similar to: Provisioning profile ... doesn't include signing certificate "iPhone Distribution: ... (26K9NDX728)"
I then deleted and regenerated the certificates/profiles and ensured both targets shared the same distribution certificate. That resolved the build failure — the application now builds successfully — but the resulting application is still rejected by iOS during installation with the REJECT_PROFILE / 0xe8008018 error above. What I’m trying to determine Is there some server-side state associated with my Apple Developer team/account that can cause a newly generated, apparently valid Ad Hoc provisioning profile to be returned as: REJECT_PROFILE
by Apple’s online authorization service? Specifically:
- What causes online-auth-agent to return REJECT_PROFILE for a newly created provisioning profile?
- Can an Apple Developer team/account get into a state where newly generated Development/Ad Hoc profiles are rejected by device-side online authorization?
- Is there any additional server-side reset or validation Apple Developer Support can perform for Team ID 26K9NDX728?
- Is error -402620392 associated with a specific provisioning/profile authorization condition?
- Is there anything else I should inspect in the .mobileprovision file or code signature to determine exactly why Apple is rejecting it?
- Since I can reproduce this with both Xcode and EAS, is there any known issue affecting Ad Hoc/Development profile authorization rather than the build tooling itself?
At this point I’m reluctant to keep generating new certificates and provisioning profiles because I’ve already done a complete signing reset and the newly generated profiles are still being rejected. Any guidance on what REJECT_PROFILE means internally, or what Apple Support should check on the Developer account/team, would be greatly appreciated.