It's all well and good to say such and such is the reason, but that's not what the license actually says.

What's to stop a tool developer producing an Objective C library and compiler that can target both iPhone and Android? The original source would still be in Objective C. If it was developed specifically for the iPhone, and only later for Android, it wouldn't be a compatibility layer - only the Android port would count as the compatibility layer, with the iPhone original being the native one.

If it comes to that, Apple will ban it's use. No biggie. As long as Apple thinks they have no competition to fear they can limit developers as they wish.

So let's all hope Android (or any other mobile platform) is very successful. Yes, you iPhone-Developers, too should wish for Androids success!

I don't think Apple would, or even could ban anything of the sort. I think they want people to develop for iPhone first, and if you want to automatically convert that code to Android and get the cross-platform inferior experience there, then so be it.

I agree with this as well... I'm sure Apple wants more apps for the Mac, and if someone were to create a 3D modeling tool targeted for iPhone apps that could produce cross platform Android apps, they'd welcome it into their Mac family.

I see this the same way. The TOS states that you are not allowed to use an intermediary layer to call the iPhone OS API. A C++ or C library that would abstract the underlying OS' API would clearly be such an intermediary layer and if there would be sort of a QtMobile or wxPhone or whatever framework that would allow you to write cross platform mobile applications in C++, Apple could ban it based on their new rules - even if you were sticking to the approved set of programming languages.

We're light years away from that happening.

I think Apple isn't used to being in control. Cross platform on OSX generally means poor versions of programs designed for other platforms. That isn't an inherent factor of cross platform tools, its because OSX is a minority OS. For instance in all the complaints about Firefox on OSX noone has stopped to think that Firefox on Windows is equally developed on a compatibility layer.

With the iPhone OS dominance in handheld software compatibility layers, Android and other platforms will be the minorities dealing with poor ports. Cross platform tools will be designed for iPhone OS.

Having said all I've said against section 3.1.1, I'd have to say I support banning Flash CS5 from the App Store, there is just no need to blanket ban compatibility layers. Maybe Apple should institute a framework whitelist - it'd certainly be up their alley in terms of control, and would let decent platforms like Unity continue.

If there had been a whitelist in place all along, none of these cross-compilers would exist. A whitelist would stifle innovation as much as a blanket ban.

Sure, I'm just thinking of options that Apple might approve of.

He never goes into how he uses Lua, but if he's still targeting Apple's libraries (rather than some cross-platform transition layer), they might not even be able to tell he is using Lua in the first place.

The author of the open letter is behind iPhone Wax: http://github.com/probablycorey/wax

It may also be worth nothing that the particular case of Lua was already prohibited under the iPhone DPLA section 3.3.2 which states that no interpreted code may be included unless it's run by Apple's interpreter(s). Wax embeds a third-party Lua runtime that does just that.

This is stated again and again on HN, but it is just not true. You could run interpreted code, it just wasn't allowed to download and run modules, everything had to be linked into the application.

That was true given early revisions of the agreement. If you revisit the language you'll find that the phrase "download and run" has been replaced with "download or run."

That said, there was talk about moving Wax to llvm-lua such that the resulting application would be compiled machine code. The new clause precludes this option entirely.

The only uncertainty left, now, centers around enforcement. There are a number of PhoneGap and Wax powered apps already in the store, and PhoneGap was even blessed as an approved framework. Only time will tell if that blessing stands.

I'll take a guess - Lua isn't there to abstract the iPhone. It's just there to make development faster. Apple won't clamp down on better apps, they will only target cross-platform abstractions. But it's still a bit worry.

Leave it to the suits to create artificial barriers.