acm*_*acm 6 c++ code-signing dylib ios
如果有人提出并回答了这个问题，我深表歉意。将其重定向到可以回答这个问题的规范资源将是非常不错的。
我最近收到了一个请求，要求提供我为iOS维护的项目的构建，这不是我熟悉的平台。特别是，我不是应用程序开发人员，从未向App Store提交过应用程序，等等。该项目提供了标准的C ++ 11 SDK：某些标头和某些库，已安装为autoconf样式$PREFIX/include和$PREFIX/lib目录。要满足请求，就需要提供针对iOS的预构建二进制文件和标头。出于本文的目的，假设我可以限制为更新的iOS，例如iOS 10.2+。
对于非IOS开发人员而言，此SDK的典型交付方式传统上是作为标头和一组动态链接的库。该项目是围绕动态链接设计的，因此对于许多用户来说效果很好。
但是，我的搜索导致关于是否完全可以在iOS上以这种方式使用动态库以及如果打算提供以iOS为目标的SDK时正确的传递机制/格式是什么的信息相互矛盾。
我有几个问题：
第一个问题：完全有可能提供一个包含动态库（dylib）的SDK，以便应用程序开发人员可以针对该SDK构建其应用程序，并将dylib与他们的应用程序打包在一起，从而产生一些可以包含在应用程序中的东西商店。
第二个问题：如果以上问题的答案为“是”，是否有具体限制？我已经看到一些信息，表明只有当动态库形成框架（框架捆绑包？）时，才有可能。有人知道我可能会以此模型发布的任何开源SDK吗？
第三个问题：如果我要交付静态SDK，我相信作为SDK开发人员，代码签名对我来说不是问题，因为应用程序开发人员使用自己的密钥对最终生成的工件进行签名，并且由于它们也在签名，因此可以正常工作他们从静态库中获取的任何位。在我看来，如果有可能交付动态SDK，那么对工件进行代码签名的负担就会转移到我身上。我有正确的吗？是否可以交付其中不同部分具有不同签名密钥的应用程序（例如，如果我签名SDK dylib，并且应用程序开发人员签署了他们的应用程序位，情况就是这样）？
第四个问题：将SDK作为dylib交付会对希望为其构建应用程序的人们的可用性产生不利影响吗？如果是这样，怎么办？
请注意，我并不是在问是否可以使用dlopen一个库，还是下载动态代码并使用它等等。我的理解是，出于相当明显的原因，那是禁止的。这里的用例旨在使开发的应用程序具有引用SDK dylib的显式加载命令。同样，我也不想绕过Apple的任何限制：我只是想得到一个答案，让我知道什至尝试将这个SDK作为一组dylib交付是否有意义，或者是否应该重定向我的致力于生成静态版本的SDK。
您可以使用以下代码共同设计您的库
codesign -s <Identity> libyourlib.dylib
将其添加到您的应用程序中，并通过 加载它dlopen。这至少在技术上应该可行。我不确定，但我认为 Apple 可能不会让你的应用程序通过 App Store。如果这对您来说是最简单的方法，您应该尝试一下。dlopen注意：Apple并不禁止在iOS中使用，他们甚至建议将其用于弱链接。
共享框架的主要部分是动态库。因此，您可以使用 Xcode 创建一个框架，将构建结果复制到您的项目中，并将包含的二进制文件替换为动态库的通用二进制文件。创建应用程序包时，代码签名应由 Xcode 自动完成。由于 Apple 正式支持 iOS 上的共享框架，因此他们将通过 App Store 发布此解决方案。
如果您可以生成库的静态版本：您可以在 Xcode 中创建一个共享框架，并将其与您的静态库链接到-all_load. 这至少为您提供了一个共享框架。
注意：仅当有多个二进制文件（例如应用程序和扩展）使用共享框架或库时，将共享框架或库包含到 iOS 应用程序中才有意义。如果只有应用程序使用该库，那么使用共享框架/库通常没有优势（节省空间和内存）。