3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
The preceding is quoted from Daring Fireball presumably quoting Apple’s new licensing conditions verbatim (I actually haven’t read or signed off on the latest SDK license — I’ve been too busy).
I’m coming very late to this particular discussion, although I’ve commented a few times on Unity 3d’s enormously long forum thread on this same topic. Probably the single clearest explanation of WTF Apple is thinking is in this post (also thanks to Daring Fireball) from Jean-Louis Gassée, former head of Apple’s ATG, and founder of Be Inc.
Here’s my version: Flash, like all cross-platform development tools, is essentially about implementing a fixed feature set on a virtual platform that usually is itself based on a lowest common denominator of the platforms on which it runs. But, unlike Realbasic — which actually tries to find common features between platforms (scrollbars say), Flash is more like Java’s AWT and targets an absolute minimum of features (graphics and audio, say) and then builds out everything from scratch. This means that anything built using Flash adheres to no platform standards whatsoever. (E.g. on the Mac, Flash scrollbars ignore the mouse scroll wheel.)
It follows that cross-platform development tools are all about ignoring the advantages of individual platforms and all about turning hardware into a worthless commodity. Gee, I wonder why Apple might not like this?
But, it gets worse. Adobe, having started out as Apple’s partner has — to its own detriment — scorned the Mac platform and released a succession of inferior products on the Mac, notably Photoshop. (But remember that the as-yet-unreleased Flash 10.1 addresses most of the issues with Flash… in other words, in response to ten years of user complaints and three years of outright hostility from Apple, Adobe has finally fixed a few glaring issues with Flash.)
But, as you might infer from my reference to Unity at the top of this post, Adobe is far from the only (potential) victim of this latest exchange of fire. It would appear that technically, Unity might be affected by this changed clause. More importantly, any finesse which might enable Unity to avoid being so affected is equally open to Flash:
“Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine” — depending on how you read it, Unity or Flash themselves may have been “originally written” in Objective-C, C, or C++, but Unity and Flash apps themselves are written in something else entirely.
“only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs” — is a pretty odd clause because it appears to be unnecessary given the preceding clause — how can I compile and link against an API from a language I’m not allowed to use in the first place? And, in the absence of the previous clause it expressly prevents an app written in some other language from using iPhone OS’s differentiating features. In other words, an app written in C that gratuitously implements a substandard UI from scratch is OK but one written in Lisp or Go that contrives to use the native API to access platform-specific features is not. Why? And how does this benefit end-users or Apple?
Edit: actually, it’s possible that Apple’s real problem is the assumption by third-party tool builders that Apple is going to stick with the ARM platform — e.g. Adobe’s LLVM implementation emits ARM binary. Apple’s long-term commitment to ARM cores can hardly be taken for granted given its various acquisitions, including a PowerPC-oriented chip design company.
It seems to me that the way for Apple to achieve its objectives would be to ban apps that use non-standard UI (and other) widgets without good reason, which gratuitously implement widgets for which native widgets are available, which suffer from poor performance, memory footprint, or power usage for no good reason, and which fail to adhere to various platform standards (and let’s go crazy here and enumerate them). All of these things are actual end-user benefits rather than arbitrary technical or legal requirements.
This would kill Flash far more specifically than the existing legalese, and the way to address it would be to fix the problems in Flash (don’t hold your breath). A developer like Unity Technologies (which has been known to fix problems in sub-Geological timeframes) could address its non-compliance by improving its support for platform APIs and UI widgets. Simply allowing developers to incorporate NIB files and make direct API calls would probably solve 95% of issues and actually make developers’ lives easier too.