iOS SDK是否可以随动态库一起提供

Question

如果有人问过并回答了这个问题，我很抱歉--如果能重定向到一个回答这个问题的规范资源，那就太好了。

我最近收到一个请求，要求提供我为iOS维护的一个项目的构建，这不是一个我非常熟悉的平台。特别是，我不是一个应用程序开发人员，从来没有提交过应用程序到应用程序商店等。该项目提供了一个标准的C++11软件开发工具包:一些头文件和一些库，安装到autoconf样式的$PREFIX/include和$PREFIX/lib目录。满足请求需要提供针对iOS的预先构建的二进制文件和头文件。为了这篇文章的目的，假设我可以限制在较新的iOS上，比如iOS 10.2+。

对于非IOS开发人员，此SDK的典型交付模式传统上是作为头文件和一组动态链接库。该项目是围绕动态链接设计的，对于许多用户来说工作得很好。

然而，我的搜索导致了非常矛盾的信息，关于是否有可能在iOS上以这种方式使用动态库，如果是的话，当打算交付针对iOS的SDK时，正确的交付机制/格式是什么。

我有几个问题：

第一个问题:有没有可能提供一个包含动态库(Dylib)的SDK，这样应用程序开发人员就可以根据SDK构建他们的应用程序，并将dylib与他们的应用程序打包在一起，生成一些可以包含在App Store中的东西。

第二个问题:如果上述问题的答案是“是”，是否有具体的限制？我已经看到一些信息表明，如果且仅当动态库形成框架(Framework Bundle?)时，这是可能的。有没有人知道有没有开源SDK以这种方式发布，我可以将其作为模型使用？

第三个问题:如果我要发布一个静态SDK，我相信作为SDK开发人员，代码签名对我来说不是问题，因为应用程序开发人员使用自己的密钥对最终生成的工件进行签名，而且这是有效的，因为他们还会对从静态库中获得的任何位进行签名。在我看来，如果有可能提供一个动态SDK，那么共同设计工件的负担就会转移到我身上。我没记错吧？是否有可能交付一个不同部分具有不同签名密钥的应用程序，就像我对SDK dylib签名，而应用程序开发人员对其应用程序位进行签名的情况一样？

第四个问题:将SDK作为dylib交付是否会对希望基于它构建应用程序的人的可用性产生不利影响？如果是这样的话，是怎么做的？

请注意，我不是明确地询问是否可以dlopen一个库，或者下载动态代码并使用它，等等。我的理解是这是被禁止的，原因很明显。这里的用例旨在使开发的应用程序具有引用SDK dylib的显式加载命令。同样，我也不想绕过Apple的任何限制:我只是想要一个答案，让我知道尝试将这个SDK作为一组dylib交付是否有意义，或者我是否应该将精力重新定向到生成SDK的静态版本上。

Answer 1

你可以用来设计你的库

codesign -s <Identity> libyourlib.dylib

将其添加到您的应用程序中，并通过dlopen加载。这至少在技术上应该是可行的。我不确定，但我认为苹果可能不会让你的应用程序通过app Store。如果这对你来说是最简单的方法，你应该尝试一下。注:苹果并没有禁止在iOS中使用dlopen，他们将其用于弱链接。

Shared Framework的主要部分是动态库。因此，您可以使用Xcode创建一个Framework，将构建结果复制到您的项目中，并用动态库的通用二进制文件替换包含的二进制文件。代码签名应该在创建App bundle时由Xcode自动完成。由于苹果官方支持iOS上的共享框架，他们将允许这个解决方案通过App Store。

如果您可以生成库的静态版本:您可以在Xcode中创建一个共享框架，并使用-all_load将其链接到您的静态库。这至少给了你一个共享的框架。

注意:只有当有多个二进制文件(例如，应用程序和扩展)将使用它时，才能将共享框架或库包含到iOS应用程序中。如果只是应用程序使用库，那么使用共享框架/库通常没有优势(节省空间和内存)。