Cross Compiling: The Apple iPhone Developer Clause 3.3.1 and You
There has been quite a buzz about Apple's new developer guidelines that now contain clause 3.3.1:
"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)."
Read on for our opinion about this.
Why?
From the wording it seems that any kind of cross compilation is now forbidden, one could even argue that any kind of libraries that ease the use of iPhone APIs are now prohibited as well. Why does Apple choose such restrictive guidelines?
- Quality: I don't think that Apple is concerned about the quality of applications here: they do have an application approval process that can or could handle this.
- Flash: There seem to be quite a few emotions between Apple and Adobe about Flash, so one could speculate that Apple wants to annoy the Adobe folks. Since it would be less elegant to outlaw only Flash they could have chosen to use these broader legal terms. This theory is quite possible but I don't buy it.
- Lock In: One can only speculate that they want to lock in developers into the Apple ecosystem. It makes sense for Apple really, they force developers to learn the Apple environment and languages if they want to provide applications for the most successful mobile system there is.
Lock In Theory Explained
Nowadays developers need to consider the iPhone first or at least parallel to other platforms in many cases. Before the new guidelines were in place there were many options to choose from for creating native iPhone apps, for example Mono Touch for the C# developers, Titanium for the web developers, Flash CS5 for the designers or J2ME Polish for the J2ME developers (and many, many more). These options meant that developers could leverage their existing know-how and could release applications for a variety of platforms at the same time. If a developer wants to release applications on the iPhone first (4.0) she must create the application in Objective-C, C or C++ directly for the iPhone first before she can turn to other platforms.
Why a Lock In is Unfair
In my opinion this lock in effect of clause 3.3.1 is not fair because Apple uses its dominant position in the mobile application space to force developers to develop directly for its platform. How dominant is the iPhone? Apple has 160k+, the next one seems to be Android with around 40k apps - around 25% of the iPhone numbers. In other words: Apple is four times bigger than its closest rival. When Apple now enforces that developers develop directly for its platform, it is clear that there is less time and money for other platforms left.
Is There a Loophole?
There are speculations that you are within the legal bounds when have generated Objective-C source code along with an Xcode project. I am, however, not sure about this interpretation, since the clause 3.3.1 states that the application needs to be originally written in Objective-C, C, C++ or JavaScript.
What Apple Should Do Instead
If Apple wants to keep developers to their platform they should provide the best tools, the best support for different languages and a flourishing environment instead. If Apple wants to increase the quality of applications they should allow third party developers to access the same APIs that Apple uses for its own applications. And they should allow competing apps to their own products as well. Innovate on fair grounds - it's that easy really.
Porting Alliance to the Rescue!
We want to protect the freedom of developers and users - first we should check legal actions against this provision. Enough Software as well as MoSync and other parties were discussing founding a porting alliance for some time now, I think there has never been a better reason to do so!
If you wan to to join this effort please send an email to porting-alliance<at>enough<dot>de.
Robert