Las directrices para desarrolladores de iOS de Apple establecen:

3.3.2 - Una Aplicación no puede instalar o lanzar otro código ejecutable por cualquier medio, incluso sin limitación a través del uso de una arquitectura de plug-in, llamando a otros marcos, otras API u otros. Ningún código interpretado puede ser descargado o utilizado en una Aplicación, excepto el código que es interpretado y ejecutado por las API documentadas de Apple y los intérpretes integrados.

Suponiendo que la descargadatos - como XML e imágenes, o una descripción de nivel de juego, por ejemplo - en el tiempo de ejecución está permitido (¿como es mi impresión?), me pregunto dónde dibujan la línea entre "datos" y "código". Imagine el escenario de una aplicación que ofrece "presentaciones" interactivas a los usuarios (como una encuesta, por ejemplo). Las presentaciones se agregan continuamente al servidor y las diferentes presentaciones se ponen a disposición de diferentes usuarios, por lo que no pueden ser parte de la descarga inicial de la aplicación (que sería el punto completo). Se describen en formato XML, pero al ser interactivos, pueden contener ramificaciones condicionales de este tipo (que se muestran en forma pseudo para ejemplificar):

<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>

Cuando este XML se interpreta y "juega" dentro de la aplicación, lo anterior se presentará en dos pasos. Primero se muestra una pantalla de selección, donde el usuario puede hacer clic en cualquiera de las dos opciones ("Hombre" o "Mujer"). A continuación, una imagen [se descargará dinámicamente] y se mostrará según la elección realizada en el paso anterior.

Ahora, a partir de esto, es fácil imaginar etiquetas adicionales, describiendo aún más la lógica. Por ejemplo, se podría agregar una etiqueta contenedora:

<loop count="3">

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

</loop>

El resultado aquí es que, por supuesto, el par pantalla de selección / pantalla de imagen se presentará de forma secuencial tres veces.

O imagina algún formato describiendo unnivel en un juego. Tal vez sea natural ver eso como "datos" pasivos, pero si incluye, digamos, varias puertas por las que el usuario puede pasar y con varios disparadores, trampas y puntos conectados a ellos, etc., no es lo mismo que usar un Script (o, de hecho, código interpretado): para describir secuencias de ejecución, opciones y sus respuestas condicionales.

Si se asume que el motor de interpretación de los datos ya está presente en la aplicación y que esas "presentaciones" solo pueden consumirse (no crearse o editarse) en la aplicación, ¿cómo se ajustaría esto a las pautas de iOS de Apple? ¿XML no constituye básicamente un lenguaje de secuencias de comandos en este sentido (no podría describirse un programa en un lenguaje interpretado en XML)?

¿Estaría bien si el lenguaje de scripting propietario (ref. El XML utilizado anteriormente) fuera estrictamente aislado (cómo pueden saberlo) y no se le da acceso al sistema operativo de ninguna manera (pero puede descargar contenido, como una encuesta o un juego)? nivel (dinámicamente, así como subir resultados (respuestas o puntuaciones) al servidor de creación)?

¿A dónde va la línea?