I’m experiencing this same issue as well. I tried going through UNSH’s guide on github and the steps in the Kitteh Face blog post, as well as many different combinations of signing commands, but all of my builds crash with the same Code Signature Invalid exception.
UNSH, did you ever see a crash like this while working on the initial guide? I haven’t been able to find any useful information in the crash report to help locate the specific cause of the signing error, but if you had any experience or tips diagnosing something similar that could be a big help!
One thing I did notice while attempting to run these commands manually is that the SignAndPackage script only signs one of the five dylibs included in the build for the version of Unity I’m using. Specifically, my build from 2018.3 includes:
I’ve tried signing just the two in the MonoBleedingEdge directory (I guess libmono.0.dylib was at some point replaced by libmonobdwgc-2.0.dylib?) and signing all 5, but I get the same crash regardless.
I’m going to try doing all of the provisioning from scratch today and following the Kitteh Face guide again, so I’ll post back if I find anything. Thanks!
EDIT: Also, just to be clear, once the RepeatForUpdatedBuild script is run, the game should be immediately launchable from the 1_MyBuild directory correct? I’ve seen reports online that this crash will occur when trying to run a distribution build locally and is expected because it needs to be signed by Apple first, but my understanding is that builds with a development profile should still work locally.
Also, thanks UNSH for the awesome guide and your willingness to support it!
Alright, I was able to get a functioning build. The Code Signature Invalid crash was indeed caused by signing with a Distribution certificate instead of a Development one. The SignAndPackage script uses “3rd Party Mac Developer Application: $DEVNAME” for the signing identity in dev builds, but in my setup this is actually a Distribution certificate. I changed the identity to my Development certificate (named something like “Mac Developer: (XXXXXXXXXX)”) and was able to do a build after signing all .dylibs in the build.
For reference, my SignAndPackage script now looks like this for dev builds:
if [ "$BUILD_FOR" = "dev" ] ; then
for file in "$appDir/Contents/Frameworks/"*.dylib
do
codesign --force --verify --verbose=4 --display --sign "$DEVIDENTITY" --preserve-metadata=identifier,entitlements,flags "$file"
done
for file in "$appDir/Contents/Frameworks/MonoBleedingEdge/MonoEmbedRuntime/osx/"*.dylib
do
codesign --force --verify --verbose=4 --display --sign "$DEVIDENTITY" --preserve-metadata=identifier,entitlements,flags "$file"
done
for file in "$appDir/Contents/Plugins/"*.bundle
do
codesign --force --verify --verbose=4 --display --sign "$DEVIDENTITY" --preserve-metadata=identifier,entitlements,flags "$file"
done
codesign --force --verify --verbose=4 --display --sign "$DEVIDENTITY" --entitlements "$locationEntitlements" "$appDir"
elif [ "$BUILD_FOR" = "appstore" ] ; then
I thought that signing with a developer id you sign your build for outside of the Appstore, I could be very wrong though ( EDIT: And wrong it is) . In any case if you can test iCloud functionality then we’re a bit closer closer to a solution. And you’re right all those .dylib’s should be signed to, I’m updating the script with to loop through the respective folders instead.
To answer your questions :
No you’re not supposed to use the build in “1_Build”. Product build will create an installer in “7_Distribution/Your_Build_Destination/Dev_or_Dist/Your_Version” Also when building for the Appstore delete the build in the 1_Build folder because the installer will install there instead of the Applications folder.
No we didn’t have any crashes then but like I said we didn’t use iCloud and our setup was really simple. We sent our builds to the Appstore they were accepted and pushed the whole experience deep into the subconscious like a childhood trauma The last build we sent to the Appstore was about six months ago and things have changed yet again apparently so three hoorays for that.
EDIT : You’re right, so I got completely confused on building for development, my apologies I’m adjusting the script now.
Sounds good. I can confirm that cloud saves are working for me after updating the signing procedure and using optool as outlined in the Kittehface post!
Thank you once again for posting these scripts and guide, and continuing to support it… it’s been a massive help! Even after your need to engage personally with the trauma has subsided
You’re very welcome! We use it to though so until Unity gets macOS Xcode up and running any of your problems that get fixed will help us to in the future
Fixed development signing & readme which was signing with the wrong credentials
Fixed provisioning profiles mixup in readme & folder structure
There is now a separate development folder in /5_Entitlements to put your dev entitlements so you don’t need to change them between development and distribution builds.
Changed the folder structure in 7_Distribution to be less chaotic
Cleaned up the signing code
Various corrections and adjustments to make things more clear.
I’m following this as well to get iCloud working and everything signed. What a nightmare but I really appreciate this tool.
I’m having some troubles though, when I add the com.apple.security.app-sandbox entitlement it crashes with some log errors:
Sandbox deny file-read-data
Sandbox deny iokit-open IOAudioEngineUserClient
Sandbox deny network-outbound
If I remove the sandbox entitlement it runs but I can’t get iCloud to sync between iOS/tvOS and macOS. Most likely because they are running on different modes?
App sandbox is needed, I would guess that you’re missing entitlements, did you include read/write, and other keys described in the in the icloud entitlements example?
Are you building for development?
I’ve gotten signing to work now but I can’t seem to get my progress synced from my iOS build to my macOS build Have you gotten that to work (if you are using iCloud that way). And if so, HOW?!?
Not sure how things have changed with Notarising but before you uploaded your pkg with Xcode’s Application Loader.
not sure if you found your solution but another person had a similar crash and it was related to the iCloud container identifiers in the provisioning profile not matching the identifiers in the entitlements.
Have anyone tried to make a mac dev build for OSX 10.15 version and able to launch it using the Unity Appstore Distribution Workflow?
I tried to build it for almost a week and the closest I can get now is a code-signed app that launch and immediately close after 1 seconds without any error.
Here is the entitlement i used to code-signed the app, any idea?
Regarding the CODESIGNING, Code 0x1 crash.
We had the same crash when trying to make an app that uses the iCloud Key Value Stoarge. But the problem causing this was the ‘com.apple.developer.aps-environment => development’ entitlement from 5_Entitlements/Examples/Icloud_Development.plist. We never enabled APS/PushNotifications for our provisioning profile. We changed this to ‘com.apple.developer.icloud-container-environment => development’ before signing again, and the app runs now. It seem to sync with iCloud across mac/iOS devices without removing any .meta files or patching the executable to load CloudKit (we dont use CloudKit [yet]).
Have you verified it working between iOS/tvOS and macOS? I’m also only Key Value Storage but I just can’t get them to sync between by following any of these guides.
We able to make it work in OSX 10.14 and the iCloud Key Value Storage are shared across three platforms ( tvOS, iOS and Mac OSX ). In order for the app to be sync, they have to share the same id for “com.apple.developer.ubiquity-kvstore-identifier” in entitlements.plist.
For example, if your team id is ABCDE, and product id ( use the tvOS, iOS id ) is com.happycompany.fungame, then the com.apple.developer.ubiquity-kvstore-identifier value in entitlements.plist would be ABCDE.com.happycompany.fungame for tvOS, iOS and Mac.
I’m having issues with the signing step (with or without --deep doesn’t matter), I always get this error:
Afterwards, the verify step spits this out:
I found this issue and it seems the only way for me is to wait for Unity to update to 2019.2.3f2:
I sign with the distribution certificates and try to build for Appstore Distribution. Does anyone have similar issues/ are there any known workarounds for this?
Seems like this is a general issue with various unity version, that has nothing to do with this workflow.
Will post here once the issue cleared, in case others have the problem as well.
Hey, we noticed you found our blog post and pulled some stuff from it. Works for me! Building for App Store has been so much messier than we expected when we started.