AppStore/iOS 应用程序和解释代码 - 他们在哪里划线? [英] AppStore / iOS apps and interpreted code - where do they draw the line?

问题描述

Apple 的 iOS 开发者指南规定:

Apple's iOS developer guidelines state:

3.3.2 — 应用程序本身不得以任何方式安装或启动其他可执行代码，包括但不限于通过使用插件架构、调用其他框架、其他 API 或其他方式.除了由 Apple 的文档化 API 和内置解释器解释和运行的代码外，不得在应用程序中下载或使用任何解释代码.

3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

假设允许在运行时下载数据——比如 XML 和图像，或游戏级别描述——是允许的(就像我的印象?)，我想知道他们在哪里绘制数据"和代码"之间的线.想象一下向用户提供交互式演示"(例如调查)的应用程序的场景.演示文稿不断添加到服务器，不同的演示文稿可供不同的用户使用，因此它们不能作为初始应用程序下载的一部分(这将是重点).它们以 XML 格式描述，但由于是交互式的，它们可能包含此类条件分支(以伪形式显示以进行示例):

Assuming that downloading data - like XML and images, or a game level description, for example - at run-time is allowed (as is my impression?), I am wondering where they draw the line between "data" and "code". Picture the scenario of an app that delivers interactive "presentations" to users (like a survey, for instance). Presentations are added continuously to the server and different presentations are made available to different users, so they cannot be part of the initial app download (which would be the whole point). They are described in XML format, but being interactive, they might contain conditional branching of this sort (shown in pseudo form to exemplify):

<options id="Gender">
    <option value="1">Male</option>
    <option value="2">Female</option>
</options>

<branches id="Gender">
    <branch value="1">
        <image src="Man" /> 
    </branch>
    <branch value="2">
        <image src="Woman" /> 
    </branch>
</branches>

当此 XML 在应用程序中被解释和播放"时，上述内容将分两步呈现.首先显示一个选择屏幕，用户可以在其中单击两个选项中的任何一个(男"或女").接下来，将根据上一步中的选择[动态下载] 并显示图像.

When this XML is interpreted and "played" within the app, the above would be presented in two steps. First a selection screen is shown, where the user can click on either of the two choices ("Male" or "Female"). Next, an image will be [downloaded dynamically] and displayed based on the choice made in the previous step.

现在，从这里，很容易想象额外的标签，仍然描述进一步的逻辑.例如，可以添加一个包含标签:

Now, from this, it's easy to imagine additional tags, describing further logic still. For example, a containing tag could be added:

<loop count="3">

    <options... />
    <branches... />

</loop>

当然，这里的结果是选择屏幕/图像屏幕对将按顺序显示三遍.

The result here being that the selection screen / image screen pair would be sequentially presented three times over, of course.

或者想象某种描述游戏关卡的格式.将其视为被动的数据"也许是很自然的，但是如果它包括用户可以通过的几个门，并带有各种触发器、陷阱和附加到它们的点等 - 这与使用脚本(或者，实际上，解释代码) - 描述执行序列、选项及其条件响应?

Or imagine some format describing a level in a game. It is perhaps natural to view that as passive "data", but if it includes, say, several doorways that the user can go through and with various triggers, traps and points attached to them etc - isn't that the same as using a script (or, indeed, interpreted code) - to describe execution sequences, options and their conditional responses?

假设数据的解释引擎已经存在于应用程序中，并且此类演示文稿"只能在应用程序中使用(不能创建或编辑)，这将如何违反 Apple 的 iOS 准则?从这个意义上说，XML 不是基本上构成了一种脚本语言吗(解释性语言中的任何程序都不能用 XML 来描述)?

Assuming that the interpretation engine for the data is already present in the app and that such "presentations" can only be consumed (not created or edited) in the app, how would this fare against Apple's iOS guidelines? Doesn't XML basically constitute a scripting language in this sense (couldn't any program in an interpreted language be described in XML)?

如果专有脚本语言(参考上面使用的 XML)被严格沙盒化(他们怎么知道?)并且没有以任何方式访问操作系统(但能够下载内容 - 就像调查一样)或游戏级别 - 动态以及上传结果 - 答案或分数 - 到创作服务器)?

Would it be OK if the proprietary scripting language (ref the XML used above) was strictly sandboxed (how can they tell?) and not given access to the operating system in any way (but able to download content - like a survey or a game level - dynamically as well as upload results - answers or scores - to the authoring server)?

线路去哪里了?

推荐答案

自 WWDC 2017 起更新

现在明确允许诸如下面提到的 Codea 之类的编程工具下载代码.App Store 指南目前说(强调我的):

Programming tools such as Codea mentioned below are now explicitly allowed to download code. The App Store Guidelines currently say (emphasis mine):

2.5.2 应用程序应自包含在其捆绑包中，不得在指定的容器区域外读取或写入数据，也不得下载、安装或执行代码，包括其他应用程序.旨在教授、开发或测试可执行代码的应用程序可以在有限的情况下下载代码，前提是此类代码不得用于其他目的.此类应用必须使应用提供的源代码完全可供用户查看和编辑.

2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other apps. Apps designed to teach, develop, or test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.

还有 这条推文 引用了有关宽松条款的更多详细信息.

There is also this tweet citing more details on the relaxed clauses.

原创

您的解释下载是否允许用户编写无限循环或递归?

Does your interpreted download allow the user to write infinite loops or recursion?

Apple 允许 Javascript，因为它们提供了解释器并且可以杀死您的代码.我有一种感觉，我读过它有 10 秒的限制，但我在网站上搜索了几分钟就找不到它.(是的，我自己设置的写答案超时.)

Apple allow Javascript because they provide the interpreter and can kill your code. I have a feeling I've read that it's a 10 second limit but I couldn't find it on the site with a few minutes searching. (Yes, my self-imposed timeout for writing an answer kicked in.)

如果您所做的是声明性的并且不允许在解释器中出现明显的循环，我认为您是相当安全的.

I think you're pretty safe if what you do is declarative and doesn't allow obvious looping in the interpreter.

我也会避免在 Apple 可见的任何描述中使用解释器"这个词，包括公开讨论.也许解析器"会更安全.

I would also avoid the use of the word "interpreter" in any descriptions visible to Apple including public discussion. Maybe "parser" would be safer.

Codea 的 Lua 环境已经在这些定义的边缘滑过，无法下载代码.他们必须删除一项功能，以便将新软件包下载为.codea"" 文件.

Codea have skated along the edge of these definitions with their Lua environment and cannot download code. They had to remove a feature for downloading new packages as ".codea" files.

这篇关于AppStore/iOS 应用程序和解释代码 - 他们在哪里划线?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！