Hey everyone, I was granted access to Family Controls (Distribution) for my main App ID The entitlement is visible and enabled in the App ID configuration. I’ve successfully created and used a provisioning profile that injects com.apple.developer.family-controls for the main app. ✅ However, the issue is with an extension target under the same parent App ID and all others Despite enabling the Family Controls (Development) capability in this extension’s App ID config, every new provisioning profile I generate for the extension fails to include the entitlement. I’ve confirmed this by: • Dumping the .mobileprovision with security cms -D → no sign of com.apple.developer.family-controls • Recreating the profile multiple times (Development and Distribution) • Ensuring the entitlement is toggled on in the portal • Validating the parent app profile does include it ⸻ ❗Question: Is there a known issue where Family Controls doesn’t get injected into extension App IDs even after team approval? Or is there an extra step I need to take to get this entitlement injected properly into provisioning profiles for app extensions?

Anyone know how long it takes to get Apple to respond to a request for provisioning for endpoint security?

My app records the screen to use the audio for audio analysis for a music visualization. The app works perfectly in production but when uploaded to Transporter is rejected as below. What is the correct entitlement to use as the entitlement I am using seems deprecated. Validation failed (409) Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, key 'com.apple.security.screen-capture' in 'com.boxedpandora.pulse.pkg/Payload/PuLsE.app/Contents/MacOS/PuLsE' is not supported. (ID: a1a436f5-925d-43bc-908d-0761064d589b) Many thanks for any input provided!

Short description of the issue/suggestion: After upgrading to MacOS Sequoia and being required to code sign and notarize my app, cannot launch app even though code sign and notarization pass Please tell us about your environment: MacBookPro Chip Apple M2 Max 32 GB JavaPackager version: 1.7.6 OS version: macOS Sequoia 15.0.1 JDK version: jdk-1.8 Build tool: Maven Steps to reproduce the issue: -DMG Maven Build of Spring Boot /Java (version 8) application with "fvarrui" JavaPackager plugin using default universalJavaApplicationStub. Code signing and Notarization / Stapling PASS and App installs in Application folder, however cannot launch App. Although code sign and notarization pass, it is interesting that in the build output, prior to it submitting to Apple, there is an error stating that the App code sign could not be replaced. What is the expected behavior? -App launches when double clicking the application icon What have you tried to resolve / workaround the issue? -Install via package rather than DMG - same result -Can launch App by opening up the app Content/MacOS folder and clicking directly on the universalJavaApplicationStub. Note requires that you allow it to run within the Security and Privacy settings. codesign --verify --deep --verbose force1.app force1.app: valid on disk force1.app: satisfies its Designated Requirement spctl -a -vvv force1.app Info.plist.txt pom.xml.txt f Build Output abridged.txt o SysConsoleOutput.txt r ce1.app: accepted source=Notarized Developer ID origin=Developer ID Application: Neal Hartmann (JPFYU53MK9)

Xcode 16.2 無法在IOS 18.2 Debug Xcode 16.2 iOS 18.2 直接建立新專案 Xcode -> Create New Project -> Multiplatform -> Application -> App 選擇 實體手機 -> 執行 error: attach by pid '1050' failed -- attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.) Logging Error: Failed to initialize logging system due to time out. Log messages may be missing. If this issue persists, try setting IDEPreferLogStreaming=YES in the active scheme actions environment variables.

Even if I recreate everything and register it, it does not register in xcode as shown below. No matter how many times I regenerate the certificate and profile, the same thing happens.

Hi Team, i'm running into same issue with notarization time. I create new, small app for a customer but however the notarization is running since this morning, so almost a few hours. This isn't normal or ? Is there anything what i can do ? Best regard, Lars

I started the notarization process for my electron app (just a browser window loading a URL) yesterday (26/03/2025) at around 05:23 GMT. I noticed in a couple of posts here in the forum that it may sometimes take a day to notarize the first app submitted by a team, but it has been over 30 hours now. Here's the log from xcrun notarytool history. createdDate: 2025-03-26T05:23:11.102Z id: ddcb3fca-4667-4acb-8fd1-3298a7c244cc name: xolock-browser.zip status: In Progress Do help me out here, I have zero idea why this is taking so long. Thanks in advance!

I've submitted my app, signed with a new Developer Id Certificate for a distribution outside of the App Store, 88 hours ago. xcrun notarytool history ... Shows the submission as "In Progress". xcrun notarytool log ... Tells me "Submission log is not yet available or submissionId does not exist". I don't know if that's expected for an "In Progress" submission. As far as I can tell the signing worked without problems. I'm using the Tauri toolchain, which under its hood is using notarytool. How long can I expect this to take? If there is a problem with my submission does the status just stay on "In Progress" or do I get an error? Thanks

