I am using 10.14.5 since my Catalina is quarantined at work.My application is X11 based and Xquartz 2.7.11 is installed.The application was successfully notarized and stapled using Xcode and the option "Disable library validation" checked.I also tried the command line approach with codesign, altool and xcrun stapler.Whatever I do the application fails with error:/opt/X11/lib/libXinerama.1.dylib: code signature in (/opt/X11/lib/libXinerama.1.dylib) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDsYes the Team IDs are different: myApplication --> TeamIdentifier=P65398CN49 libXinerama.1.dylib --> TeamIdentifier=NA574AWV7Ebut the hardening option "Disable library validation" being checked I do not understand that error message.Clearly, this key does not work as described by Apple (see below).com.apple.security.cs.disable-library-validationTypically, the Hardened Runtime’s library validation prevents an app from loading frameworks, plug-ins, or libraries unless they’re either signed by Apple or signed with the same team ID as the app. The macOS dynamic linker (dyld) provides a detailed error message when this happens. Use the Disable Library Validation Entitlement to circumvent this restriction.I searched the internet but could not find any solution.

I finally found a solution to obtain a notarised application which is functional.The bundle is organised as follows TestApp.app Contents MacOS testAppp <-- a launcher (C binary) myAlert <-- an alert dialogue (Cocoa binary) Resources winteracter <-- an X11 (Xquartz) window and dialogue (Fortran binary)The binary "winteracter" is based on the Winteracter library <http://www.winteracter.com> which uses OpenMotif and Xquartzwinteracter binaryThis binary is hardened manually (i.e. from outside Xcode) prior to the otherscodesign -d --force --options runtime --verbose=4 -s "$DEV_CERTIFICATE" --entitlements "winteracter.entitlements" "winteracter" winteracter.entitlements should only contain the following:com.apple.security.cs.disable-library-validation testApp and myAlert binariesThese are signed and hardened either manuallycodesign -d --force --options runtime --verbose=4 -s "$DEV_CERTIFICATE" "$MYBINARY"or using Xcode In that case be sure to manually erase the field "Code Signing Entitlements" en Build Settings. It may remained filled in even if you delete "Sandboxing" from the the Capabilities interface.Once notarized the application is functional.I tried sandboxing it but the infamous error "mapping process and mapped file (non-platform) have different Team IDs" went back !But what were my mistakes?1- Apple says that sandboxing keys must appear only once in entitlement file of the main binary, with other having only the "inherit" key. I wrongly assumed that com.apple.security.cs.disable-library-validation was inherited too.2- I thought the key com.apple.security.app-sandbox was compulsory in entitlement files. Not at all!3- I wrongly assumed that setting com.apple.security.app-sandbox to false is equivalent as no entitlement file. Wrong again!4- I wrongly assumed that the Xcode interface "Signing & Capabilities" correctly manages the Build Settings5- I performed so many trial an errors that I do not remember all by all dead ends where I got lost.

I have not tested it yet but I read that the problem is "productsign" not "Transporter.app". productsign is Okay with Catalina but does not correctly sign .pkg files with Big Sur. If this is the correct answer, I would say that the error message from Transporter is totally non-informative and misleading.

I reply to myself. Transporter's error message "Failed to decompress the app." with no more explanation is just a shame and was responsible for a big waste of time on my side. Another problem is that command line test tools such as spctl --assess or spctl -a -t execute may give inaccurate results depending on the certificate is use (Developer ID or Apple Distribution) After a lot of efforts, it turned out that: one of the 226 libraries of my App had a missing LCUUID one of the libs had a problem with a sealed ressource. I had to search for it manually to finally identify the problem. In other words "Transporter: Failed to decompress the app." should translate into "Transporter successfully decompress the App, but the bundle is rejected because ..."_

I forgot to mention the solution I finally found. I codesign and harden the auxiliary binaries prior adding them to Xcode. In Xcode I do the following:   Product/Archive    Distribute App    Developer ID    Upload    Distribution certificate: select "Developer ID application..."    Upload    Close       wait for Apple's notification    Click button "Export Notarized App"

Hi Quinn, Thank you for your answer. I will try bundling each auxiliary binary but this may imply making the macOS version quite different from the versions for other platforms, something I hoped I could avoid. A remaining couple of questions: 1- when myMainApp calls myAuxBin shall it be through a Finder command "open" or can I still use a direct call to the binary within the MacOS folder ? 2- One of these auxiliary binary uses a classical Open dialogue to open a file but also opens with no dialogue a set of other files with the same name but different extensions. Is this compatible with sandboxing or is there a trick I should know ? All the best Linus

Thanks Claude31, I will try that solution which, as you say, is not perfect. Since the folder may contain several file sets, this means asking first for the folder then asking for the file or file set. sandboxing is a real headache (at least for me). I agree with you.

I have the same problem with Big Sur 11.6.5. The strange thing is that a double-clic on an existing .txt or .rtf correctly displays the text. It is the File/Open menu that reluctantly displays a blank page. An SSD reformatting + a full macOS re-install did not cure that problem. Any help will be much appreciated! Thanks A

