Hi everyone,
I’m having trouble getting remote push notifications working on iOS for a production Flutter app, and it looks like it’s related to the provisioning profile / entitlements used during signing.
Context
Platform: Flutter
Push provider: OneSignal (backend is Supabase; Android push works fine)
CI: Codemagic
Target: iOS TestFlight / App Store builds
I’m on Windows, so I cannot open Xcode locally. All iOS builds happen via Codemagic.
Capabilities / entitlements
In the Apple Developer portal, my App ID for com.zachspizza.app has:
Push Notifications capability enabled
A separate Broadcast capability is listed but currently not checked.
In my repo,
ios/Runner/Runner.entitlements
contains:
xml
aps-environment
production
So the project is clearly requesting the push entitlement.
Codemagic signing setup
For my App Store workflow (ios_appstore_release in
codemagic.yaml
):
I use a combination of manual and automatic signing:
Environment variables can provide:
P12_BASE64 + P12_PASSWORD (distribution certificate)
MOBILEPROVISION_BASE64 (a .mobileprovision file)
A script in the workflow:
Creates a temporary keychain.
Imports the .p12 and installs the .mobileprovision into ~/Library/MobileDevice/Provisioning Profiles.
For the final export, I generate an exportOptions.plist that does:
If a profile name/UUID is provided via env (PROV_PROFILE_SPEC, PROV_PROFILE_UUID, PROVISIONING_PROFILE_SPECIFIER, PROVISIONING_PROFILE):
xml
signingStylemanual
provisioningProfiles
com.zachspizza.app[profile name or UUID]
Otherwise, it falls back to:
xml
signingStyleautomatic
After archiving and exporting, my script runs:
bash
codesign -d --entitlements :- "$ARCHIVE_PATH/Products/Applications/Runner.app"
...
and again on the signed Runner.app inside the exported IPA
codesign -d --entitlements :- "$SIGNED_APP"
In both cases, the effective entitlements output does not show aps-environment, even though:
The App ID has push enabled.
Runner.entitlements
includes aps-environment = production.
Observed behavior
iOS devices (TestFlight build) do not receive remote push notifications at all.
Android devices receive notifications as expected with the same backend payloads.
OneSignal configuration and backend are verified; this appears to be an APNs / signing / entitlements problem.
The Codemagic logs strongly suggest that the provisioning profile being used for signing does not carry aps-environment.
Questions
Under what conditions would a distribution provisioning profile (for an App ID with Push Notifications enabled) result in a signed app without aps-environment, even when:
The entitlements file in the project includes aps-environment, and
The App ID in the Developer portal has Push Notifications enabled?
Does using a CI flow like the above (custom .p12 + .mobileprovision installed via script, exportOptions with signingStyle=manual) increase the chances of:
Xcode ignoring the requested entitlements, or
Selecting a provisioning profile variant that does not include the push entitlement?
Is there a recommended way, from the Apple side, to verify that a given .mobileprovision (the one I’m base64-encoding and installing in CI) definitely includes the aps-environment entitlement for my bundle ID?
i.e., a canonical method to inspect the profile and confirm that APNs is included before using it in CI?
Are there any known edge cases where:
The project entitlements include aps-environment,
The App ID has Push Notifications enabled,
But the final signed app still has no aps-environment, due to profile mismatch or signing configuration?
Given that I’m on Windows and can’t open Xcode to manage signing directly, I’d really appreciate guidance on how to ensure that the correct push-enabled provisioning profile is being used in this CI/manual-signing setup, and how to debug why aps-environment is being stripped or not applied.
CodeMagic Signing/Export Step:
Signing / entitlements output from Codemagic
Dumping effective entitlements for Runner.app in archive...
/Users/builder/clone/build/ios/archive/Runner.xcarchive/Products/Applications/Runner.app: code object is not signed at all
Failed to dump entitlements
Exporting IPA with exportOptions.plist...
2025-11-20 22:25:00.111 xcodebuild[4627:42054] [MT] IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path "/var/folders/w2/rrf5p87d1bbfyphxc7jdnyvh0000gn/T/Runner_2025-11-20_22-25-00.110.xcdistributionlogs".
2025-11-20 22:25:00.222 xcodebuild[4627:42054] [MT] IDEDistribution: Command line name "app-store" is deprecated. Use "app-store-connect" instead.
▸ Export Succeeded
Dumping entitlements from signed Runner.app inside exported IPA...
Executable=/private/var/folders/w2/rrf5p87d1bbfyphxc7jdnyvh0000gn/T/tmp.LHkTK7Zar0/Payload/Runner.app/Runner
warning: Specifying ':' in the path is deprecated and will not work in a future release
application-identifier.com.zachspizza.app
beta-reports-active
com.apple.developer.team-identifier
get-task-allow
As you can see, the signed app’s entitlements do not contain aps-environment at all, even though
Runner.entitlements
in the project has aps-environmentproduction and the App ID has Push Notifications enabled.
Thanks in advance for any help and pointers.
Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hello Colleagues,
We have been seeing a delay in our Apple notarization submission that hangs for hours "in progress" without completing:
This issue has been occurring since Friday, October 17th.
We have also checked the Apple System Status page and there is no indication of any outage for Apple notarization.
Hi,
I am developing a iOS app with Packet Tunnel Provider Network Extension. I manage signing manually. I created a distribution provisioning profile. Then when I archive and click "validate" I get this error:
Your application bundle's signature contains code signing entitlements that are not supported on iOS. Specifically, value 'url-filter-provider' for key 'com.apple.developer.networking.networkextension'
So I run security cms -D -i profiles/vpn_distribution.mobileprovision and I see there
<key>Entitlements</key>
<dict>
<key>com.apple.developer.networking.networkextension</key>
<array>
<string>app-proxy-provider</string>
<string>content-filter-provider</string>
<string>packet-tunnel-provider</string>
<string>dns-proxy</string>
<string>dns-settings</string>
<string>relay</string>
<string>url-filter-provider</string>
<string>hotspot-provider</string>
</array>
Where are those coming from. My entitlement file has
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.developer.networking.networkextension</key>
<array>
<string>packet-tunnel-provider</string>
</array>
<key>com.apple.security.application-groups</key>
<array>
<string>group.my-app-group</string>
</array>
</dict>
</plist>
What is happening here. How can I get a provisioning profile that only has the entitlements that I actually need?
The problem is the following:
We create a keychain item called NotaryTool (There are multiple accounts that use Notary tool and we created it for all of them )
This is created in the following way:
$ xcrun notarytool store-credentials
This process stores your credentials securely in the Keychain. You reference these credentials later using a profile name.
Profile name:
NotaryTool
We recommend using App Store Connect API keys for authentication. If you'd like to authenticate with an Apple ID and app-specific password instead, leave this unspecified.
Path to App Store Connect API private key:
//AuthKey_ABCDEFGH.p8
App Store Connect API Key ID:
<ABCDEFGH>
App Store Connect API Issuer ID:
ABCDEF-ABCD-1234-1234-1234567
Validating your credentials...
Success. Credentials validated.
Credentials saved to Keychain.
To use them, specify `--keychain-profile "NotaryTool"`
The key is downloaded from Apple and some other IDs are provided alongside.
These should remain in the keychain for as long as the user process is running (just like any other process)
A few runs are successful when we run with the profile that was created.
After a few runs we start seeing a failure.
Now we are seeing the following issue where the keychain item just vanishes:
Error: No Keychain password item found for profile: NotaryTool\n\nRun 'notarytool store-credentials' to create another credential profile.\nError during the not process\nTue Aug 26 06:02:09 2025 Notarization failed with notarytool with exit code 17664: \nTue Aug 26 06:02:09 2025 could not upload for notarization!!!
Topic:
Code Signing
SubTopic:
Notarization
I added a new device and it's not recognizing the device model. This causes a message saying "Unable to verify" when signing an app. Has anyone else encountered this issue? This only happens with this one device, not others.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Hey, when I try to launch my app it prompts me with a "Apple could not verify" popup. The thing is the app has been signed and stapled.
xcrun stapler validate .app for my app returns "The validate action worked!"
If I also run syspolicy_check distribution .app it returns: "App passed all pre-distribution checks and is ready for distribution"
Any idea?
My notarization submission been "In Progress" status for over 30 minutes now. I thought this process should be much faster.
I've developed a Mac app distributed through the App Store that uses NSAppleScript to control Spotify and Apple Music. I'm experiencing inconsistent behavior with automation permission prompts that's affecting user experience.
Expected Behavior:
When my app first attempts to send Apple Events to Spotify or Apple Music, macOS should display the automation permission prompt, and upon user approval, the app should appear in System Preferences > Security & Privacy > Privacy > Automation.
Actual Behavior:
Initial permission prompts work correctly when both apps are actively used after my app download. If a user hasn't launched Spotify/Apple Music for an extended period, the permission prompt fails to appear when they later open the music app. The music app doesn't appear in the Automation privacy pane too. Once this happens, permission prompts never trigger again for that app
Steps to Reproduce:
Fresh install of my app
Don't use Spotify for several days/weeks
Launch Spotify
Trigger Apple Events from my app to Spotify
No permission prompt appears, app doesn't show in Automation settings
If you're using Apple Music during this time it runs without any problems.
Troubleshooting Attempted:
Used tccutil reset AppleEvents [bundle-identifier] - no effect
Verified target apps are fully launched before sending Apple Events
Tried different AppleScript commands to trigger permissions
Problem occurs inconsistently across different Macs
Technical Details:
macOS 13+ support
Using standard NSAppleScript with simple commands like "tell application 'Spotify' to playpause"
App Store distribution (no private APIs)
Issue affects both Spotify and Apple Music but seems more prevalent with Apple Music
Questions:
Is there a reliable way to programmatically trigger the automation permission prompt?
Are there timing dependencies for when macOS decides to show permission prompts?
Could app priority/usage patterns affect permission prompt behavior?
I use MediaManager to run the functions and initialize it on AppDidFinishLaunching method and start monitoring there.
Any insights or workarounds would be greatly appreciated. This inconsistency is affecting user onboarding and app functionality.
Hi Developer Community,
I'm encountering persistent code signing failures on macOS Sonoma 15.3 with a valid Developer ID Application certificate. The error occurs consistently across multiple certificate regenerations and various troubleshooting approaches.
Environment
macOS Version: Sonoma 15.3
Developer Account Type: Developer ID
Certificate Type: Developer ID Application
Certificate Details:
Developer ID Application certificate valid until 2027
Using SHA-256 with RSA Encryption
Certificate shows as valid in Keychain Access with associated private key
Error Message
Warning: unable to build chain to self-signed root for signer "Developer ID Application: [my certificate]"
[filename]: errSecInternalComponent
Steps to Reproduce
Install certificate chain in order:
Apple Root CA (System keychain)
Apple WWDR CA (System keychain)
Developer ID CA (System keychain)
Developer ID Application certificate (Login keychain)
Verify certificate installation:
security find-identity -v -p codesigning
Result shows valid identity.
Attempt code signing with any binary:
codesign -s "Developer ID Application: [my certificate]" -f --timestamp --options runtime [filename]
Results in errSecInternalComponent error
Troubleshooting Already Attempted
Regenerated Developer ID Application certificate multiple times from Developer Portal
Completely removed and reinstalled entire certificate chain
Verified trust settings on all certificates (set to "Always Trust" for code signing)
Tried multiple codesign command variations including --no-strict flag
Verified keychain integrity
Installed latest Apple CA certificates from apple.com/certificateauthority
Verified certificate chain is properly recognized by security verify-cert
Additional Information
All certificates show as valid in Keychain Access
Private key is properly associated with Developer ID Application certificate
Trust settings are correctly configured for all certificates in the chain
Problem persists after clean certificate installations
Error occurs with any binary I try to sign
Has anyone else encountered this issue on Sonoma 15.3? Any suggestions for resolving this system-level certificate trust chain issue would be greatly appreciated.
Thanks in advance!
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
For years, I've been shipping my apps with a Perl script that now invokes notarytool to get the notarization, using this command
/usr/bin/xcrun notarytool submit --apple-id jerry@sheepsystems.com --keychain-profile SSYShipProduct --team-id 4MAMECY9VS --output-format json /Users/jk/blah/blah/MyApp.zip --wait
I used this script with this command several times during September 2024 to ship my apps, and it worked. But now, the above command fails with:
Error: No Keychain password item found for profile: SSYShipProduct Run 'notarytool store-credentials' to create another credential profile.
Of course, I am now running later versions of macOS beta and Xcode than I was in September. Does anyone know the problem? Screenshots from Terminal and Keychain Access are attached. Thank you.
Topic:
Code Signing
SubTopic:
Notarization
There is something wrong with my keychain. Can someone point me in the right direction?
codesign --force --sign "Developer ID Application: Denis Putnam (2368694WQF)" --options runtime "/Users/denisputnam/git/expense_tracker/dist/ExpenseTracker.app"
/Users/denisputnam/git/expense_tracker/dist/ExpenseTracker.app: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Developer ID Application: Denis Putnam (2368694WQF)"
/Users/denisputnam/git/expense_tracker/dist/ExpenseTracker.app: errSecInternalComponent
Deniss-MacBook-Pro:expense_tracker denisputnam$
security find-certificate -c "Developer ID Certification Authority" -p /Library/Keychains/System.keychain | openssl x509 -noout -dates
notBefore=Sep 22 18:55:10 2021 GMT
notAfter=Sep 17 00:00:00 2031 GMT
Deniss-MacBook-Pro:expense_tracker denisputnam$
This is my .entitlements file:
Code signing:
codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s "Developer ID Application: XXX. (XXXXXXX)" ./UES.app
I work fine in the macOS 13.x system, but the "killed" error occurs in macOS11.x. The system log is displayed as follows:
(If codesign remove the --entitlements ./UES.entitlements, it will operate normally)
2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050
2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES:
2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file "UES"
2025-04-21 13:58:27.040720+0800 0xd5bc0 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 29354, /Applications/UES.app/Contents/MacOS/UES
2025-04-21 13:58:27.045974+0800 0xd58be Error 0x0 66405 0 CoreServicesUIAgent: [com.apple.launchservices:uiagent] handle LS launch error: {\n Action = oapp;\n AppMimimumSystemVersion = "10.13";\n AppPath = "/Applications/UES.app";\n ErrorCode = "-10826";\n}
2025-04-21 13:58:39.121619+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050
2025-04-21 13:58:39.121832+0800 0xd5e0f Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES:
2025-04-21 13:58:39.121861+0800 0xd5e0f Default 0x0 0 0 kernel: proc 29415: load code signature error 4 for file "UES"
2025-04-21 13:58:39.122571+0800 0xd5e10 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 29415, /Applications/UES.app/Contents/MacOS/UES
2025-04-21 13:58:46.297915+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050
2025-04-21 13:58:46.298031+0800 0xd5f85 Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES:
2025-04-21 13:58:46.298072+0800 0xd5f85 Default 0x0 0 0 kernel: proc 29485: load code signature error 4 for file "UES"
2025-04-21 13:58:46.300248+0800 0xd5f86 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 29485, /Applications/UES.app/Contents/MacOS/UES
What causes the pattern to be narrow?
I have built my application for arm and x64 so I have two files called DeepSkyStacker.app in different directories.
I have followed the instructions to notarise the arm version of the app, but an concerned about what I should do to notarise the other one - do I just zip that up and then run:
xcrun notarytool submit "DeepSkyStacker.zip" --keychain-profile "Notary Profile for DeepSkyStacker" --wait
xcrun stapler staple DeepSkyStacker.app
again or will that mess everything up?
Related to that can I use the Notary Profile I created for DeepSkyStacker to notarise other apps that are part of the same product (DeepSkyStackerLive and DeepSkyStackerCL)??
Thanks
David
Topic:
Code Signing
SubTopic:
Notarization
Hello, I have this simulator made in Unity that I want to distribute as Standalone. It consists of launcher which, when users download it, downloads the game.
I've built the launcher, got Developer ID Application certificate, added entitlements from: https://docs.unity3d.com/Manual/macoscodesigning.html#signing-identity
I've signed the .app of the launcher and 2 dlls chatgpt recommended to sign, zipped it, notarized .zip successfully, stapled to .app and put it on Google Drive to test. I got my other MacBook Pro, downloaded the zip, tried to open it.
It did open, but there is a black loading screen saying "0% progress, 0B/0B" indicating that it isn't downloading anything - no network calling. When checked using command
xattr -l path/to/file.app
I get the following output:
com.apple.macl: @?????I???|????
com.apple.quarantine: 0083;67bf1a22;Safari;69764595-CA94-44D2-B679-A69DC4669382
There are some specifics I think are also important to mention.
I tried to code-sign it, notarize it and staple it using only Terminal and I'd like to keep it that way because I am very unfamiliar with Mac so I've avoided using Xcode as much as possible
I really want to avoid putting the simulator up on the App Store, so I must have Standalone solution and Standalone solution only
I believe that there might be problem with needing right entitlements, but I don't know how to check which one's are needed for users to avoid using "xattr" command in terminal to allow the launcher to run because of GateKeeper
I've been banging my head against the wall with this problem for over a month and I don't see the light at the end of the tunnel.
This is .entitlements file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.developer.endpoint-security.client</key>
<true/>
</dict>
</plist>
Code signing:
codesign --sign -vvv --timestamp --options=runtime --force --entitlements ./UES.entitlements -s "Developer ID Application: XXXX Ltd. (XXXXXX)" ./UES.app
When I run it on macOS 13.x, it works fine. If I run the system on macOS 11.x, it reports a "killed" error
(if codesign remove --entitlements ./UES.entitlements, Then the startup will not report an error, but the endpoint security rights cannot be used)
System log:
2025-04-21 13:58:27.039638+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050
2025-04-21 13:58:27.039762+0800 0xd5bbf Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES:
2025-04-21 13:58:27.039815+0800 0xd5bbf Default 0x0 0 0 kernel: proc 29354: load code signature error 4 for file "UES"
2025-04-21 13:58:27.040720+0800 0xd5bc0 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 29354, /Applications/UES.app/Contents/MacOS/UES
2025-04-21 13:58:27.045974+0800 0xd58be Error 0x0 66405 0 CoreServicesUIAgent: [com.apple.launchservices:uiagent] handle LS launch error: {\n Action = oapp;\n AppMimimumSystemVersion = "10.13";\n AppPath = "/Applications/UES.app";\n ErrorCode = "-10826";\n}
2025-04-21 13:58:39.121619+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050
2025-04-21 13:58:39.121832+0800 0xd5e0f Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES:
2025-04-21 13:58:39.121861+0800 0xd5e0f Default 0x0 0 0 kernel: proc 29415: load code signature error 4 for file "UES"
2025-04-21 13:58:39.122571+0800 0xd5e10 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 29415, /Applications/UES.app/Contents/MacOS/UES
2025-04-21 13:58:46.297915+0800 0xd5941 Default 0x0 149 0 amfid: /Applications/UES.app/Contents/MacOS/UES signature not valid: -67050
2025-04-21 13:58:46.298031+0800 0xd5f85 Default 0x0 0 0 kernel: mac_vnode_check_signature: /Applications/UES.app/Contents/MacOS/UES: code signature validation failed fatally: When validating /Applications/UES.app/Contents/MacOS/UES:
2025-04-21 13:58:46.298072+0800 0xd5f85 Default 0x0 0 0 kernel: proc 29485: load code signature error 4 for file "UES"
2025-04-21 13:58:46.300248+0800 0xd5f86 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 29485, /Applications/UES.app/Contents/MacOS/UES
May I ask what the reason is?
I’m having trouble with the notary step of our electron app. It sometimes says “In progress” for days on end, where other times, it only takes 15-20 minutes.
For the last few weeks, I’ve noticed that it will take longer than the 20 minutes if our app was using a not latest version of the electron module -- https://www.npmjs.com/package/electron. I would then update our codebase to build using the latest version, and then try to sign and notarize the app again, and it would work till a new version was released.
This was the first time that that process didn’t work. Everything is on latest, and we’re still getting stuck “in progress” for days on end. We have been signing and Notarizing this app for years now, so it's not the first time we're trying to do this process
To make matters stranger, I have two branches of the same exact code base – same dependencies, same source code, same everything – there is no difference. One sign and notarize works 100% of the time where the other one hasn’t worked yet.
Any ideas would be helpful. I'm not really sure where to begin to debug this.
Thanks!
Hi everyone,
I applied for CarPlay Entitlements on [Date 4. 26, 2025] using.
(*CarPlay Entitlements Case-ID : 13045151)
I haven't received any updates or responses regarding my application yet. It's been 7 days since the application.
My service requires CarPlay integration with a Black Box device. The primary purpose of this integration is to allow users to configure device settings through CarPlay.
Furthermore, we plan to utilize the "Communication" category of Entitlements to notify users of parking incidents detected by the Black Box device while parked. This functionality is crucial for alerting drivers to potential issues affecting their vehicles.
Could anyone share their experience with the typical turnaround time for CarPlay Entitlements, especially for applications involving device integration and the "Communication" category? Is this delay normal?
Is there any way to check the application status or contact the appropriate team to inquire about its progress?
Thank you for any insights or advice you can provide!
Sincerely,
I use the 'notarytool' to notarize applications and .pkg installers for Developer ID distribution. When using the notary tool with a fresh Apple Developer account, the notarization process remains stuck in the 'In progress' state. However, if I try the same app with an older developer account (one that has notarized at least one app in the past), the notarization works.
All agreements are accepted in developer portal and Appstore Connect.
Hi,
Out app is approved on app store, however we want to distribute outside apps tore as well. But notarization always fails with error:
Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.",
"statusCode": 7000,
Any help to address this issue is highly appreciated.
In an expo managed project which utilizes custom expo plugins, we're having trouble getting the keychain-access-groups entitlement inserted to our provisioningprofile for signing.
The provisioning profile we download from apple dev portal contains:
<key>keychain-access-groups</key>
<array>
<string>56APMZ7FZY.*</string>
<string>com.apple.token</string>
</array>
and this is not recognized by xcode for signing; an error is thrown:
Provisioning profile "ccpp" doesn't include the com.apple.developer.keychain-access-groups entitlement.
A matching error is thrown during EAS build.
So we need to find a way to modify the ccpp.mobileprovision locally and then sign the build using the modified ccpp.mobileprovision.
Or, we need guidance on the proper way to resolve this situation.
Questions:
why does the downloaded mobileprovision file have the keychain-access-groups key, and not com.apple.developer.keychain-access-groups? Both Xcode and EAS appear to demand the latter keyname.
when I use expo prebuild, I am able to see the following in the .entitlements file:
<key>com.apple.developer.keychain-access-groups</key>
<array>
<string>$(AppIdentifierPrefix)com.myapp</string>
</array>
I am adding this entitlement using a custom expo plugin. However, the mobileprovision file downloaded from apple developer portal has no knowledge of this setting which is only applied through expo prebuild.
So what I am left with at the end is an entitlements file generated by my expo prebuild which has the correct setting, and a provisioningprofile downloaded from dev portal with an incorrect setting, and I don't know how to mend the downloaded provisioningprofile (incorrect setting) with my local entitlements file (correct setting).
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Entitlements
Provisioning Profiles
Signing Certificates