New iPhone OS License Threatens 3rd Party Languages
In certain circles, whatever interesting things there were in Apple’s iPhone OS 4.0 unveiling today were overshadowed by some new language in the iPhone Developer Program License Agreement:
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). [Emphasis added--LOB]
This is almost certainly a reaction to Adobe’s Flash-to-iPhone cross-compiler, but on the face of it, it catches a whole range of 3rd parties in the blast radius. In particular, I’ve been recommending MonoTouch as a great solution for C# developers and teams. Although Mono compiles C# code to native code, Mono applications are not “originally written” in one of Apple’s preferred languages, so would clearly seem to be prohibited under the new agreement.
The buzz on the monotouch IRC channel is that this restriction only applies to applications that are deployed the AppStore and not to enterprise deployment, which means that even if the restrictive clauses stay in place, MonoTouch might remain a good option for some.
This is a developing story and it doesn’t seem to make sense that Apple gains by limiting the universe of programmers for the iPhone. Prohibiting inefficient translation layers and libraries is one thing, prohibiting code generation and higher-level languages is another. One of the showcase apps for the iPad is “The Elements” whose media, page layout, and transitions were largely generated in Mathematica. Many games use higher-level languages such as Lua to script AI.
Logically, one would hope that the legal agreement would be clarified with some form of “…except for approved toolchains,” and figure out how to work with Novell and Appcelerator and, yes, even Adobe.
Even “…except for approved toolchains” isn’t going to do much good. How can Apple possibly keep up with all the different toolchains? And what constitutes a toolchain? For many of the complex projects I’ve been involved in, there is almost always some sort of set of custom tools that generate code automatically. Those portions aren’t coded in the “original” language. Do those custom tools constitute a toolchain? Is this allowed under these terms? If they adopted your suggestion, would I need to seek approval for my custom tools? Unless Apple has some sort of lint like tools that they require App developers run on their source to before approval, I can’t imagine any scenario where this materially benefits Apple or developers or users.
You may be right that this is a reaction to Adobe’s Flash-to-iPhone tool, but that’s not a good reason. Why do developers have to get caught in the middle of this apparently ego driven nonsense? I remain completely baffled by the emphasized portions of that section. The only reason I can think of for that section is that Apple is hoping to trap developers into their “ecosystem”, but… That’s just not the way to do it. If I have to, I’ll create a cross compiler toolchain that can take the source for my iPhone app and target other, less restrictive, platforms. Therefore I can meet their license terms but still seek a broader market. Wait… Is there a section in the license agreement prohibiting that?
I wonder when Apple will start getting labelled an “evil” company. There is certainly plenty of fuel for the fire. For now cool design trumps evil.
More and more I see Android in my future.
[...] the just-released Apple iPhone SDK 4.0 has an interesting clause in the license, described here and here. Some are taking this as a direct attack on Adobe’s Flash, but the collateral damage looks to be [...]
[...] New iPhone OS License Threatens 3rd Party Languages - Larry O’Brien highlights some new Terms and Conditions included in the Apple iPhone OS4 release which casts question over the use of C# and the MonoTouch library for iPhone application development. [...]
The Turtleneck Taliban strikes again! You’d think Apple would be wanting to join the 21st century and get more open. Roll on the new Windows phone…
[...] Home « New iPhone OS License Threatens 3rd Party Languages [...]
@ScottS : Apple is most closed guarded company. I can’t think of why it isn’t labeled “evil”.
As I have read in engadget, I think ADOBE and rest of the eco-system must hit back by restricting their softwares on Mac.
Regards to MonoTouch, I don’t see a reason why we should use it now :(
This has also hammered REALbasic’s (semi-official) plans to target iPhone.
For mainstream Mac reasons, they have been busy with both porting their framework to be Cocoa-based, abandoning Carbon, and migrating to LLVM. These were also important parts of the path to iPhone native apps.
now, they will be hit directly by both the restriction on other frameworks calling CocoaTouch and the translation of other languages. Even if they were to take advantage of LLVM’s ability to compile to C, rather than directly to ARM native code, it sound like that would violate the “originally written in” clause.