CODEWITHSUNDEEP
macosqtnotarize
p_Each
p_Each

Reputation: 21

Mac app notarization successful but spctl assessment rejects app because of Qt Frameworks

We are currently trying to have our app verified in order to distribute it outside of the app store. We are including OpenSceneGraph libraries as well as Qt frameworks in the app bundle.

This is how we did it so far:

The executable, libraries and frameworks signing is done manually with the codesign command, and to sign the whole .app we do the following:

codesign --force --verify --verbose=3 --options runtime --timestamp --entitlements App.entitlements -s "Developer ID Application: Our Dev Id" App.app

When we send the zipped .app to be notarized we usually get a quick reply informing us that the notarization was successful, but if we try to run spctl --verbose --assess --type execute -v App.app we get the following error:

App.app: rejected (unsealed contents present in the root directory of an embedded framework)

Also inspecting the json file with the notarization output we notice the same error, but it is marked as a warning and checking it with codesign no error is returned.

After a bit of digging we realized that the issue is related to the Qt frameworks: as a counterproof, we tried to submit the same app without the Qt frameworks and this time when the bundle was successfully notarized spctl accepted it too. Consequently, we eliminated the all symlinks in the root directory, moved the .prl files into the Resources/ folder, and created an alias to A/ in the Versions/ subfolder as suggested in several forum posts, but we have not been able to have spctl accept our bundle with the Qt frameworks. Now at the root of each framework there is just the Versions folder and nothing else (we checked with ls-lha to be sure)

What are we missing in this? Is there a way to at least get some hint on where is the unsealed content which is upsetting the verification tool?

Thank you in advance

Upvotes: 0

Views: 1529

Answers (1)

p_Each
p_Each

Reputation: 21

In the end, turns out macdeployqt was the way to go, because it automatically arranges the Frameworks in a way that makes it possible to sign the bundle with no error.

Our problem with some framework not being added by macdeployqt disappeared when we upgraded from Qt 5.12.2 to Qt 5.14.1

Upvotes: 2

Related Questions