Nevermind, I removed the dangling RPATHs from the relevant libs using install_name_tool and turned off library validation and now it's working. Our app bundle itself defines the run path search paths. I guess our build system for the 3rd party libraries (Conan) sets those in order to build the libraries with dependencies but I'm not sure. Anyway, solved now. Thanks!

Hey again! Looks like I spoke too soon. Setting the disable library validation entitlement to false made Gatekeeper happy but introduced a new much bigger problem. Our app supports using external, professional video hardware by Blackmagic and AJA. For AJA, we're shipping the required libraries as part of the app bundle so I guess that's why it still works. However, for Blackmagic devices, the app is just built against a small SDK. The SDK will load the actual framework from a system folder (/Library/Frameworks/DeckLinkAPI.framework/Versions/A/DeckLinkAPI). This works when building with Xcode and signing the app locally. But when running the release build, the Blackmagic devices are not loaded at all. Is that because the library validation doesn't allow libraries to be accessed which are outside the bundle? With disable library validation turned on this worked but we got the other Gatekeeper issue as described above. Is there a way forward? Thanks so much! Is there

Thank you so much! I haven't touched that entitlements file in quite a while. Wasn't aware the com.apple.security.cs.disable-library-validation was still in there. It didn't do any harm with the previous version of the libraries where we used a different approach to build them. I removed it and now Gatekeeper is happy! Success!! For my understanding: the library libavcodec.dylib tries to load this dangling library: /Users/flo/.conan/data/openssl/3.1.3/_/_/package/869f360e5d846618772ce5abc649684a86565498/lib/libswresample.dylib Why is that not shown in the otool -L output? That output does indeed reference libswresample, but with a different path: @rpath/libswresample.dylib There is also no error in operation. In contrast, otool -l prints the load commands, how is that different from the output of otool -L? I'm trying to understand how I could possibly catch this since it doesn't cause a linker error. Thanks!

Ok, thanks for that. I set up a clean Sonoma 14.4.1 VM, downloaded the DMG from our local build server, installed it and I'm getting the "app can't be opened because the developer cannot be verified" I verified both the app and the DMG using the commands from the Testing a Notarized Product link you provided. spctl -a -t exec -vvv /Applications/MyApp.app /Applications/MyApp.app: accepted source=Notarized Developer ID origin=Developer ID Application: *** spctl -a -t open -vvv --context context:primary-signature ~/Downloads/MyApp.dmg /Users/flo/Downloads/MyApp.dmg: accepted source=Notarized Developer ID origin=Developer ID Application: *** I found one of your other posts where you wrote about the new syspolicy_check. I tried that and I am indeed getting an error: syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Bad Load Command File: MyApp.app/Contents/MacOS/../Frameworks/libavcodec.dylib Severity: Fatal Full Error: /Users/flo/Downloads/MyApp.app/Contents/MacOS/../Frameworks/libavcodec.dylib attempts to load /Users/flo/.conan/data/openssl/3.1.3/_/_/package/869f360e5d846618772ce5abc649684a86565498/lib/libswresample.dylib. Resolved load path: (path not found) Type: Notary Error --------------------------------------------------------------- This is a very odd one. The path mentioned is indeed not present on the machine I'm running the app on. But when I run otool, I don't see this path. otool -L /Users/flo/Downloads/MyApp.app/Contents/Frameworks/libavcodec.dylib /Users/flo/Downloads/MyApp.app/Contents/Frameworks/libavcodec.dylib (architecture x86_64): @rpath/libavcodec.dylib (compatibility version 59.0.0, current version 59.37.100) @rpath/libswresample.dylib (compatibility version 4.0.0, current version 4.7.100) @rpath/libavutil.dylib (compatibility version 57.0.0, current version 57.28.100) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0) @rpath/libz.dylib (compatibility version 1.0.0, current version 1.3.0) /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0) /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1069.24.0) /Users/flo/Downloads/MyApp.app/Contents/Frameworks/libavcodec.dylib (architecture arm64): @rpath/libavcodec.dylib (compatibility version 59.0.0, current version 59.37.100) @rpath/libswresample.dylib (compatibility version 4.0.0, current version 4.7.100) @rpath/libavutil.dylib (compatibility version 57.0.0, current version 57.28.100) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0) @rpath/libz.dylib (compatibility version 1.0.0, current version 1.3.0) /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0) /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1228.0.0) Can you help me understand the issue better? Thank you very much!

@eskimo I'm having the exact same problem although our app is distributed through a DMG. The app is signed and notarized and spctl as well as codesign verify doesn't show any problems. However, when it is launched some users (it's apparently not happening for all) get the "app cannot be opened because the developer cannot be verified". xattr shows that the quarantine attribute is set and not cleared: /Applications % xattr -l MyApp.app com.apple.macl: com.apple.provenance: com.apple.quarantine: 0183;66100fe4;Safari;76643850-7086-4346-8B1E-02EF43C9799D What can I do to fix this? Just in case this is relevant (it may be following the rest of the conversation here): Our app has a bundled Python runtime which - when the app is started - will create compiled files which would invalidate the bundle's signature. Hence, we're copying the relevant Python files to a subfolder within Application Support and our app's bundled Cython will then read/write files in this location. However, this shouldn't be any different to reading/writing user preference or similar files in this location which is what we've been doing forever without these kind of issues. I would appreciate any ideas on how to get around this or what else to try to troubleshoot this further. Thank you!

Thanks! I have tried that but unfortunately it didn't work. The command per se finished and didn't print any error message but when triggering a build with notarization directly after, it still prints the error message about the keychain item not being found. I checked and found that the keychain item was added to the iCloud keychain so I also tried unlocking the iCloud keychain specifically using security unlock-keychain iCloud but that unfortunately didn't work. I also tried logging in through remote desktop and that also didn't change things. Can you think of another solution? Things were working fine with altool and stapler.

The one and only eskimo! ;-) Thanks for your help! I have created new credentials this morning. I notarized an app directly after and it worked fine as expected. I just tried notarizing again (about 6 hours later) and it failed with the error message: "Error: No Keychain password item found for profile: notarization" You are correct though that the keychain item itself is still present so it's probably a keychain access problem. Do you know how to get around that? Thanks!