Ok, I've found out that some of my .dylib were not being signed in my script. Now I'm including all the files and launching the app throws a different error:Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)Exception Codes: 0x0000000000000032, 0x00000000fe52ffabException Note: EXC_CORPSE_NOTIFYTermination Reason: Namespace CODESIGNING, Code 0x2kernel messages:VM Regions Near 0xfe52ffab: VM_ALLOCATE 00000000128f7000-0000000012937000 [ 256K] rw-/rwx SM=PRV--> VM_ALLOCATE 00000000fe520000-00000000fe530000 [ 64K] r-x/rwx SM=COW __TEXT 0000000100000000-0000000100877000 [ 8668K] r-x/rwx SM=COW /Users/USER/*/MyApp.app/Contents/MyApp/bin/clibs/libwx.dylibIf I put the app into a dmg and upload it with the "xcrun altool" command it's being notarized successfully.Maybe this helps?$ spctl -vvv --assess --type exec Redist/Release/MyApp.appRedist/Release/MyApp.app: invalid API object reference
SrCobranza
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Hi eskimo, thanks for your answer.Exactly, the problem was that the app was crashing after signing with the hardened runtime enabled (notarization process was not involved yet).I've been trying to fix it by adding different exceptions entitlements and it finally worked after adding "com.apple.security.cs.allow-unsigned-executable-memory". The "com.apple.security.cs.allow-jit exception" wasn't needed.Just in case someone runs into the same issue, this is the final entitlements.plist file:<?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.security.cs.allow-unsigned-executable-memory</key>
<true/>
</dict>
</plist>And I'm doing the signing with this command (without the "--deep" option, as you suggested) for all of my executables:codesign --force --entitlements entitlements.plist --verbose=2 --sign "Developer ID Application: My Certificate Name" --options runtime path/to/executable
Yes, that's true.In this case I needed a quick workaround to ship the application, and since we're going to deprecate it soon anyway, it didn't worth the effort. But yes, definitively something to take into account for others running into the same issue, thanks for the suggestion.
Ok, I'm not sure if this is on purpose or it's a bug, but I don't see that option even if I have the "Admin" role. The person who created the Team is able to see the option to create that type of certificate. I share it just in case someone runs into the same issue. In my case, because of not having the correct option, I ended up using a wrong certificate...