I think a careful implementation of Lua integration 'avoids' 3.3.1 but 3.3.2 which forbids interpreted languages (except those within the official SDK) catches it.

I don't understand how that could be... Could you explain? If a portion of your app is written in Lua, how can you claim that the app is "originally written" in a C derivative?

It's a technicality of course but you can rightly claim that the app is written in C and that it interprets the Lua code. In the same way it may interpret and XML file.

Of course we all know this is a technicality and it doesn't matter since 3.3.2 states "... No interpreted code may be downloaded or used in an Application...".

The two clauses combine to put Lua on a sticky wicket.

Certainly for video games it's not as if there is a slim C layer and the vast bulk is written in Lua. Most game engines are huge and only game flow and AI are written in Lua.

In the previous version of the Agreement, 3.3.2 stated "... No interpreted code may be downloaded AND used in an Application..."

Using an embedded interpreter that only ran the signed code inside your app bundle was previously quasi-legit -- it was more narrowly restricting the use of an interpreter to bypass the App Store review process.

They changed that AND to an OR a while ago, before this recent announcement. So basically that reduces down to: no interpreters. So these games using Lua were already breaking Apple's rules.

No you can't rightly claim that. The C is an intermediary translation layer.

Correct. So you carefully craft it so that it doesn't "...link to Documented APIs... " i.e. it only interfaces with your application.

It's all tenuous I agree.

From what I've seen, the ban on interpreters is very much aimed at options that allow an end user to download and run scripts and if that is the case, expect Apple to clarify that, particularly if they are getting pushback from the larger grossing game houses. The ostensible reason for the ban on interpreters is that allowing third party scripts would be a security risk; which is true to a point. But, we all know that it functions to keep the App Store as the only source of software.

/the ban on interpreters is very much aimed at options that allow an end user to download and run scripts/

That's why 3.3.2 used to prohibit only apps that download and run scripts. Now it prohibits apps that download or run scripts. So that should take care of those folks polluting the iPhone with the Lua.

In many cases, the game has already been developed. What can they do but wait and see what actions Apple takes to enforce?

What about updates?...

Apple's precedent seems to be pull the games immediately from the AppStore and not wait for an update. That being said, it would be extremely strange in a corporate sense to see a fair number of top grossing apps disappear.

Since the apps were approved by the previous terms they still can be sold, i guess... Now if the developer submits an update then it must comply with the new terms...

Approved apps have been pulled before (Google Voice apps) so they could do it. I doubt they would, but it's not without precedent.

Good point, I remeber reading about a game, initially accepted, that had been pulled out because it relied on a library that was able to call private APIs, even though the game didn't use that part of the library.

This happened when Apple started to scan binaries for infringing code.

its probably a good bet, apple's intentions are pretty clear and nixing studio-quality game engines is not to their advantage.

No. It's undoubtedly a bad bet to put your time and energy into creating a product that is in direct violation of the policies of the store in which you plan to sell the product. I'm not saying they will definitely ban you, I'm saying the risk of putting all your eggs in the Unity or Lua basket and getting banned vastly outweighs the potential reward of a lucrative app.