Invalid Code Signature Mac App

Question

Created Feb ’21

Replies 5

Boosts 0

Views 2.9k

Participants 2

Our game is build with Unity 3d (Version 2020.2) after building in unity, then again in XCode the build works perfectly fine on the machine I'm using. I then Archive the project, and attempt to distribute the app using the development option so our QA can test it before submission. After export and uploading to dropbox, when our QA downloads the app they get an error saying the app needs to be updated and the attached crash log says that there is an invalid code signature on the UnityPlayer.dylib as well as .app/Content/MacOS

When I download the same app on the machine I built it on, I get an error that says Apple cannot detect if it is malicious, but if I right click and go to Open I can run the app just fine on that machine.

I've double checked that the devices UDID's are in the Development provisioning profile and that I'm using the proper development Certificate for signing, as I tested multiple variations of certificates and profiles all with the same result.

We can't do a Development ID option as our app is for the Arcade and needs Game Center and Cloud Kit which from everything I've read Development ID distributed apps do not have access to these capabilities.

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’21

There seems to be two problems in play here:

On your machine your app is not passing Gatekeeper. This is expected because it’s Development signed.
On your QA machines the system is blocking the execution of your apps for some reason. The most common reason for this is that the target Macs are not included in your provisioning profile, but you seem to have ruled that out.

Quick question: When you sign the app, do you end up with entitlements applied to things other than the main executable. Try this:

Code Block  % codesign -d --entitlements :- /path/to/your.app
% codesign -d --entitlements :- /path/to/your.app/Contents/Frameworks/your.dylib

The first should output your entitlements. The second should list no entitlements.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

Methanier OP

Feb ’21

Well When I go to Export the app during the Distribute app part in xcode it shows what's signed etc. One thing I noticed is that on the main .app is shows both the certificate and the profile listed, but when I click on the other things (UnityPlayer.dylib etc) it only lists the Certificate. It says there's no profile attached to the signature.

I just got done running that command on the 4 different frameworks/plugins that show up (UnityPlayer.dylib, GameAssembly.dylib, UnityFbxSDKNative.bundle, and a custom bundle. The FbxSDKNative.bundle is not signed according to XCode so when running those commands that is the only one that doesn't show anything. When running it on everything else, it shows the full list of entitlements that the main .app shows when running the command on that.

So Both commands output entitlements.

0

Answer 3

DTS Engineer OP

Apple

Feb ’21

One thing I noticed is that on the main .app is shows both the
certificate and the profile listed, but when I click on the other
things (UnityPlayer.dylib etc) it only lists the Certificate.

That’s expected. Provisioning profiles are associated with the app as a whole, not with each individual chunk of code within the app.

The FbxSDKNative.bundle is not signed according to XCode so when
running those commands that is the only one that doesn't show
anything.

If that bundle contains any code, it must be signed.

Oh, just to be clear, you’re running the command against the built app, right?

So Both commands output entitlements.

That didn’t come through. You have a couple of choices for posting large chunks of preformatted text here on DevForums:

For inline display, add a triple backtick line before and after the text.
For out-of-line display, use the text attachment feature (the paperclip icon).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 4

Methanier OP

Feb ’21

Yes I ran the commands against the built app, also after going back and forth with one of Unity's developers on their forums we found that in order to get the app to run on another device, we had to have the QA person install the embeded.provisioningprofile that is within the .apps contents folder. Once that was done QA was finally able to run the app.

Also the line

So Both commands output entitlements

was the final statement of my last reply I was just stating that it showed entitlements listed when running both commands you asked me to run.

0

Answer 5

DTS Engineer OP

Apple

Feb ’21

I was just stating that it showed entitlements listed when running
both commands you asked me to run.

Shot.

we had to have the QA person install the embeded.provisioningprofile
that is within the .apps contents folder.

And chaser!

Before we start, some background on entitlements:

Entitlements are only effective when applied to a main executable. When the system starts a process running that executable it gives that process those entitlements. In this context the entitlements applied to any libraries are ignored.
Certain entitlements are restricted, that is, they must be explicitly allowed by a provisioning profile. Your Apple Arcade entitlement is a prime example of this.
The previous point is true even if the entitlement is applied to something that’s not the main executable.

So, here’s what’s happening:

When you launch the app the system checks its entitlements.
The entitlement check for your main executable passes because of the embedded profile.
The entitlement checks for your various libraries fail because the system can’t find their profile (you could in theory give each library its own embeded.provisioningprofile but that’d be quite silly).
When you install the profile in System Preferences > Profiles the system can find the profile and these checks now succeed.

The solution here is to only apply entitlements to your main executable. After all, that’s the only place where they do any good, and applying them elsewhere can actively cause harm.

Most folks who hit this problem do so because they’re using --deep. I recommend against that, as explained in --deep Considered Harmful. Rather, you should sign each component separately. For an example of this, see Manual Code Signing Example. And for general advice on how to sign, see Signing a Mac Product For Distribution.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0