Load dylibs signed by different team

I presume that this is related to your other question. If so, there’s two possibilites here:

• These libraries are included in the app you submit to the App Store. In that case you should sign them with your own signing identities before submitting. This makes sense when you think about it: You are responsible for putting this code on the user’s system, and you indicate that by signing it with your signing identity.

• These libraries are coming from elsewhere. That should never crop up in an App Store app because, as I explained on your other thread, App Review’s guidelines make it clear that your app should not be downloading code.

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

Hello Quinn,

 Thanks for the quick reply. Yes, both questions are related. The reason we're downloading the dylibs from our servers and loading using dlopen() is that our vendor releases these dylibs very often for fixes. So, if that's the case, our users can get the fix almost immediately whenever new dylibs are available (without having to update the entire app). 

However, I think we'll have to take the approach of embedding these dylibs in our app itself and increase the app's release frequency. The only drawback is that the end users will have to wait for a few extra days for the fix (because of the submission to app store/approval etc). 

I can embed the dylibs in our project and say "embed and sign" so that it'll be signed with our certificate. The dylibs end up in /Applications/OUR_APP.app/Contents/Resources/DYNAMICLIB.dylib. Then, load them using "[NSBundle mainBundle] pathForResource:" 

codesign -dvv of dylibs at /Applications/OUR_APP.app/Contents/Resources/DYNAMICLIB.dylib shows this :

Authority=Apple Mac OS Application Signing Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA 

So, i believe there shouldn't be any conflict in our main app loading a different team's library. 

However there's one final question. spctl shows this : 

spctl -a -vv -t install /Applications/OUR_APP.app/Contents/Resources/DYNAMICLIB.dylib 

DYNAMICLIB.dylib: rejected

origin=Apple Mac OS Application Signing

I believe this will still cause another warning from Gatekeeper? Do we have to notarise DYNAMICLIB.dylib even though it's embedded in the app?

Hello Quinn,

Thanks for the quick reply. Yes, both questions are related. The reason we're downloading the dylibs from our servers and loading using dlopen() is that our vendor releases these dylibs very often for fixes. So, if that's the case, our users can get the fix almost immediately whenever new dylibs are available (without having to update the entire app). 

However, I think we'll have to take the approach of embedding these dylibs in our app itself and increase the app's release frequency. The only drawback is that the end users will have to wait for a few extra days for the fix (because of the submission to app store/approval etc). 

I can embed the dylibs in our project and say "embed and sign" so that it'll be signed with our certificate. The dylibs end up in /Applications/OUR_APP.app/Contents/Resources/DYNAMICLIB.dylib. Then, load them using "[NSBundle mainBundle] pathForResource:" 

codesign -dvv of dylibs at /Applications/OUR_APP.app/Contents/Resources/DYNAMICLIB.dylib shows this :

Authority=Apple Mac OS Application Signing Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA 

So, i believe there shouldn't be any conflict in our main app loading a different team's library. 

However there's one final question. spctl shows this : 

spctl -a -vv -t install /Applications/OUR_APP.app/Contents/Resources/DYNAMICLIB.dylib 

DYNAMICLIB.dylib: rejected origin=Apple Mac OS Application Signing

I believe this will still cause another warning from Gatekeeper? Do we have to notarise DYNAMICLIB.dylib even though it's embedded in the app?