I’ve developed a macOS app, but I’ve had trouble using a script to fully codesign it and package it into a .dmg file. I was only able to complete codesigning using the third-party app itself—not via command-line scripts. Is it possible to write a script that automates the entire process of codesigning the app? To provide the best user experience for those downloading the app outside of the Mac App Store, is it correct to first package it as a .app and then wrap that into a .dmg file for distribution? Currently, the app is available on the web as a .dmg. When downloaded, it appears in a folder and can be double-clicked to launch. However, macOS displays a warning that it was downloaded from the internet. Can I use a script to remove that quarantine warning? If possible, I’d appreciate a step-by-step explanation and a sample command-line script to: Codesign the app properly Package it into a signed .dmg Remove the quarantine attribute for local testing or distribution Is the reason I was only able to codesign it inside the third-party app due to how that app was built, or can this always be done from the command line?

Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.

Hi guys, I got an error about mac notarization result return 132. here is the stack trace on the logs: 2025-02-25 02:53:55,503 ERROR [org.ecl.cbi.ws.mac.not.xcr.not.NotarytoolNotarizer] (macos-notarization-service-pool-thread-13) Error while parsing the output after the upload of '/tmp/macos-notarization-service/pending-files/myapplication.dmg' to the Apple notarization service: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Premature end of file. at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204) at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1465) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1013) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825) at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224) at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:637) at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:326) at java.xml/javax.xml.parsers.SAXParser.parse(SAXParser.java:197) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.PListDict.fromXML(PListDict.java:134) at org.eclipse.cbi.ws.macos.notarization.xcrun.notarytool.NotarytoolNotarizer.analyzeSubmissionResult(NotarytoolNotarizer.java:39) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.NotarizationTool.upload(NotarizationTool.java:50) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.Notarizer.lambda$uploadFailsafe$3(Notarizer.java:65) at net.jodah.failsafe.Functions.lambda$get$0(Functions.java:48) at net.jodah.failsafe.RetryPolicyExecutor.lambda$supply$0(RetryPolicyExecutor.java:66) at net.jodah.failsafe.Execution.executeSync(Execution.java:128) at net.jodah.failsafe.FailsafeExecutor.call(FailsafeExecutor.java:379) at net.jodah.failsafe.FailsafeExecutor.get(FailsafeExecutor.java:68) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.Notarizer.uploadFailsafe(Notarizer.java:65) at org.eclipse.cbi.ws.macos.notarization.NotarizationService.lambda$notarize$0(NotarizationService.java:192) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840) Do you know why? If you have any thread or documents telling about the details of return values of the command: 'xcrun notarytool submit'

I'm developing an app using Electron Builder for a potential port to Windows in the future. I've had a heck of a time getting credentials to work and felt like I was in some sort of time loop doing the same things over and over again to no avail. I finally was able to sign my app, sign the .dmg and start the notarization process. That was last night and it still says "In Progress". If anyone is able to push it through, that would be awesome! (id: 2520e724-7069-408a-9ea4-60b23e8435a7) I saw another thread on here where people stated it was taking forever, I'm not sure if this is just because its my first time, but I was hoping to get a beta out to testers this weekend. I just need a version that doesn't get flagged as "Malware" by Gatekeeper. This is just for a standalone macOS application, not the App Store. Is there a reason that this process takes an absurd amount of time? Will it always be like this or is this just a fluke and it was a bad time to try?

I am receiving an entitlement error from stripe terminal SDK when integrating Tap to Pay from apple in the info.plist. Im hoping that someone can give me their input on my error output rather than diving into the stripe sdk to point me in the right direction of something I may have missed with entitlements. I have been approved for tap to pay entitlement and am following the instructions here from apple: https://developer.apple.com/documentation/proximityreader/setting-up-the-entitlement-for-tap-to-pay-on-iphone com.apple.developer.proximity-reader.tap-to-pay

Yes, this is very likely the completely wrong way to do things but I would like to ask regardless. Currently with windows/linux I can perform an in-situ upgrade of an application by performing a download of the binary 'foo' and then doing a rename-and-replace and subsequently requesting the licencee to restart the program and all is good. With macOS, as the binary is within the foo.app ( Contents/macOS/foo ) I imagine I cannot perform a similar operation without breaking the signing of the foo.app itself? ....or, can I individually sign the binary foo for macOS and perform the same type of operation? Download new foo as foo.new rename current foo.app/Content/macOS/foo -> foo.old rename foo.new -> foo Restart application Again, I know this is very likely an un-macOS way of performing the task but as you can imagine with supporting cross-platform development it's usually easier to maintain a consistent method even if it's "not ideal".

