"The signature of the binary is invalid" macOS App Notarization Issue

Sounds like you’ve run most of the diagnostics that I’d recommend |-:

It also looks like you’re using Xcode. Are you notarising from the Xcode organiser? Or from the command line using notarytool?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for taking the time to look over this.

I am using the Xcode 16 organizer with the 'Direct Distribution' option to handle notarization.

Would it be worth a shot at looking into using notarytool? I haven't used it in the past, so I would need to look into it more before diving in.

I also thought that maybe there was a change between Xcode (or notarytool / codesiging) versions that changed how the app would be signed, but I couldn't find any (breaking) changes when looking at the xcode release notes.

Are you notarising from the Xcode organiser? Or from the command line using notarytool?

The approach I usually take is to export the app from the Xcode organiser and then use notarytool to attempt to notarise that. The advantage of that approach is that you end up with a notary log [1] and the exact file that was submitted to the notary service. You can then look at the file to see what’s what.

I’ve found that using Xcode for notarisation is very convenient under normal circumstances, but it adds a layer of abstraction that I’d rather not have when I’m dealing with the weird stuff.

Submitting with notarytool is pretty easy; see Customizing the notarization workflow for instructions.

Once you have these two bits of info — the file you submitted and the notary log — there are two things I’d recommend you do:

• Unpack the file on a case-sensitive volume and see if that changes the result of the code signature verification (that is, the codesign --verify --strict --deep -vvv … command).

• Check the zip archive for extended attributes. You can list the archive’s content with unzip -l. You want to look for any ._ files, and also for any __MACOSX directories. A well-structured Mac app shouldn’t have any of those [2].

Please try this out and let me know what you see. If neither of these reveal anything interesting, there are still things we can do, but they’re more complex.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] See Fetching the Notary Log.

[2] See Extended Attributes and Zip Archives for more context on this.

Thank you for the suggestions, here are my results:

Exporting

In order to export my app archive through the organizer, I followed these steps: Xcode 16 -> Organizer -> Distribute App -> Custom -> Direct Distribution -> Export -> Automatically Manage Signing -> Export.

Notarytool + Log

After exporting, I followed Customizing the notarization workflow in order to run notarytool. You were right, the process was easier than I thought that it would be. After running notarytool, I was able to get the log file from the failed notarization by running xcrun notarytool log .... I have attached the log file below.

Case Sensitive Volume

I created a case sensitive volume using the disk utility app. After copying over and unpacking my app, I re-ran codesign --verify --strict --deep -vvv …, which produced different results than my original debugging session. The output was a lot shorter than my initial run (maybe from detecting the issue?). This seems to be the issue from the output:

--prepared:/Volumes/Notarization Testing/MYAPP.app/Contents/Frameworks/grpcpp.framework

/Volumes/Notarization Testing/MYAPP.app: code has no resources but signature indicates they must be present

In subcomponent: /Volumes/Notarization Testing/MYAPP.app/Contents/Frameworks/grpcpp.framework

Extended Attributes in Zip Archive

I checked for extended attributes by running unzip -l MYAPP.zip | grep -E "__MACOSX|._" and the output was empty. I also ran unzip -l MYAPP.zip while manually checking and noticed no directories or files with these prefixes. Also when signing through the organizer, these files + directories seem to automatically get stripped if they happen to be in the archive, though I might be wrong about that.

Conclusion

From this debugging session, it seems that the issue stems from the new output received when debugging the code signing on a case-sensitive volume. The error seem to be "code has no resources but signature indicates they must be present" for grpcpp.framework. Which I'm not sure exactly what that means at the moment besides that it is from an external package. I'll do some more research and see if I can resolve that.

I think that I have solved this issue.

The issue seems to be related to this Firebase package issue.

I updated the firebase SPM package to v10.29.0, and after was able to get the app notarized again. The issue must have only shown since I updated my xcode version to xcode 16 when updating my macOS version to 15.

Thank you for your reply that got me on track to fix this issue, I'm not sure if I would have been able to solve this without your suggestions.