Trying to find some advice on how to deal with OSX. Currently we are distributing our game outside of App store and without doing any code signing..... and gatekeeper is the bane of my life. It randomly removes the execution flag when we do patches, it quarantines the .zip file when users download our game. I've had enough of it and want to circumvent it. From what I have read we can code sign to bypass gatekeper or we can distribute via the app store (which also involves code signing). I am struggling to find good information on code signing a Unity application and staying outside of Apple store - is this a good idea, will it be problem free? Is there even any good information on this as I'm yet to find anything I can understand - I'm not an OSX user, so the apple ecosystem is fairly new to me. Is there a guide somewhere on how to code sign a Unity application for OSX, are there any reliable automated tools to make it easy? I even struggled working out how to get a code signing ID as Apple's webpages on the subject are circular in nature so you follow the hypertext links and end up back where you started and no wiser - so frustrating. Would appreciate a bit of guidance from someone who has suffered this pain already.
Yes, we code-sign High Frontier and distribute it through our own store. And in fact, since it's a cross-platform app, we also code-sign the Windows binary on our Mac build machine, as described here. We do it all through the Unix command line. Here's the shell script that does all the heavy lifting for the Mac version (only slightly sanitized, and reduced to deal with just one app — our real script does both the demo and full versions of the game): Code (CSharp): #!/bin/bash cd /Users/blah/blah/Build/Mac echo 'Clearing "Untouched" versions...' rm -rf *Untouched* echo 'Code-signing Mac full build...' codesign --deep -f -v -s "Developer ID Application: Strout and Sons, LLC" HighFrontier.app codesign --deep --verify --verbose HighFrontier.app echo 'Zipping Mac full build...' rm HighFrontier-Mac.zip zip -r HighFrontier-Mac HighFrontier.app So, basically, the codesign (that's code-sign, not co-design!) command is what you're looking for. It digs up your private key from the keychain, where it'll be installed if you've managed to follow Apple's (confusing) guidelines, and uses it to sign the app package. Then we just zip it up for distribution. Some people prefer to deliver on a disk image, but as a user, I'd just as soon have a zip file rather than a disk image I have to mount, drag stuff out of, unmount, and then throw away.
Very helpful thanks, so we just have to go jump through the Apple hoops to get our code signing id and then the above can be applied?
Yes, that's right. But it's easier than in the Windows world... you wouldn't believe the rigamarole I had to go through to get my CODOMO certificate!
got the apple cert through today and appear to have code signed without issue. One thing we aren't sure about is if you zip a code signed app does that stop the archive from picking up the quarantine flag if you then host that zip on goolge drive or a web host for download?
No, it's fine. Once the zip file is unzipped, Finder will see that the app is signed and not bug the user about it.
Interesting time we have had with code signing. Because we don't distribute through the Apple Store any zip file we provide gets quarantined (even if we have signed it all). However, we have discovered that if we package using a signed .dmg file then although it downloads as quarantined on first open it verifies and removes the quarantine. At this point we can run fine with full disk access which we can't do using zip distribution as we get moved to a safe read only area due to the quarantine flag.
Interesting! That's not something I've ever noticed with our game (but then, it's not trying to get full disk access — it uses only a folder in Application Support). But perhaps it explains why so many apps are distributed as .dmg files!
I'm not sure what the subtle difference is between .dmg and .zip for one to follow a different security policy to the other, logically either one could run malicious code (which I'm told is the point of the quarantine). I'm just grateful one way works as we were looking like ending up in the Apple Store (hell no!).
Hey JoeStrout: Thanks for the script! I'm trying to do the exact same thing as well. I keep getting "no identity found" with respect to my cert, which I assume means I'm not naming it correctly or it's not in the right place. Do you have any tips on installing and naming the cert so codesign command can find it?
I'm afraid not — except I guess to go back through Apple's guidelines on where/how to install developer certificates.
I know I'm resurrecting an old thread but I'm attempting to do the exact same thing as what JoeStrout here does with his script and somehow any attempt I make to sign the .app manually from the command line is met with the following error message: Code (CSharp): Test.app: code object is not signed at all In subcomponent: /Users/XXX/Workspace/XXX/XXX/Build/OSX/XXX/Test.app/Contents/Frameworks/libssl.dylib I haven't been able to find much results when looking up that error message, anyone has experienced a similar issue.
I haven't met the error you are having, but sometimes the --deep command doesn't sign everything and you have to sign everything manually. We’ve written an automated workflow / guide to prepare distribution for OSX (from start to finish) in and outside of the Appstore together with an extensive guide I would suggest reading it. The code to do it manually is also included and I would suggest you read up at signingpackage if you scroll up a bit it shows what other packages to sign. Good luck! You can read the full text guide with DIY here and get the full here. You can find the Unity forum thread here.
@UNSH Thanks for the in depth guide. It looks great and all the steps seemed to work fine, but after installing the resulting Mac App Store package and running it, I get a crash with a "EXC_CRASH (Code Signature Invalid)" exception. I tried removing all the .dylibs/.bundles and signing/packaging the app with the following: Code (CSharp): codesign -f --deep -s "3rd Party Mac Developer Application: COMPANY_NAME (ID)" --entitlements "my.entitlements" "My.app" productbuild --component "My.app" /Applications --sign "3rd Party Mac Developer Installer: COMPANY_NAME (ID)" "My.pkg" I made sure there were no other builds of the same app on my computer before installing. Is there any way to figure out which file is causing this? Any other suggestions that I could try to find the root cause? I'm trying this on a build using Unity 2019.2.21
Not sure but the guide is behind again. You need a different certificate now the guide doesn't describe that yet, but that's a good start (link) because it will give code signing errors. We should update the guide but it's a frustrating endeavour because things change all the time and we don't build enough for macOS.
I know what you mean, it doesn't seem like Mac App Store distributions are something people do too often with Unity builds. Otherwise maybe Unity would put some time into updating their docs as well (https://docs.unity3d.com/Manual/HOWTO-PortToAppleMacStore.html). Following those steps does not result in a valid build for me (even when removing all plugins/frameworks). It looks like the issue in the link you mentioned is for Developer signed apps, so that doesn't apply to me unfortunately (I'm signing with Distribution cert).
Sorry for the late reply. No I believe it does if you are using Catalina with Xcode 11.2 It's a new cert also for Appstore distribution. If you look closely there's "Mac App Distribution" (the old cert) and the Apple Distribution. In any case there's so many variables that it's difficult to say where you made a mistake but since you get a code signature invalid I would say it's either the certs, and subsequently your profile, the signing identity or if you are using extra features like icloud or something that's not set up correctly (resulting in an incorrect provisioning profile). It's difficult to say as it's even tough to remember all the steps, I would go over the guide and double check everything and keep trying. I know it's like giving birth to a rock but there's no other way since the error logs are pretty generic and there's a ton of variables that can be set up wrong. There's hopefully light at the end of tunnel with Unity's Xcode builds.
What about just for distributing internally - do you use a development certificate? I give people a Mac build and (particularly if zipped) it fails to run on people's Macs unless they hack settings in the terminal and/or allow it through privacy settings. I just want it to be recognized as non-harmful, but do not need an app setup for it, as not going on any store notorization via a terminal is like a foreign language to me coming from a windows background, very unfriendly!
They don't have to allow it through privacy settings. All they have to do is, the first time, right-click the app icon and choose "Open" from the contextual menu, and then click the "Open" button in the warning dialog that appears. Once they've done that once, Finder will remember and they can just double-click it as usual after that. Most Mac users are savvy to this, because unsigned apps are still fairly common.
I wish that were the case, but in Catalina there is no open button in warning dialog on right-click open and if sent by zip it just doesn't open There was a whole thread on this: https://forum.unity.com/threads/the-application-cannot-be-opened.404388/
Well, that hasn't been my experience (I'm both building on Catalina and distributing to Catalina users), and I see nothing in the thread that says so. (But it does point out that if you're building on Windows, you will need to take some pains to make sure the execute bit is set on the executable.)
I do, yes. But I do believe that if you are going to sign your app, it works better if you ship it on a signed disk image as well.
@andyz one minor point ... in Big Sur they added a ridiculous thing: - traditionally if you right-click (I mean ctrl-click) then select Open from the context menu - it will bypass security. - in BigSur, you have to do that TWICE (!) the first time it gives an erase warning. but the second time it works traditionally, you get the 'Open' context menu option! hope it helps
Anybody also noticed any trouble when building for macOS and distributing with a zip file download? I'm quite puzzled, because my older builds still work when downloaded from the webpage. After some investigation I found out that when I build with architecture "Intel 64-bit + Apple Silicon" selected, I can run the build on my laptop, but when I zip, upload, download, unzip it, Big Sur complains that the object is damaged and gives the option of putting it in the trash. A bit-wise comparison of the original (locally created) zip file and the downloaded zip file show that they're identical (as in: the MD5 hash is identical), but after unpacking the downloaded zip file, it just doesn't work. Is that maybe also related to code signing and mac os whining about downloaded stuff?
Apple are ridiculous at this point. A signed, notarized app will not want to run if distributed in a zip, if you force it to it will run in a quarantined location. You need to make a pkg installer, sign that (!!) And then distribute like that
@tjmaul note, there is now a stupid thing in MacOS ... try to open it using right-click (ie ctrl click), select Open from small menu BUT do that TWICE :/ that's Apple's new security. idiots.
Thanks @Fattie, I tried but that only works if I don’t do a “Intel 64-bit + Apple Silicon” build. I’ll try this notarization that @andyz mentioned tomorrow or next week and come back to you. Oh, it’s a pain. :/
I did try notarizing but it failed. Since that's another issue, I continued here in case anyone is interested. Thanks for the help up to here. I hope we'll figure that out. I'll come back with my findings once notarization issues are out of the way.
This is true, you can still open uncertified apps but I found it was running with 'trans-location' - in a random quarantined location which stopped the local file access I needed. The decent packaging app (WhiteBox - Packages (free.fr)) is uncertified and has the same issues. You have to manually give it full disk access!
Just for the record to see that the download is not actually broken: the downloaded .app works if I execute the following command sudo xattr -r -d com.apple.quarantine /path/to/MyApp.app
@tjmaul - gotchya, you have to do “Intel 64-bit + Apple Silicon” as you say Regarding doing a real notarization build - that does seem incredibly complicated!! I hope someone can pull it off! @andyz - interesting, thanks for that tidbit!
I did get my build notarized and it runs now after it's been downloaded from the internet, but it did require manual signing of some libraries. I guess this is something that needs fixing on Unitys side. Here's the post on the other thread: #14 The notarization itself is pretty straightforward. Just follow this gist: https://gist.github.com/dpid/270bdb6c1011fe07211edf431b2d0fe4