iOS interpreted code

Apple's iOS Developer Program License Agreement (official version here – login required; publicly available copy here) forbids the use of "interpreted code" in an application unless

The first exception clearly allows the use of iOS interpreted code, provided the interpreter is used purely for technical convenience – the app could have been written with executable code, and the restrictions on executable code are applied to the interpreted code as well. The second exception allows HTML5 integration into apps, provided this isn't used to morph the app into something else.

Seems reasonable at first glance, right? There are, however, problems that arise.

First, one of the reasons for using interpreted code is that it allows a more rapid and user-friendly update cycle. This is not only because of the well-known rapid prototyping feature of interpreted languages, but also because the script itself may be easily modularized and only affected scripts need be updated.  In addition, byte-level differencing typically works extremely well on scripts so that a differential update scheme is particularly effective here. Apple's stance removes that possibility from its iOS developers – all updates, including an update that only affects one script file, must be full package updates, including all executable code, all scripts, everything.

Second, game manufacturers in particular often have the concept of "levels" in their game. Initial installation needs only the first level or two and additional levels may be downloaded as the user plays through the game.  This improves the user experience by shortening the initial download time while running later downloads in parallel with other activities. The later levels are typically represented as some sort of iOS interpreted code.  This architecture appears to be prohibited by a plain reading of the Apple License Agreement, though game developers appear to be doing it with Apple’s approval (see here and here). Clearly Apple is trying to avoid two things: a path for malware to get onto the mobile device and a way to avoid paying Apple its cut for chargeable app upgrades. Games that understand the reason for the policy and are willing to abide by those restrictions appear to be able to get around the more Draconian language of the policy itself.

Finally, there is simply the problem of the inconsistent and capricious nature of the policy. There are many definitions of various terms near the beginning of the license agreement.  "Interpreted code" is not one of those.  Consequently, Apple is free to interpret this in any way they wish, and to change that interpretation at any time – not a confidence builder for a developer contemplating spending a significant amount of time designing and building a product for the iOS platform. Not only have games been allowed to "get away" with seeming violations of a plain reading of the policy, but other apps like Codea (formerly Codify) exist that allow user-generated Lua scripts to be run. However, a (superficially at least) very similar app called Scratch was rejected. I know if I were in the planning stages of an iOS app, I’d really be grateful for some clarity from Apple.

So how can the policy be fixed? Here’s a suggestion: define "allowable interpreted code" in such a way as to make clear what the real purpose of the policy is.  One possibility would be to use the verbiage from the HTML5 exception to make sure that the interpreted code doesn't cause the app to morph into a fundamentally different entity. Then, make it clear that scripts of this type may be either user-generated on the device or developer-generated (not third-party-generated) and downloaded from servers controlled by the developer.  Of course lawyers would need to be involved, but it seems to me that such an approach would solve all the problems I've noted here.