Hello everyone, I'm facing a critical, blocking issue where my developer account (Team ID: K655PX7A46) is unable to generate a valid provisioning profile with the App Attest entitlement. I have confirmed this is a server-side issue and am hoping to get visibility from an Apple engineer who can investigate. The Problem: When I generate a provisioning profile for an App ID with the "App Attest" capability enabled, the resulting profile is defective. It is missing the required com.apple.developer.app-attest.environment key in its entitlements dictionary, causing Xcode to fail the build. What I Have Proven: The issue is not a misconfiguration. The App Attest capability is correctly enabled and saved on the App ID configuration page. The issue is not isolated to one App ID. I created a brand new App ID from scratch, enabled the capability during creation, and the server still generates a defective profile with the same missing entitlement. I have definitive proof by inspecting the downloaded .mobileprovision file. The contents confirm the required key is missing. Steps to Reproduce on My Account: Create a new App ID on the Developer Portal. Enable the "App Attest" capability and save. Generate a new "iOS App Development" provisioning profile for this App ID. Download the profile and inspect its contents via security cms -D -i [profile]. Observe that the com.apple.developer.app-attest.environment key is missing. The Evidence (Contents of the Defective Profile): Here is the output from inspecting the profile for a brand new App ID (com.technology519.linksi.app2). As you can see, the correct entitlement is missing, and an incorrect devicecheck entitlement is present instead. This is a critical bug in the provisioning profile generation service for my account that is blocking all development. I have already filed a support ticket (Case #102721408444) but have so far only received generic, unhelpful responses. Can an Apple engineer please investigate this server-side issue with my account? Thank you.

