Implications of Apple's iPhone Lockdown

If you have been living under a rock this week and have not heard about Apple's wonderful new iPhone Developer License Agreement, here is the part that is bothering people:

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).

I am not exactly a businessman, but this does seem like a rather bad move on Apple's part. Apple seems to lack an official stance of the matter, but the response of Steve Jobs to John Gruber's blog is the closest I have seen. I think the John summarized Apple's reasoning in the 4th paragraph (emphasis mine):

So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there's no lock-in advantage.

It is Apple's platform which they used to take over the "hip" smartphone market with elegant simplicity, solid design and good marketing. Somehow, despite the incredible lockdown on distribution (to the point where you can develop an application and just have it rejected), people are climbing over each other to develop exclusive applications for it. It seems like everyone and their dog is making an iPhone application and it is the de facto "easy mobile platform," despite the fact that other SDKs exist and look awesome.

John then goes on to say this:

Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.

How is that relevant? As an application developer, layers of abstraction are a good thing. In the simplest case, consider a library like SDL. It allows me to develop an application concurrently for Windows, Linux, OSX and whatever else SDL, despite the drastic differences in windowing systems and system libraries. For the majority of the graphics things I need, SDL provides a convenient way to develop it for all target platforms simultaneously. In the corner cases where I need functionality that SDL does not provide, I can work down to system-specific OpenGL calls. The mark of the good library is that it abstracts the most common functionality and lets you get more specific when you need to. If the abstraction layer does not provide the functionality you need it, make the system call yourself. If the abstraction layer does not allow you to do this, get a new library.

I can understand that Apple does not want a bad standard taking over their magical platform, but unlike a web standard, when you compile a language, assemble the generated code and run it on a processor, the processor is completely agnostic to what the original input language was. I'm willing to bet that when Adobe's software is transforming your ActionScript code to run on the iPhone, they are making the appropriate system calls. There is also a good chance that the code that Adobe emits automatically is more efficient than the average iPhone developer's. If application developers need some functionality provided by Apple's SDK but not yet wrapped in a high-level call, they can just make the SDK call. If the system does not allow this, it is time to get a new one.

All Apple is doing is locking down their system so that people have to use their tools to develop for them. While a great money-grabbing move: Does it help the customers? While John provides the common assertion that cross-platform apps are bad on Apple platforms, I would argue that has less to do with the fact that the application is cross-platform and more to do with developer time. Many Windows+OSX apps are worse on OSX because developers do not care enough about the OSX version (which is probably justified, considering the percentage of users of both systems). Besides, there are already systems which provide cross-platform support and I will site QML as just one of such systems. Ultimately, how well an application works on the systems is a property of how much time and effort a developer puts into it. And if a developer is tasked with making the same app for a web browser and the iPhone, then having to write common functionality once will give them more time to dedicate to the making the application feel right and will give consistency across platforms, both of which lead to an ultimately better user experience. And if the abstraction layer does not make it easier to develop, then it is time to get a new one.

Enter the Apple fanboys. Steve makes the case that Apple does not want to tie themselves to a single platform and seems to think that XCode is the only thing capable of cross-compilation or that Apple is somehow innovative in this regard. He also seems to think that the iPad's processor is not of ARM architecture and that, for some reason, Apple is artificially restricting people to running their apps on an emulator. If he is right, then Apple is epically stupid, since it is obvious they are not lacking in a compiler for whatever the A4 chip is. This is my favorite quote:

Apple is sowing the groundwork to make architecture changes seamless—developers will only need to flip a switch to give their apps blazing, native performance.

All debate about what the A4 is aside, it is ridiculous to think this argument is a legitimate justification for the programming language lockdown. If Apple's toolchain really does generate applications that are so superior to others that it outweighs the cost of having to develop two simultaneous apps, then people will just use their system. Apple would win on the merits of being better and would not need to lock down their system in the first place. Apple is no longer competing on the grounds of producing a better system; they are effectively saying that they do not wish to compete and are just locking Adobe out. Lack of competition ultimately hurts the customer.

But Adobe is not the only one Apple is screwing over with this policy - it raises legitimate concerns for abstractions like Qt-iPhone. They are probably safe, since Qt is mostly C++. However, some could argue that with uic and moc, that Qt code can no longer be considered "C++." Of more concern are tools like Unity 3D, whose front page boldly currently advertises "Unity iPhone 1.7, Now with iPad support." Sorry, guys! And what about the people who no longer wish to live in the world of imperative languages? Nope.

Its sad that the iPhone is what people will consider the spark that started the era of ubiquitous mobility, when that perception was nothing but an amazingly well-played marketing game.

---

UPDATE: The latest Unity mailing list letter contains this gem (emphasis mine):

As most folks already know, Apple introduced a new Terms of Service (ToS) with their iPhone OS 4 that has some Unity users concerned. While we don't yet have a definitive statement to share at this time, we have a healthy, ongoing dialogue with Apple and it seems clear that it's not their intention to block Unity and will continue our efforts to ensure compliance with the Terms.

I feel bad for the Unity developers, who will probably have to do a some amount of work to "insure compliance." What a pointless waste of energy. For more on this, check out David Helgason's blog. What surprises me is that Unity is in direct violation of the words of their terms of service. It is not really debatable — user applications simply are not written in "Objective-C, C, C++, or JavaScript."

This goes back to my emphasis: "...it seems clear that it's not their intention to block Unity..." So what is their intention? It is clear that Adobe is not getting this same treatment. Was Apple's only intention to block Adobe? That is astoundingly pathetic.