在阅读了广泛的App Store指南（特别是mac app store）之后，我发现了一个矛盾....
一方面，在功能性下，它明确指出：
2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected
然而，当你进一步阅读有关购买类型的信息时，它通常是指在App Purchase'下载'中，我很确定我记得在捆绑开发指南（特别是插件开发）中阅读这些可以被视为在app中购买？
在上面的2.7和2.8中，他们是指他们没有检查的代码，即myAppPurchase.bundle，这是在应用程序提交时没有提交的，或者这是具体的，绝对没有被Apple检查或取消选中的包可以是完全下载了吗？
简而言之，应该是一个完整的应用程序创建，即所有“应用程序内购买额外”还是可以模块化完成，即应用内购买从应用商店下载批准的捆绑包？
干杯，
A
答案 0 :(得分：2)
虽然您可以下载内容进行应用内购买，但不允许下载代码以便以后合并到应用程序中。有一些理论上的边缘情况，因为你可能有自己的解释器，可能能够下载一些可解释的代码，在这种情况下，你不能下载将作为一部分执行的本机代码应用程序（插件）或外部启动的应用程序。
至于为什么Apple会在文档中介绍这个问题，可能是因为OS X和iOS应用程序存储在文件系统中的方式。在Apple决定允许可下载的二进制可执行文件之前，我们只在OS X中使用插件包，而非操作系统框架包也是如此，这可能会更有用。特别是，我们有一些iOS / OSX跨平台的捆绑包，我们必须在iOS下静态链接，这是一种耻辱。
Apple的明显看法是，如果我们可以动态加载代码，那么通过在初始（或后续）程序加载后下载有问题的代码模块来规避审查过程是一个机会。例如，想象一下，一个与服务器通信以下载违反Apple指南之一的代码的应用程序。如果发出请求的版本尚未被恶意开发人员“释放”，则不会返回任何代码，只是看起来它正在检查某种信息性消息。但是，一旦Apple批准该应用程序，开发人员就会告诉服务器开始发回动态库，框架或插件，然后由现在的恶意代码在适当的时间执行。
难点是为了防止这种情况发生（通过dyld或类似），您需要将可以加载的所有内容列入白名单，或者您只需要完全阻止应用程序代码使用它。
未来有可能会使用某种经批准的代码白名单，但在此之前，Apple显然选择了阻止使用非系统框架动态链接的途径。