I landed on this question due to a similar problem of a Framework that Xcode was not resigning correctly (but AppStore Connect does). In my case the author provides a distribution license (your case 1). With regard to your question on GPL I am also not a lawyer, but this has come up off and on over the past 35 years. These are quotes from gnu.org. This is why the industry refers to the "GPL Virus" You have a GPLed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? (https://www.gnu.org/licenses/gpl-faq.en.html#LinkingWithGPL) Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions. If so, is there any chance I could get a license of your program under the Lesser GPL? (#SwitchToLGPL) You can ask, but most authors will stand firm and say no. The idea of the GPL is that if you want to include our code in your program, your program must also be free software. It is supposed to put pressure on you to release your program in a way that makes it part of our community. You always have the legal alternative of not using our code.

I have some more info on this. The 3rd party developer package contains a framework and two bundles. The framework IS getting resigned to agree with my certificate but the bundles have not been. The framework tries to load one of the bundles which causes /Users/{user}/Library/Developer/Xcode/DerivedData/CaptureEclipse-evfrpkqsoswzwsgrcttvdaqskqfx/Build/Products/Debug/CaptureEclipse.app/Contents/Frameworks/{vendor}.framework/Versions/A/{vendor}Image.bundle/Contents/MacOS/{vendor}Image' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs) At the moment this does not appear to be fatal {for me} since neither my app nor the framework seems to call into the bundle, but this is likely causing log entries. I tried adding the bundles as Embedded content and as "Copy Bundle Resources" but neither made a difference I ported by project back to Ventura and Monterey machines so I could test with Xcode 14 and 13. I must have not noticed these errors before.

The work around is what Eskimo suggests. The app will run if you turn off library validation. That will likely result in your app being rejected for the App Store. <key>com.apple.security.cs.disable-library-validation</key> <true/>

This problem is still in Xcode 15.1 RC

I verified that when my app was built with XCODE 14 that the team IDs on the included Framework were changed to my own Team ID. The problem appears to be a bug introduced in XCODE 15 not the problem Eskimo talked about.

I tested it again this morning using the original test code from above. It now works on both M1/Ventura and Intel/Monterey. To adapt to Ventura I briefly switched the dialogs from modal to sheets. I then went back to modal dialogs issued more cleverly. I thought I had used the original test code for both before I changed the test design. Mea Culpa This thread can be closed (and deleted)

this is what Xcode sees The alert is actually queued for display while the Total Eclipse Editor dialog is being created and then displayed once that window appears when it is legal to post alerts. In other words it appears immediately, but I added the fudge of waiting since I am now running on a Studio instead of a Mac Pro 2013. The "Save Prefs" button is the previous configuration dialog.

I used the Accessibility tool and the alert shows This worked fine when I ran the test under Catalina/Big Sur It is not a system dialog. It is one that my app posts when a scenario condition is not met. I am not sure what you are asking WRT the bundle of the test run. The code I am currently using does the search as found = app.alerts.firstMatch.waitForExistence(timeout: 5.0) let ackdialog = app.alerts.firstMatch I have also tried posting the dialog using beginSheetModal and then searching for a sheet.

At the request of Apple DTS I submitted FB9567844. I met with the App Store Connect folks this morning. They indicated they understood my problem.

Another CFBundleIdentifier Collision threads such as https://developer.apple.com/forums/thread/73528 can be marked as a duplicate.

See the thread https://developer.apple.com/forums/thread/687535?answerId=686014022#686014022 for more information on this issue

I verified that I can (and should) resign the 3 parts as follows. Doing so allows you to run with a fully hardened runtime. where Ψ is the name of an apple distribution certificate my-machine  Framework % codesign -vvv -f --remove-signature EDSDK.framework/Versions/A/CHHLLite.bundle  EDSDK.framework/Versions/A/CHHLLite.bundle: replacing existing signature EDSDK.framework/Versions/A/CHHLLite.bundle: signed  [] my-machine  Framework % codesign -vvv -f --remove-signature EDSDK.framework/Versions/A/EdsImage.bundle  EDSDK.framework/Versions/A/EdsImage.bundle: replacing existing signature EDSDK.framework/Versions/A/EdsImage.bundle: signed  [] my-machine  Framework % codesign -vvv -f --remove-signature EDSDK.framework/Versions/A/EDSDK           EDSDK.framework/Versions/A/EDSDK: replacing existing signature EDSDK.framework/Versions/A/EDSDK: signed  [] my-machine  Framework % codesign -f -v -s Ψ EDSDK.framework/Versions/A/EdsImage.bundle EDSDK.framework/Versions/A/EdsImage.bundle: signed bundle with Mach-O thin (x86_64) [com.canon.EdsImage] my-machine  Framework % codesign -f -v -s Ψ EDSDK.framework/Versions/A/CHHLLite.bundle  EDSDK.framework/Versions/A/CHHLLite.bundle: signed bundle with Mach-O thin (x86_64) [jp.co.canon.CHHLLite] my-machine  Framework % codesign -f -v -s Ψ EDSDK.framework/Versions/A/EDSDK           EDSDK.framework/Versions/A/EDSDK: signed bundle with Mach-O thin (x86_64) [com.canon.edsdk] In Xcode you should select Frameworks, Libraries,.. to "embed and sign", Link Binary with libraries, and Embed Frameworks Note that the subject issue remains open.

I could also remove the "Disable Library Validation" and run with a fully hardened runtime. IMO this is an incorrect approach. Disabling library validation only makes sense in a limited set of circumstances [1] and using a third-party framework is not one of them I think this was caught in a double negative. I currently have to use Disable Library Validation since my current build uses the Library with Canon Signing. If I change the signing to my own then I will be able to run with a fully enabled Hardened Runtime

Indeed. Given the complexity of this issue I recommend that you open a DTS tech support incident so that I can help you one-on-one. Make sure to include a reference to this DevForums thread, just for context. OK That was going to be my next step. Once I get a solution this is worthy of an Apple Tech Note because I have seen this same problem multiple times.

So if someone could suggest a procedure to remove the signing on a 3rd party framework (including the two included bundles) and replace it with my own signing then that would solve the problem. I could also remove the "Disable Library Validation" and run with a fully hardened runtime.