Thank you very much for your help. That's extremely useful. I encourage you to investigate the build process used by your build server Of course yes but the "build server" is not under my responsibility and thus the vtool trick is welcome to go ahead with my project! $ vtool -show-build myBinary <-- the LC_BUILD_VERSION was successfully added myBinary: Load command 6 cmd LC_BUILD_VERSION cmdsize 24 platform MACOS minos 11.0 sdk 12.1 ntools 0 I thought that the missing minos was the cause of the Killed: 9 error in the Terminal and EXC_BAD_ACCESS (Code Signature Invalid) in the Console. If fact the problem is with "--options runtime" wether or not com.apple.security.cs.disable-library-validation is added to the entitlements This is new to me since I used that codesign option for long for both the current project and some others. $ codesign --remove-signature myBinary $ ./myBinary <--- Okay $ codesign -d --keychain /Users/filhol/Library/Keychains/login.keychain --force --verbose -s "Developer ID Application: xxxxxx" --entitlements simple.entitlements myBinary $ ./myBinary <--- Okay $ codesign -d --keychain /Users/filhol/Library/Keychains/login.keychain --force --options runtime --verbose -s "Developer ID Application: xxxxxx" --entitlements simple.entitlements myBinary $ codesign --display --verbose myBinary CodeDirectory v=20500 size=13876 **flags=0x10000(runtime)** hashes=423+7 location=embedded $ ./myBinary **Killed: 9 ** <-- Why ? And this can be repeated at will. Just removing the "runtime" option makes the binary operational. What do you suggest to bypass this problem ? Here my configuration: MacBook pro late 2013, MacOS Big Sur 11.7.2, Xcode 13.2.1 (I ordered a MacBook pro M1 but not yet received) I will try on a more recent Intel MacOS asap. All the best

Thank you very much for your help again. As a diagnostic step, try enabling all the hardened runtime exception entitlements and see if that gets your code to start. And this was an excellent advice since my app is again functional. Up-to-now I successfully used the only entitlement: com.apple.security.cs.disable-library-validation I am now forced to add the following: com.apple.security.cs.allow-unsigned-executable-memory I really don't know why since the code of most of the 50 Fortran binaries in the bundle was unchanged. They were only re-compiled on the build server. Anyway, the build server is another story and, at least, with your help, I could notarize the bundle again. For sure, you gave me decisive help! All the best

Sorry for the delay. Here the crash report from the Console when "com.apple.security.cs.allow-unsigned-executable-memory" removed. Crash report and entitlement All the best

Notararized only. I got the impression that is not possible to sandbox an X11 based application or at least I failed to do so. As a workaround I will try to call the Terminal through an osacript. All the best Alain

Thank you very much. As you said I cannot use your trick since I do not call NSWorkspace directly. Fortunately enough, a mere osascript solved the case. I noticed that the behaviour of Terminal calls changed since a recent update of Big Sur etc. I wonder if this is a related problem. My X11 based app is organised as follows: [MacOS folder] mybinary --> [Resources] myScript.sh --> myToolBar --> binary_01, binary_02, [...], binary_xx If myScript.sh is called without opening a Terminal window, any of the binaries "binary_xx" when they call "xterm -e" no Terminal window is shown. If myScript.sh is called from an opened Terminal window, "binary_xx" can open a Terminal window too. It is quite strange that now any "binary_xx" inherits a hidden/visible Terminal window from the initial shell script call. As I said my first notice of the problem after a recent Big Sur upgrade but it also affects other macOS versions. This is just to inform you since this is not a blocking problem, at least for me. Just an unwanted extra Window ... I can live with it. All the best

We finally found why the binaries x86_64 from our Build Server missed the LC_BUILD_VERSION section. Our server admin is a Linux expert and she configured the macOS server as she did for Linux. The offender turned out to be the packager UPX which works nicely on Linux but does strange things on macOS. UPXed binaries miss LC_BUILD_VERSION parameters, however they work nicely on Big Sur and Ventura for M1. On Ventura for Intel (and presumably on Monterey too) they crash with a "Segmentation fault 11". Removing the UPX step in the cmake of the build server turned ou to be the solution! View, what a fight! I finally got a working version of my app and I am very grateful for your help.

The problem is still present with Xcode 14.2. I prepared a fresh new project and the Products folder new showed up. The solution for me was inherited from Pulsar's post but with much less editing of the .xcodeproj file: Quit Xcode Open the bundle MYPROJECT.xcodeproj Edit the file MYPROJECT.pbxproj Search for "Products" In my case I found the following: /* Begin PBXGroup section */ 5D1FC2932992BC6900AA5910 = { isa = PBXGroup; children = ( 5D1FC2B92992BEC100AA5910 /* myBinary1 */, 5D1FC29E2992BC6900AA5910 /* myProject */, 5D1FC2BB2992BEF000AA5910 /* myBinary2 */, 5D1FC29D2992BC6900AA5910 /* Products */, ); I simply moved the /* Products */ line to the top of the "children" list 5D1FC29D2992BC6900AA5910 /* Products */, 5D1FC2B92992BEC100AA5910 /* myBinary1 */, 5D1FC29E2992BC6900AA5910 /* myProject */, 5D1FC2BB2992BEF000AA5910 /* myBinary2 */, Save and reopen Xcode. The Products folder was again visible in the project navigator. I don't know how to feel a bug report for the Xcode team Xcode 13, Xcode 14, the bug is stil present.