I'm building an app that uses the Screen Time API and DeviceActivityMonitoring Framework. It works when I run the simulator build on iPhone 16 but when I try to launch it on my own iPhone, I get these errors. Provisioning profile "iOS Team Provisioning Profile: Kanso- Digital-Wellness.Kanso-v2" doesn't include the com.apple.developer.device-activity.monitoring entitlement. KansoMonitorExtension 1 issue x Provisioning profile "iOS Team Provisioning Profile: Kanso-Digital-Wellness.Kanso-v2.KansoMonitorExtension" doesn't include the com.apple.developer.device-activity.monitoring en... Read something online that said a reboot would fix this, but I tried and no luck. Any ideas? I'm not very technical, so would pay someone to fix this for me :)

This post is a ‘child’ of Resolving errSecInternalComponent errors during code signing. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Fixing an untrusted code-signing certificate If your code-signing identity is set up correctly, selecting its certificate in Keychain Access should display a green checkmark with the text “This certificate is valid”. If it does not, you need to fix that before trying to sign code. There are three common causes of an untrusted certificate: Expired Missing issuer Trust settings overrides Check for an expired certificate If your code-signing identity’s certificate has expired, Keychain Access shows a red cross with the text “… certificate is expired”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" error: The specified item could not be found in the keychain. If you use security to list your code-signing identities, it will show the CSSMERR_TP_CERT_EXPIRED status: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" (CSSMERR_TP_CERT_EXPIRED) 1 identities found Valid identities only 0 valid identities found The most likely cause of this problem is that… yep… your certificate has expired. To confirm that, select the certificate in Keychain Access and look at the Expires field. Or double click the certificate, expand the Details section, and look at the Not Valid Before and Not Valid After fields. If your code-signing identity’s certificate has expired, you’ll need to renew it. For information on how to do that, see Developer Account Help. If your certificate hasn’t expired, check that your Mac’s clock is set correctly. Check for a missing issuer In the X.509 public key infrastructure (PKI), every certificate has an issuer, who signed the certificate with their private key. These issuers form a chain of trust from the certificate to a trusted anchor. In most cases the trusted anchor is a root certificate, a certificate that’s self signed. Certificates between the leaf and the root are known as intermediate certificates, or intermediates for short. Your code-signing identity’s certificate is issued by Apple. The exact chain of trust depends on the type of certificate and the date that it was issued. For example, in 2022 Apple Development certificates are issued by the Apple Worldwide Developer Relations Certification Authority — G3 intermediate, which in turn was issued by the Apple Root CA certificate authority. If there’s a missing issuer in the chain of trust between your code-signing identity’s certificate and a trusted anchor, Keychain Access shows a red cross with the text “… certificate is not trusted”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer "Apple Development: …" MyTrue: errSecInternalComponent The message unable to build chain to self-signed root for signer is key. If you use security to list your identities, it will not show up in the Valid identities only list but there’s no explanation as to why: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 0 valid identities found IMPORTANT These symptoms can have multiple potential causes. The most common cause is a missing issuer, as discussed in this section. Another potential cause is a trust settings override, as discussed in the next section. There are steps you can take to investigate this further but, because this problem is most commonly caused by a missing intermediate, try taking a shortcut by assuming that’s the problem. If that fixes things, you’re all set. If not, you have at least ruled out this problem. Apple publishes its intermediates on the Apple PKI page. The simplest way to resolve this problem is to download all of the certificates in the Apple Intermediate Certificates list and use Keychain Access to add them to your keychain. Having extra intermediates installed is generally not a problem. If you want to apply a more targeted fix: In Keychain Access, find your code-signing identity’s certificate and double click it. If the Details section is collapsed, expand it. Look at the Issuer Name section. Note the value in the Common Name field and, if present, the Organizational Unit field. For example, for an Apple Development certificate that’s likely to be Apple Worldwide Developer Relations Certification Authority and G3, respectively. Go to the Apple PKI and download the corresponding intermediate. To continue the above example, the right intermediate is labelled Worldwide Developer Relations - G3. Use Keychain Access to add the intermediate to your keychain. Sometimes it’s not obvious which intermediate to choose in step 4. If you’re uncertain, download all the intermediates and preview each one using Quick Look in the Finder. Look in the Subject Name section for a certificate whose Common Name and Organizational Unit field matches the values from step 3. Finally, double check the chain of trust: In Keychain Access, select your code-signing identity’s certificate and choose Keychain Access > Certificate Assistant > Evaluate. In the resulting Certificate Assistant window, make sure that Generic (certificate chain validation only) is selected and click Continue. It might seem like selecting Code Signing here would make more sense. If you do that, however, things don’t work as you might expect. Specifically, in this case Certificate Assistant is smart enough to temporarily download a missing intermediate certificate in order to resolve the chain of trust, and that’ll prevent you from seeing any problems with your chain of trust. The resulting UI shows a list of certificates that form the chain of trust. The first item is your code-signing identity’s certificate and the last is an Apple root certificate. Double click the first item. Keychain Access presents the standard the certificate trust sheet, showing the chain of trust from the root to the leaf. You should expect to see three items in that list: An Apple root certificate An Apple intermediate Your code-signing identity’s certificate If so, that’s your chain of trust built correctly. Select each certificate in that list. The UI should show a green checkmark with the text “This certificate is valid”. If you see anything else, check your trust settings as described in the next section. Check for a trust settings override macOS allows you to customise trust settings. For example, you might tell the system to trust a particular certificate when verifying a signed email but not when connecting to a TLS server. The code-signing certificates issued by Apple are trusted by default. They don’t require you to customise any trust settings. Moreover, customising trust settings might cause problems. If code signing fails with the message unable to build chain to self-signed root for signer, first determine the chain of trust per the previous section then make sure that none of these certificates have customised trust settings. Specifically, for each certificate in the chain: Find the certificate in Keychain Access. Note that there may be multiple instances of the certificate in different keychains. If that’s the case, follow these steps for each copy of the certificate. Double click the certificate to open it in a window. If the Trust section is collapsed, expand it. Ensure that all the popups are set to their default values (Use System Defaults for the first, “no value specified” for the rest). If they are, move on to the next certificate. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Another way to explore trust settings is with the dump-trust-settings subcommand of the security tool. On a stock macOS system you should see this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. That is, there are no user or admin trust settings overrides. If you run these commands and see custom trust settings, investigate their origins. IMPORTANT If you’re working in a managed environment, you might see custom trust settings associated with that environment. For example, on my personal Mac I see this: % security dump-trust-settings -d Number of trusted certs = 1 Cert 2: QuinnNetCA Number of trust settings : 10 … because my home network infrastructure uses a custom certificate authority and I’ve configured my Mac to trust its root certificate (QuinnNetCA). Critically, this custom trust settings are nothing to do with code signing. If you dump trust settings and see an override you can’t explain, and specifically one related to code-signing certificate, use Keychain Access to remove it. Revision History 2025-09-29 Added information about the dump-trust-settings command to Check for a trust settings override. Made other minor editorial changes. 2022-08-10 First posted.

