Thanks a lot! I had the same issue, and probably would have never figured out the solution on my own.

In my tests, the attributedTitle property does have an effect, but if you set it too early in the tab's lifecycle, it gets reset. Setting it a bit later, it seems to properly stick. However, despite what the docs state*, the title's font size and font color are incorrect, even when left unspecified: the font is slightly too large, and the color is the same for both selected and unselected tabs (and isn't correct for either). * “Attributes that are left unspecified, including the font and foreground color, are automatically filled in using default values appropriate for the window tab”

Sure! Here's the first dialog: And the second: Of note, the second dialog only appears if you choose “Allow” in the first. If you instead choose “Always Allow”, the second dialog is skipped. (and the keychain read succeeds)

Thank you for your super detailed answer! And, oops, sorry about missing (or probably forgetting about) these warnings in the docs. I've been looking into various solutions, mostly gravitating towards the “symlinks for gnarly edge cases” solution. However, I ran into something perplexing: If I create an archive build within Xcode, then submit it using “Direct Distribution”, the process fails with a “The signature of the binary is invalid.” issue. But! If I then submit this same, archived .app, using notarytool, this submission then succeeds! Is this what you were referring to, when mentioning Xcode being persnickety? I don't understand the implications here—is Xcode performing the notarization submission differently? Is it OK to just rely on the command line for notarization? Here's how I submit via Terminal. I'm using the same AC profile in both cases: xcrun notarytool submit --keychain-profile "AC_PASSWORD" --wait ZippedArchivedApp.zip

(interesting reads, thank you—just learned a bunch of things) My previous message was misleading though, sorry: when notarizing through the command line, I was submitting the .app that Xcode re-signed with my Developer ID identity, not the original .app from the archive. Or said differently, I was submitting the .app found in *.xcarchive/Submissions, not *.xcarchive/Products. Still, the confusion remains! Because that means I'm submitting the exact same .app for notarization; and so in Xcode notarization fails, and using xcrun notarytool it succeeds. So strange. For now we should be fine notarizing through the command line, but if you do have insight into why there's a difference in the notarization service's behavior, I'm very much interested.

Yes, that's exactly it! I just reproduced the issue, strictly running through your list, to make extra sure. Here's the Xcode submission UUID: 417D4144-65D6-4C05-A219-4B2B5039AF7E And the notarytool submission UUID: 035482f3-855c-455f-bd60-6be63ceefd61 And for good measure, a screenshot of the submission failure in Xcode:

Thank you very much for looking into this; this makes perfect sense now. When I first looked into fixing the file structure to fit the rules, my first instinct was to experiment by submitting slightly modified versions for notarization (i.e. add/delete/move a file, then resign, zip and notarize) until notarization broke again. This was foiled, however, since CLI notarization always succeeded! Now that I know that I can reproduce this stricter behavior found in Xcode (by dropping extended attributes while zipping), it'll be easy to experiment and check my work. Thank you!