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?

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.

Yep.

The dylibs end up in /Applications/OUR_APP.app/Contents/Resources/DYNAMICLIB.dylib

Yeah, don’t do that. Place these libraries in Contents/Frameworks. That’s the correct place for nested libraries, per the Nested Code section of Technote 2206 macOS Code Signing In Depth.

I believe this will still cause another warning from Gatekeeper?

I thought the plan was to distribute via the Mac App Store? If so, Gatekeeper isn’t a concern (well, it’s Apple’s concern because Apple is doing the final signing of your app).

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