So back in the day, Apple explicitly forbid bundling interpreted code into an app. It was always one of those restrictions that was pretty selectively applied, since there were a large number of apps in the App Store that leveraged interpreted code - some of these were even demo’d by Apple at their events.
Nonetheless, Adobe did the responsible thing, and when it developed the Flash Packager for iPhone, went to the trouble of creating a new compiler, so that all ActionScript was pre-compiled (read the section, “How it all works” in this article for slightly more detail). A side effect of this, I seem to remember, is that any code on the timeline would be stripped out by the compiler because it could not be pre-compiled. Then Apple got all, “oh no you don’t” and the Flash Packager was shelved by Adobe.
Flash forward to today’s announcement of Apple’s new Terms of Service (TOS). While this provides a measure of certainty for all of the players in the 3rd party tools space (Ansca’s Corona, Unity, etc.), it’s only confirming previous actual practice for them, since it was pretty clear from the get-go that those workflows weren’t the target of the wrath of Steve. Corona- and Unity-powered apps continued to appear in the App Store in spite of being in direct violation of the TOS. The big winner, of course, is Adobe, and with a 12% rise in their stock price, everybody knows this.
But here’s the interesting thing: the pendulum actually seems to have swung farther in the opposite direction: now, interpreted code isn’t forbidden, it’s explicitly permitted as long as the code is not downloaded but is packaged with the app. You can compare the old and new section 3.3.2 in this article, but in case you don’t want to, here’s the new version:
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.
Gone is the old language forbidding the use of any kind of interpreter other than WebKit’s. So not only can Adobe continue to work on the Flash Packager for iPhone, they could - if they so choose - modify it so that it can handle interpreted ActionScript at runtime. It would be quite interesting if they did, because I suspect one of the stumbling blocks for a lot of older Flash content that people might want to distribute through the App Store is that it contains a lot of timeline code. Converting it so that it’s compatible with Adobe’s AOT compiler would be non-trivial. But if Adobe were to modify the Packager so that it interpreted ActionScript at runtime that could suddenly become a lot easier.
I’m not commenting at all on how well that would work; this post is merely about the technical possibility now that the contractual restriction has been lifted. I just find it funny that Apple’s new Terms of Service are actually far more permissive than the original ones that led them to change the TOS to screw Adobe in the first place.