I have a custom icon for my AU.component file, which was supposed to make my installer more intuitive and visually more pleasing.
However, I found that if I applied the new icon graphic before signing it, codesign complained resource fork, Finder information, or similar detritus not allowed.
Apparently the icon introduced new metadata that codesign didn’t like.
I thought, “Ok, I’ll sign it and then apply the icon afterwards”.
However, I found some other info that basically said,“if you apply the icon afterwards, then the digital signature might be invalidated”.
Has anyone got any experience of their plugin being invalidated because of something like this? I might not actually apply the new icon graphic just to be on the safe side.
.pkg and .dmg can have custom icons applied to them without codesigning issues. And they will be the most visible items you users will interact with anyway when installing product so maybe don’t bother yourself applying custom icons to anything else (which I can’t remember having ever see, probably for a reason).
After signing and notarizing you cannot touch the product at all. Older macOS versions have tolerated some changes after signing, but this has been correctly changes to not accept any changes to what is sent to customer machines. Signing and notarizing have to be the very last steps you do.
Sure, there can’t be any modification to signed/notarised objects. I meant there won’t be any complain with .dmg and .pkg having custom icons applied to them prior to signing as opposed to .component.
I loved Packages, but it’s not longer supported, and is broken…there’s a “secret” beta that fixes the worst of the issues, but still…I’m not sure how it’s viable any more?