We are developing a macOS application for distribution outside the Mac App Store. This application requires additional entitlements, including Keychain access groups, Network Extension, App Groups, and Sandbox. Both the app and the network extension import a custom framework. After creating the .app via Xcode, I ensured that a new Developer ID Application provisioning profile was generated. These profiles were then injected into the Contents folder of the .app and Plugins/.netappex as embedded.provisionprofile. Next, .entitlements files were created with the necessary "-systemextension" entitlement for the network extension and used for code signing. When inspecting the extracted entitlements from the .provisioningprofile as described in TN3125, everything appears correct. Code signing flow: codesign --force --options runtime --timestamp --sign "Developer ID Application: <team>" <.app>/Contents/Frameworks/<sdk>.framework/ codesign --force --options runtime --timestamp --sign "Developer ID Application: <team>" <.app>/Contents/PlugIns/vpn.appex/Contents/Frameworks/<sdk>.framework/Versions/A/<sdk> codesign --force --options runtime --entitlements <vpn-plist>.entitlements --timestamp --sign "Developer ID Application: <team>" <.app>/Contents/PlugIns/vpn.appex/ codesign --force --options runtime --entitlements <app-plist>.entitlements --timestamp --sign "Developer ID Application: <team>" <.app> The .app is then zipped with ditto -c -k --keepParent and set off for notarization, which is succesful and the .app is stapled. After that, a .dmg or .pkg is created, which is then sent for notarization and subsequently stapled. The problem occurs when the app is distributed to the client. Opening the extracted .app fails, as Gatekeeper refuses to launch it with the following error message: 661 debug staticCode syspolicyd Security 0x88d68d818 done serializing <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string><teamid.bundleid></string><key>com.apple.developer.networking.networkextension</key><array><string>packet-tunnel-provider-systemextension</string></array><key>com.apple.developer.team-identifier</key><string>team-id</string><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.application-groups</key><array><string>teamid.group.appgroup</string></array><key>com.apple.security.files.user-selected.read-write</key><true/><key>com.apple.security.network.client</key><true/><key>com.apple.security.network.server</key><true/><key>keychain-access-groups</key><array><string>teamid.group.appgroup</string></array></dict></plist> com.apple.securityd 22207 debug ProvisioningProfiles taskgated-helper ConfigurationProfiles entitlements: { "com.apple.developer.networking.networkextension" = ( "packet-tunnel-provider-systemextension" ); "com.apple.developer.team-identifier" = team-id; "keychain-access-groups" = ( “teamid.group.appgroup” ); } com.apple.ManagedClient 22207 error ProvisioningProfiles taskgated-helper ConfigurationProfiles <bundle-id>: Unsatisfied entitlements: com.apple.developer.team-identifier, com.apple.developer.networking.networkextension, keychain-access-groups com.apple.ManagedClient After encountering this problem every time, we tried using a different development team with a new bundle ID, app groups, developer ID, developer ID certificate, and provisioning profiles. The .entitlements file remained the same (with different IDs), as did the capabilities for the App IDs in App Store Connect. With this new development team, we were successful, and the gatekeeper did not block the launch job. From a configuration standpoint, everything appears identical. Updating the App Store Connect App ID capabilities and generating new provisioning profiles for the first development team did not resolve the issue. Thank you for your help.

