I can sign a Mac app in the terminal (as per docs --deep etc) but it is not verified as all the libraries inside are reported as “nested code is modified or invalid”. Is there a way to fix?
I would be easier to just make an xcode project and use xcode for signing (like say iOS), but xcode tries to build an x86 & arm64 thing and it doesn’t run so no good…
Unity 2019 LTS
I think you also need --force flag for the signing to complete.
yes tried that, no luck
Hmm, not sure what’s up with that. Regarding Xcode: you should be able to tell it to your build for “My Mac” instead of “Any device”
Just to make it clear, I do as per docs:
codesign -o runtime -f --deep -s ‘3rd Party Mac Developer Application: DEVELOPER NAME’ --entitlements “GAMENAME.entitlements” “/AppPath/GAMENAME.app”
after that the app does not even run!! It complains in detailed error because a dylib is not signed correctly.
so maybe you have to sign all plugins and dylibs first as I think xcode does - tried but no… cigar
I think this needs some updating in the docs, even if it is more of an apple issue it would help many people to get robust advice in the documentation.
Will try xcode again
Can you report a bug on being unable to sign it the “recommended” way so that we could either fix it or fix the documentation?
case 1304275
If you build to Xcode (I have 12.3) then the immediate error you get is:
ld: warning: ignoring file /project_path/Frameworks/UnityPlayer.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
"PlayerMain(int, char const**)", referenced from:
_main in Main.o
ld: symbol(s) not found for architecture arm64
it is set to build for my Mac but the build settings are now Standard Architectures (Apple Silicon, Intel)
You can manually change it to “x86_64” only under architectures, however code signing then will show errors if you have any bundles included (as can be in asset store plugins!)
You need to add --deep to code signing flags
Then on finally running my app throws an error in UnityGfxDeviceWorker(29), though runs if exported:
validateFunctionArguments:3554: failed assertion `Fragment Function(xlatMtlMain): Shader uses texture(_NormalBuffer[1]) as read-write, but hardware does not support read-write texture of this pixel format.'
Please update the docs or pin on this forum how to build for Mac now
Edit:
If I ignore the assert on debugging (!?) I can then notarise the app with apple, so it requires these Xcode steps:
The notarised app however does not seem to startup…
The above was Unity 2020.1
In 2019 LTS if I build to Xcode and run it crashes right away if I enable hardened runtime (need for notarisation) otherwise runs OK
Edit: solution for this is enable various hardened runtime exceptions 
This also fixes 2020 project but that is buggy - crash on xcode debugging, calling Application.quit seems to make OSX think it exited unexpectedly 
Thanks for the bug report.
Which Unity 2019 version are you on? I just discovered Unity Issue Tracker - [macOS] Code Signing using '--deep' flag Fails on Built Package due to incorrect case in built Contents/PlugIns folder. The fix for it landed to 2019.4.8f1 so I’m wondering if you could be running into it.
Unity 2019.4.15, I could not see any recent fixes
So terminal sign as per docs did not work (see bug)
Xcode build does work - but a number of manual changes to build settings required which Unity could/should apply for you? Setting architecture to x86_64 not silicon/intel is an immediate requirement
Yeah, something is definitely wrong there :(. Thanks for the bug report. We will take a look.
I’m also struggling with this: I built a Intel64 + Apple Silicon executable on 2020.2.1f1 and went throug the process described in How to notarize a Unity build for MacOs 10.15 Catalina · GitHub
Uploading to the notarization service works without errors. I then received an email telling me that the software was not notarized. I can then pull some information about the notarization using
xcrun altool --notarization-info XXX-XXX-XXX-XXX --username X@X.X --password XXX-XXX-XXX-XXX --asc-provider XXXXX
Here’s the log provided by the command
{
"logFormatVersion": 1,
"jobId": "0f5bf3be-eb5a-48b6-82e2-8ce35251e56b",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "From_Parts.zip",
"uploadDate": "2021-01-08T08:18:36Z",
"sha256": "4e5f821b1c82616328c7f3abf4a248872f9a996a39a6340e7c36d024e157fa83",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/lib_burst_generated.bundle",
"message": "The binary is not signed.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/lib_burst_generated.bundle",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
}
]
}
Any thoughts on that?
Could you file a bug report (on the fact that burst binary doesn’t get signed)? In the meantime, you should be able to sign it manually using “codesign -f -s - lib_burst_generated.bundle”.
thanks for your help @Tautvydas-Zilys . I tried signing with the command you provided which worked without an error, but the app still didn’t get notarized. This time, the error was as follows:
Error Message
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/lib_burst_generated.bundle",
"message": "The binary is not signed with a valid Developer ID certificate.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/lib_burst_generated.bundle",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/AVFoundationWrapper.bundle",
"message": "The binary is not signed.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/AVFoundationWrapper.bundle",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/libOni.bundle/Contents/MacOS/Oni",
"message": "The binary is not signed with a valid Developer ID certificate.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "From_Parts.zip/From Parts.app/Contents/Plugins/libOni.bundle/Contents/MacOS/Oni",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
}
So I signed again using my credentials and the first error went away. I applied the same command for the two other libraries (after another failed notarization attempt) and then it worked.
I’m not sure about the bug report, because yes, lib_burst_generated.bundle doesn’t get signed, but also some other libraries, which I found out after signing lib_burst_generated.bundle. Who’s in charge of signing individual dependencies? Eg. I’m using Obi Rope in my build, thus the dependency on libOni.bundle. Should Virtual Method (the creator of said dependency) sign these? I’m a bit lost, please advise.
Yeah, the authors of each library should sign them. Furthermore, unsigned binaries don’t run on Apple silicon devices when they’re built natively for them at all.
I am not sure that will happen. Thing is there are dynamic libraries which Unity can include I believe - these are not signed. So you have to do a deep sign - which seems easy in xcode with the addition of deep option (can Unity add by default?), as for terminal code signing… I would prefer not to have to type commands which must be character and option perfect in 2021!
Yeah, you having to mess with the command line is the last thing we want. We might have to solve it ourselves in Unity. We’re looking at what we can improve here.
I’m having the same issue! How did you guys fix it?
Did you guys find a solution?
Yup, Unity automatically signs the built app now.