Thanks in advance for any hint to solve the following account problem: I tried to store credentials for notarizing. Presumably with the wrong combination of entries (similar to signing) – using the name of my university instead of my Apple Account. xcrun notarytool store-credentials "notarytool-password" --apple-id "Berliner Hochschule fuer Technik" --team-id "8YAW3HL2QP" --password "my Apple-Account-pw" .. retried assuming a syntax error (like missing "). Got the error message: This process stores your credentials securely in the Keychain. You reference these credentials later using a profile name. Validating your credentials... `Error: HTTP status code: 401. Your Apple ID has been locked. Visit iForgot to reset your account (https://iforgot.apple.com), then generate a new app-specific password. Ensure that all authentication arguments are correct.` Happy to see: Signing is not affected and I still an can log in to my account on developer.apple.com. So notarizing “only” seems to be affected. But how to reset the account to resolve the issue? The iforgot.apple.com link does not help - I provided my iPhone-number but did not receive further messages – neither on the iPhone nor on my “developer” macbook. Many thanks in advance All the best Florian

Hi, I am working on a personal HIDDriverKit project. The documentation suggests that you do not need the entitlements from Apple to do local development - that all you need to do is turn of SIP, enable developer mode, and turn signing to "Sign to Run Locally". However, I have followed all of these steps, and am still running into the error that to build, I need to have a provisioning profile with the DriverKit (development) feature (MacOS 15.2 Xcode 16.2). Am I missing something here regarding the steps for local development? Does one need to request a development version of the entitlements even for local development? Do I need a paid developer account to do this? Thank-you in advance.

We were recently approved for the "User Assigned Device Name" for a specific app Identifier. The "Additional Capabilities" tab isn't present on that App ID. I am an admin in the developer portal, and this does not appear for the account holder as well. Any help would be appreciated.

This is a continuation of my own old post that became inactive to regain traction. I am trying to resolve issues that arise when distributing a macOS app with a SysExt Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate. To directly distribute the app, I start with exporting the .app via Archive in Xcode. After that, I create a new Developer ID provisioning profile for both the app and sysext and replace the embedded ones in the .app package. After I have replaced the provisioning profiles and the have the entitlements files ready, I start signing the frameworks, sysext and parent app. codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/MacOS/<sysext> codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app After validation is successful with codesign --verify --deep --strict --verbose=4 <app>.app I zip the package, notarize and staple it ditto -c -k --keepParent "<app>.app" "<app>..zip" xcrun notarytool submit <app>.zip --keychain-profile “”<credents> --wait xcrun stapler staple <app>.app After that I finish creating signed and notarized .dmg/.pkg. hdiutil create -volname “<app>” -srcfolder “<app>.app/" -ov -format UDZO ./<app>.dmg codesign --force --sign "Developer ID Application: <name>" <app>.dmg xcrun notarytool submit <app>.dmg --keychain-profile "<credentials>" --wait xcrun stapler staple <app>.dmg Then when I move the .dmg to a clean system, open the .dmg, move the .app to the Applications folder, the attempt to run it fails with “The application “” can’t be opened.”. When I look into the console, the gatekeeper disallows the launch job with the message:
 86127 debug ProvisioningProfiles taskgated-helper ConfigurationProfiles entitlements: { "com.apple.developer.networking.networkextension" = ( "packet-tunnel-provider-systemextension" ); "com.apple.developer.system-extension.install" = 1; "com.apple.developer.team-identifier" = <teamid>; "keychain-access-groups" = ( “<teamid>.<app>.AppGroup" ); } com.apple.ManagedClient
<app>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, keychain-access-groups, com.apple.developer.system-extension.install, com.apple.developer.team-identifier LAUNCH: Runningboard launch of <app> <private> returned RBSRequestErrorFailed, error Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600001a25830 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}, so returning -10810

 I went through all possible formats (macOS-Style and iOS-Style App Group IDs) and combinations of appgroups according to the post “App Groups: macOS vs iOS: Working Towards Harmony”. But none of those work for me. The weird part is that when I try the same steps on different developer account, I am able to get the app running. What can be wrong?

Hi there! I have an issue with uploading a PKG installer to the MacOS AppStore. Uploading with: xcrun altool --upload-app -t macos -f $PKGPATH -u $DEVELOPER_ID -p $APP_SPECIFIC_PWD results in error: *** Error: Validation failed Invalid Provisioning Profile. The provisioning profile included in the bundle com.frogblue.frogCom [com.frogblue.frogCom.pkg/Payload/frogSIP.app] is invalid. [Missing code-signing certificate.] For more information, visit the macOS Developer Portal. (ID: fc4e5488-6d09-4ab2-b1f7-017a33c69723) (409) Application seems to be correctly code signed with „3rd Party Mac Developer Application“ certificate. codesign -dv --verbose=4 /Users/dietmar.finkler/Desktop/frogSIP/deploy/frogSIP.app Identifier=com.frogblue.frogCom Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=266432 flags=0x10000(runtime) hashes=8315+7 location=embedded VersionPlatform=1 VersionMin=720896 VersionSDK=918784 Hash type=sha256 size=32 CandidateCDHash sha256=923de799a54616706b76050b50b7ee6d59f8355a CandidateCDHashFull sha256=923de799a54616706b76050b50b7ee6d59f8355a65aa7cce03e34bb2033da1e9 Hash choices=sha256 CMSDigest=923de799a54616706b76050b50b7ee6d59f8355a65aa7cce03e34bb2033da1e9 CMSDigestType=2 Executable Segment base=0 Executable Segment limit=31604736 Executable Segment flags=0x1 Page size=4096 CDHash=923de799a54616706b76050b50b7ee6d59f8355a Signature size=9109 Authority=3rd Party Mac Developer Application: frogblue TECHNOLOGY GmbH (UG2P6T5LNH) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Timestamp=26.02.2025 at 10:07:08 Info.plist entries=31 TeamIdentifier=UG2P6T5LNH Runtime Version=14.5.0 Sealed Resources version=2 rules=13 files=1124 Internal requirements count=1 size=212 The PKG build with productbuild seems also be correctly code signed with„3rd Party Mac Developer Installer“ certificate. pkgutil --check-signature /Users/dietmar.finkler/Desktop/frogSIP/frogSIP-1.2a2.pkg Status: signed by a developer certificate issued by Apple (Development) Certificate Chain: 1. 3rd Party Mac Developer Installer: frogblue TECHNOLOGY GmbH (UG2P6T5LNH) Expires: 2026-02-25 17:17:54 +0000 SHA256 Fingerprint: D1 9E AC 27 C7 26 F3 2E 1E F5 50 2C 7A 1B 1D FB 54 D6 17 C1 1C 58 C1 7E F8 87 B6 44 D1 49 17 DC ------------------------------------------------------------------------ 2. Apple Worldwide Developer Relations Certification Authority Expires: 2030-02-20 00:00:00 +0000 SHA256 Fingerprint: DC F2 18 78 C7 7F 41 98 E4 B4 61 4F 03 D6 96 D8 9C 66 C6 60 08 D4 24 4E 1B 99 16 1A AC 91 60 1F ------------------------------------------------------------------------ 3. Apple Root CA Expires: 2035-02-09 21:40:36 +0000 SHA256 Fingerprint: B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C 68 C5 BE 91 B5 A1 10 01 F0 24 KeyChain login items show both "3rd Party Mac Developer Application" and "3rd Party Mac Developer Installer“ certificates. But checking with security find-identity -v -p codesigning shows only the "3rd Party Mac Developer Application“ certificate. "3rd Party Mac Developer Installer“ is missing. I check also the entitlement in the app package, which looks ok for me. codesign -d --entitlements :- /Users/dietmar.finkler/Desktop/frogSIP/deploy/frogSIP.app <?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>UG2P6T5LNH.com.frogblue.frogCom</string><key>com.apple.developer.aps-environment</key><string>production</string><key>com.apple.developer.associated-domains</key><array><string>applinks:go.dev.frogblue.cloud</string><string>applinks:go.test.frogblue.cloud</string><string>applinks:go.prod.frogblue.cloud</string></array><key>com.apple.developer.team-identifier</key><string>UG2P6T5LNH</string><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.cs.disable-library-validation</key><true/><key>com.apple.security.device.audio-input</key><true/><key>com.apple.security.device.camera</key><true/><key>com.apple.security.network.client</key><true/><key>com.apple.security.network.server</key><true/></dict></plist> What I am missing? Thanx for any hint! Regards Dietmar Finkler

Hi all, I’ve run into a signing/entitlements problem that shows up only on Big Sur (11.x). The very same .app launches perfectly on Monterey (12), Ventura (13), Sonoma (14 / 14.5) and Sequoia (15). Failure on macOS 11 com.apple.xpc.launchd[1] (application.app.myapp.exams.566312.566318[1602]): removing service since it exited with consistent failure – OS_REASON_CODESIGNING | When validating …/MyAppNameBlurred 3.13.1.app/Contents/MacOS/MyAppNameBlurred 3.13.1: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: Binary is improperly signed. Launching from Terminal: open -a "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app" kLSNoLaunchPermissionErr (-10826) | Launchd job spawn failed with error: 153 What I’ve already checked # signature itself codesign -dvvv "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app" # => valid, Authority = Developer ID Application, runtime enabled # full deep/strict verification codesign --verify --deep --strict -vvv "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app" # => “satisfies its Designated Requirement” # Gatekeeper assessment spctl --assess --type execute --verbose=4 "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app" # => accepted (override security disabled) # embedded provisioning profile matches bundle ID codesign -d --entitlements :- "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app" | plutil -p - security cms -D -i "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app/Contents/embedded.provisionprofile" \ | plutil -extract Entitlements xml1 -o - # => both show the AAC entitlement and everything looks in order # notarization ticket stapler validate "/Users/admin/Downloads/MyAppNameBlurred 3.13.1.app" # => “The validate action worked!” Deployment target: MACOSX_DEPLOYMENT_TARGET = 11.0 Entitlement added: com.apple.developer.automatic-assessment-configuration = true Provisioning profile: generated this year via Developer ID, includes the assessment entitlement and nothing else unusual. Runtime code: we call AEAssessmentSession's network configuration part only on 12 + (guarded with @available(macOS 12.0, *)). Has anyone hit this mismatch on 11.x? Could Big Sur be expecting something older or idk? Any pointers appreciated! Thanks!

Displaying attribute for a private key I see a number of applications that are allowed to access it without needing a password e.g. racoon; Keychain Access.app; Certificate Assitant.app etc.. I want to add /usr/bin/codesign to the list but the gui window that pops up when I click on + doesn't seem to allow me to do that :( How do I do it please

Hi all, I'm a solo iOS developer trying to update an app I released in 2010. My current Team ID is Q37598Q8GE, but the app's original App ID uses an old prefix, YHX995W43P. When I try to create a new App ID with the original Bundle ID (eu.andela.woordenes) to generate a new distribution provisioning profile, I get the error:An attribute in the provided entity has invalid value An App ID with Identifier 'eu.andela.woordenes' is not available. Please enter a different string. I understand this might be due to the old prefix from pre-2011, when Apple allowed multiple prefixes per account. I still have access to the app in App Store Connect and want to push an update, not create a new app. How can I resolve this?Can I reuse the existing App ID (eu.andela.woordenes with prefix YHX995W43P) for a new provisioning profile, or do I need to match my current Team ID (Q37598Q8GE)? If the Bundle ID is already taken by my current app, how do I update the app without changing the Bundle ID? Any steps to fix the prefix mismatch in Xcode or App Store Connect?

The device UDID was registered to the developer account 40 hours ago, the STATUS column was "processing" in the first 24 hours, then turned to empty. But I still can't run my app (with distribution method "development"), when I try to run it after download it through my OTA URL, it prompts “the app cannot be installed because its integrity could not be verified” but everything runs good on a iPhone which was registered a month ago. What should I do now? keep waiting?

We've been creating iOS apps for a few years now, but when I tried last month, I got an error in my XCode that says: No profiles for 'com.os.hub.mth2' were found Xcode couldn't find any iOS App Development provisioning profiles matching 'xxx.xxx.xxx.xxx'. I'm not sure if it's the cause or not, but when I look at the signing certificates, the Developer ID Application Certificate says: Missing Private Key The weird part of that is that I see a private key with this name in my Keychain access, so I'm not sure what's wrong. There has been a significant time gap between now and the last time we created a mobile app, so I'm not sure if something changed in XCode/MacOS to cause this issue, or if something expired. I'd appreciate any advice.

Is it possible to directly distribute a macOS app with a Developer ID Certificate that belongs to a different team? I am trying to resolve issues that arise when distributing a macOS app with a Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate from a different team than the app’s provisioning profiles and entitlements. I started by attempting Direct Distribution in Xcode with automatic signing. However, it fails with the following message: Provisioning profile "Mac Team Direct Provisioning Profile: ” failed qualification checks: Profile doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. I suspect the issue is that the provisioning profile allows "packet-tunnel-provider-systemextension", whereas the entitlements generated by Xcode contain "packet-tunnel-provider". When I manually modify the .entitlements file to include the -systemextension suffix, the project fails to build because Xcode does not recognize the modified entitlement. If there is a workaround for this issue, please let me know. Due to these issues, I resorted to manually creating a signed and notarized app. My process is as follows: Export the .app from the Xcode archive. Since the exported .app does not contain the necessary entitlements or provisioning profile for direct distribution, I replace Contents/embedded.provisioningprofile in both the .app and the .appex network extension. Sign the app and its components in the following order: codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/PlugIns/<netext>.appex/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/PlugIns/<netext>.appex/ codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app Verify the code signature: codesign --verify --deep --strict --verbose=4 <app>.app - <app>.app: valid on disk - <app>.app: satisfies its Designated Requirement Create a ZIP archive using: ditto -c -k --sequesterRsrc --keepParent <app>.app <app>.zip Notarize the app with notarytool and staple it. The notarization completes successfully with errors: nil. Package the notarized app into a DMG, notarize, and staple the DMG. The app runs successfully on the development machine. However, when moved to another machine and placed in /Applications, it fails to open. Inspecting Console.app reveals Gatekeeper is blocking the launch:
 taskgated-helper <bundleid>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, com.apple.developer.team-identifier taskgated-helper entitlements: { "com.apple.developer.networking.networkextension" = ("packet-tunnel-provider-systemextension"); "com.apple.developer.team-identifier" = <teamid>; } As mentioned earlier, the Developer ID Certificate used for signing belongs to a different team. We are a third-party developer and do not have access to the Developer ID Certificate of the team assigned as the team-identifier. When I changed the bundle identifier (app ID), team, entitlements, and provisioning profiles to match the team associated with the Developer ID Certificate, the app worked. My question is:
 Is this failure caused by using a Developer ID Certificate from a different team, or should it still work if the provisioning profiles and entitlements are correctly set? Could there be an issue elsewhere in the provisioning profiles or entitlements for the original app ID?

It's been over 24h and it's still in progress. Is there a timeout for a failed notarization? or do we just wait for days.. weeks.. moths? Successfully received submission info createdDate: 2025-06-25T09:52:03.153Z id: 2ae713a5-c2e3-432f-84ee-e5d3d4aed621 name: slideshow-city-1.1.0-arm64.dmg status: In Progress

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!