Dear Apple folks,
we develop a C++ application that depends on another 3rd party
library which is installed under /Library/frameworks.
This library is optionally loaded dynamically at runtime by a call to
So far, we have signed our application successfully with our
Developer ID Application certificate.
For notarization, we have enabled the hardened runtime option in our
application signature process.
With hardened runtime enabled, this library loading does not work
anymore on MacOS 10.14 and 10.15.
Following the Apple documentation and several developer forum threads
I have already checked the following constraints:
* The application is signed using a secure timestamp.
* The application is signed without using the option 'deep'.
* The 3rd party lib is signed by it's vendor with their Developer ID
* The lib's deployment target is MacOS 10.9 or higher
* The lib's installation name is fixed under /Library/Frameworks.
(LC_ID_DYLIB, calling otool -l on the lib, is this correct?).
* As the lib uses another certificate than the application, the
application enables the disable-library-validation entitlement.
This has been checked via codesign -d --entitlements :- on the app.
* Enabling all hardened runtime related entitlements for test purposes
does not help.
To be clear again:
* A signed application without option 'hardened runtime' loads the lib
* A signed application with option 'hardened runtime' enabled and all
related entitlements enabled fails loading the lib.
I do not see any relevant error messages so far:
* If the application is executed from a terminal, it does not produce
any error output.
* The system log does not produce related messages (or I do not see them).
* I do not see any dyld related messages (Where should I find them?).
* codesign --verify --verbose=4 APP_BUNDLE says 'valid on disk'.
* spctl --verbose?4 --assess --type execute APP_BUNDLE says 'accepted'.
So, how can I gather more information from the system about why it
forbids to load the lib?
Do you have any other ideas for me?