c++ - iOS SDK 是否可以与动态库一起交付

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

3年前关闭。




Improve this question




如果有人问过并回答过这个问题，我深表歉意 - 重定向到回答这个问题的规范资源会很棒。

我最近收到一个请求，要求提供我为 iOS 维护的项目的构建版本，这不是我非常熟悉的平台。特别是，我不是应用程序开发人员，从未向 App Store 等提交应用程序。该项目提供了标准的 C++11 SDK:一些头文件和一些库，安装为 autoconf 样式 $PREFIX/include和 $PREFIX/lib目录。满足请求需要提供针对 iOS 的预构建二进制文件和 header 。假设出于本文的目的，我可以限制为较新的 iOS，例如 iOS 10.2+。

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

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

我有几个问题:

第一个问题:是否有可能提供一个包含动态库 (dylibs) 的 SDK，以便应用程序开发人员可以针对 SDK 构建他们的应用程序并将 dylibs 与他们的应用程序一起打包，从而产生一些可行的内容以包含在应用程序中店铺。

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

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

第四个问题:将 SDK 作为 dylib 提供是否会对希望针对它构建应用程序的人的可用性产生不利影响？如果是这样，如何？

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

Answer 1

您可以使用

codesign -s <Identity> libyourlib.dylib

将其添加到您的应用程序中，并通过 dlopen 加载它.这至少应该在技术上起作用。我不确定，但我认为 Apple 可能不会让您的应用通过 App Store。如果这对你来说是最简单的方法，你应该试试这个。注意:Apple 不禁止使用 dlopen在 iOS 中，他们 even recommend它用于弱链接。

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

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

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