hey, trying to notarize my mac app rn. maybe servers are down. earlier today super fast but now slow and i need to ship. anyone having similar issue?

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.

I am a new macOS developer, and the codesign issue is persistent. I've been trying to resolve it for days. There are two issues: 1.) When downloading and installing frameworks, they are not showing up in Xcode templates. 2.) Regarding codesigning, even though I've installed it on my external drive and placed it in various locations (Library, Templates, Frameworks, Application Contents, macOS Templates and Frameworks) and added through General Libraries in Xcode, persistently encountering issues. I'm experiencing a codesign problem. I've cleaned the build, cleared derived data, downloaded certificates, added them to the access key, and linked the binary. However, the issue persists. Please help me, as this is making the process much more difficult. I've been stuck on this for weeks.

We are developing a custom login service including custom PAM module. While it initially works correctly after installation on macOS, it becomes blocked by the system during privilege escalation (coreauthd) after unlocking the screensaver. The custom PAM module has been signed with a Developer ID certificate and submitted for notarization using notarytool. And passed staple check. spctl -at open --context context:primary-signature -v pam_custom.so: accepted source=Notarized Developer ID Here are the detail steps: Install the custom PAM file under /usr/local/lib/pam/. Ensure SIP (System Integrity Protection) is enabled. Log in to the Mac using the custom login service developed with the custom PAM module. Successfully log in. Open System Settings > Touch ID & Password. Click Add Fingerprint to trigger local authentication. This local authentication can be passed using Touch ID without invoking the custom PAM. Cancel adding fingerprints. Allow the Mac to idle until the screensaver is triggered. Unlock the screen using the custom PAM. Go to System Settings > Touch ID & Password and click Add Fingerprint again. This time, local authentication triggers the custom PAM, but it always fails. The system log shows that the custom PAM is not found. Related system logs at step 9: 2024-12-25 19:05:05.320264-0800 0x42f3 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'authorizationhos(941)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. 2024-12-25 19:05:05.320629-0800 0x42f3 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'authorizationhos(941)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. Related system logs at step 11: 2024-12-25 19:05:22.510658-0800 0x41a6 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'coreauthd(653)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. 2024-12-25 19:05:22.510953-0800 0x41a6 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'coreauthd(653)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. 2024-12-25 19:05:22.511624-0800 0x41a6 Default 0x16b99 653 0 coreauthd: (libpam.2.dylib) in openpam_load_module(): no pam_custom.so found Why does local authentication call the custom PAM after unlocking from the screensaver? Could this issue also be related to a code signing configuration that needs adjustment?

I am making an iOS step counting app and I have included a widget in the design. I would like to get the widget to pull data from the main app to display step count etc so I created a bundle id for the widget and have been trying to use a group id to link them together. The group capabilities for both seem to be set up/enabled properly with the same App Groups id, but I've been getting an error in xcode which says, " 'Provisioning Profile: "BUNDLE_ID" doesn't include the com.apple.developer.security.application-groups entitlement.' Try Again But the identifiers do have the App Group id enabled. I have tried automatic signing, manual signing with generated profiles, unchecking and rechecking auto-signing, removing and re-adding the group capability. Creating a new bundle id from scratch, creating a new group id from scratch. Always I get the error. I've really pulled my hair out troubleshooting this and would appreciate support. I'm happy to answer and questions or share details. Thank you.

I have app developed in electron.js and python and it works in ios 15 after codesigning but not in ios 14 or below I need to understand if theres a specific instruction that we need to while building the app or do I need to codesign in lower version? what can I do solve this issue??

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?