Apple Locks Down

I'll admit it: I love developing for the Mac and for the iPhone. I think Cocoa is the best application development kit out there, and I have used quite a few. But lately it seems Apple is almost trying to piss its developers and consumers off. It's a well-known fact that developers basically have to sell their soul to Apple if they want to develop for the iPhone. To be honest, I am somewhat okay with that - It is not much different than developing for a console such as the Nintendo DS. (And on that note, it is much cheaper to do so for the iPhone). But a point of conflict has always been the infamous clause 3.3.1, which stated (Note: Clauses taken from ArsTechnica):

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

That is, until now. The new developer license published last week changed this clause to:

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

This was changed just days before Adobe released their new Flash to iPhone conversion software, and they are, understandably, very pissed. Hit "Read More" for the full story.

This is what Lee Brimelow, a "platform evangelist" for Adobe had to say about Apple:

Now let me put aside my role as an official representative of Adobe for a moment as I would look to make it clear what is going through my mind at the moment. Go screw yourself Apple.

Aptly put, sir, and it seems you are not alone. Many see this move as a further slap in Adobe's face by Apple. So is this just two boys throwing stones at one another? Well, perhaps it helps to look at this issue from an Apple perspective. What is in it for them? The answer is as simple and familiar as unsettling: Control. If a third-party development platform is released, it can decide on the feature set of apps, and where they will be distributed. Let us assume a scenario where Flash can be converted to iPhone, Android and Symbian. A whole new wave of applications would enter the app store, and all these apps would be limited in features to whatever the intermediate layer provides. For instance, they may all not be able to make use of the new Multitasking API Apple has introduced with iPhone OS 4. Additionally, the iPhone may seem less unique as all these applications run on any phone - not just the iPhone. Just like in the ongoing Opera vs. Safari battle, Apple does not want to give up its grounds of being the only player.

While all of this is usually no more than simple speculation, a recently surfaced exchange of emails between Steve and a developer add credibility to the theories mentioned above. Developer Greg Slepak spoke out to Steve pointing out the negative press Apple was receiving:

Hi Steve,
Lots of people are pissed off at Apple's mandate that applications be "originally written" in C/C++/Objective-C. If you go, for example, to the Hacker News homepage right now:
http://news.ycombinator.com/
You'll see that most of the front page stories about this new restriction, with #1 being: "Steve Jobs Has Just Gone Mad" with (currently) 243 upvotes. The top 5 stories are all negative reactions to the TOS, and there are several others below them as well. Not a single positive reaction, even from John Gruber, your biggest fan.
I love your product, but your SDK TOS are growing on it like an invisible cancer.
Sincerely,
Greg

Steve responded by citing John Gruber's post, which highlights the very reasons I mentioned above:

We think John Gruber's post is very insightful and not negative:
http://daringfireball.net/2010/04/why_apple_changed_section_331
Steve

The email exchange goes back in forth a few times, with Greg giving some examples of great software, developed using cross-platform kits, such as Mozilla's Firefox, and at one point calling Apple's new policy "evil". In the end Steve responds briefly with:

We've been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

So the question in the end is: Is Apple really helping the consumer? Is this a good thing? In my opinion: No, definitely not. You see, the only benefit I could think of really is that I can rest assured that my Mom will not be downloading sub-standard bloated software that will drain her battery. But can I really? Remember that these intermediate layers do eventually end up as Cocoa code, so they do not do anything I could not do anyway (without using these layers).

But even worse is the fact that this clause is anti-competitive. Apple is once again building their own little eco-system where competition is restricted only to those areas that Apple allows. Multiple browsers? Nope. Cross-platform apps? No, sir. When I was younger I always believed that in the future we would get rid of compatibility issues, where this piece of software runs only on that sort of hardware, similar to how PostScript got rid of the software-hardware dependency of printers. But it seems we are actually moving away from that. I find it somehow frustrating that the Final Fantasy games I just bought for the iPhone only run on that device (and yes, the iPod Touch). Just like with DVDs, I would love to have a Final Fantasy collection that runs on any device by any manufacturer that conforms to some standard. But it seems Apple is moving away from standards in the area where it counts most.

Would the use of intermediate cross-platform APIs lead to sub-par applications in terms of quality? Yes, probably so. We can see that on the Mac where cross-platform apps tend to be of poor quality as they cannot make use of platform-specific features. But you know what? People vote with their wallets. These apps generally get bad reviews, and when a native version appears with similar functionality, users flock to this new app instantly.

And that is what I believe Apple should be doing. Focus on the end product, not how it got there. If a badly ported app gets submitted for review: Reject it, if it does not conform to your high standards. The same goes for native apps, and Apple does that already. If all apps using a certain intermediate SDK get rejected for this reason, so be it: The developers of this SDK will need to improve on their feature set. But seriously Apple, how an application got there is none of your business. I'll agree with Greg here: That is just evil.