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