"If you want to write code for a platform where the only thing that determines whether you're going to succeed with it is whether your audience loves it, the iPad isn't for you."  -Cory Doctorow

Sometimes, there's a way to write about something controversial, make your point, and at the same time, bring together both sides of an issue to a point of common understanding. Alternatively, you can write something in a way that simply draws a line in the sand, and forces both sides of the debate to get their backs up against the wall. You only need to read a line or two of a Cory Doctorow's column to know which way the ink in his pen flows.

"As a copyright holder and creator, I don't want a single, Wal-Mart-like channel that controls access to my audience and dictates what is and is not acceptable material for me to create." -Cory Doctorow

The discussion is both timely and pertinent, especially with the release of the iPad, and the updated license agreement for iPhone development. Just take a look at section 3.3.1 of the new iPhone Developer 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).

Doesn't this sound rather restrictive? John Gruber interprets this as essentially banning Adobe's Flash-to-iPhone compiler. If that's a true assertion, then it certainly puts a damper on Adobe's Flash Professional CS5 release. Lee Brimelow, platform evangelist at Adobe and the author of The Flash Blog, gets even more to the point when he says, quite simply, "go screw yourself, Apple!"

"If you want to live in the fair world where you get to keep (or give away) the stuff you buy, the iPad isn't for you."  -Cory Doctorow

Certainly, Apple has the right to control the quality and secure nature of its products, and nobody wants to see poorly written or compiled programs allowing viruses and bugs to run rampant on their handheld devices. But just how far is too far?

Well, if you want an opinion on these subjects, something with which you can either strongly agree, or vehemently disagree, check out Cory's column. John’s is solid as well.

"If you want to live in the creative universe where anyone with a cool idea can make it and give it to you to run on your hardware, the iPad isn't for you." -Cory Doctorow

Why I Won't Be Buying an iPad, by Cory Doctorow

Does the iPhone License Agreement Ban Adobe's Flash Compiler?  by John Gruber

Go Screw Yourself, Apple! by Lee Brimelow

Doesn't this post belong on theclientside.com?  :)

Indeed, Apple has its segment in the client side, but there is an effect on simply the adoption and acceptance of Java when major players in the industry marginalize our language of choice.

A viable way around this problem is the use of a cross compiler.  You code in one language and then emit code in one of the supported languages using a runtime library.

We did it for years with C++ prior to the release of real C++ compilers on many platforms.

I do not think the phrase "Applications must be written in" has any substance. 

This is probably just a short term way of killing Flash.

What do others think?

A way of killing Flash? I don't like Apple's business practices, but I don't like Flash either. Hmmm. Is the enemy of your enemy's enemy still your enemy?

Cross compilers specifically won't work, as the ORIGINAL source code will not be in C/C++/Obj-C.

The goal is to get iPhone developers to write iPhone apps. The goal to ensure that those writing those apps are focused on the platform, to not let the iPhone become a "commodity" platform for "generic" mobile applications.

If you want to distribute code for the iPhone, you're obligated to write for the iPhone, not some other, generic, platform agnostic toolkit.

That's the driver behind all of this.

It's both, sound technical reasoning and "anti-competitive".

The sound technical reasoning is you don't get lowest common denominator interfaces for you apps. It's good in that you have code running the native iPhone infrastructure rather than something that's potentially mimicking some aspect of another platform levered on top of the iPhone. It's good in that your developers are basically required to understand the ins and outs of the iPhone platforms specifically rather than their toolkits views of it.

For example, in the Java world, beyond perhaps worrying about drive letters and different file separators, a basic Java app "just runs" with NO understanding of the underlying Windows platform. Yet, obviously, Windows isn't really quite that shallow. So, it's kind of hard for someone with no Windows knowledge to really leverage the Windows OS.

So, the native toolkit requirement means that the developers need to have some depth of knowledge (though certainly not "expert") of the iPhone OS and environment to develop their applications. In the end, you will likely end up with applications that better work with the iPhone OS, leverage the in-built services, etc.

Overall that can result in "better quality" applications on the iPhone.

We have all seen bad cross platform ports, the native development requirement helps reduce that problem.

From the "anti-competitive" point of view, that's an interesting turn of phrase. The move is VERY competitive. Basically, competitors are going to have to compete without iPhone developers. Competitors are going to have to have to compete and attract developers on their own for being something besides simply a "mobile device". There will need to be a compelling reason to convert a (now) dedicated iPhone developer to run on your platform, rather than hoping that they'll come to your platform "for free" using a cross platform toolkit.

"Unleveling" the playfield is what competition is all about, frankly.

Do you consider MS development of .NET to counter Java anti-competitive, which is effectively the same thing, if perhaps less formal, that Apple did? I certainly don't.

So, for the short term at least, in the mobile space, you will have iPhone developers, and "other mobile" developers. Apple feels that it's worth distinguishing their device at the development and application level from other platforms. It's not going to be a "generic Java ME" phone.

The mobile space is already fragmented. The fragmentation is what promotes the development of cross platform toolsets in the first place. But what you end up with is applications developed to the constraints and boundaries of that toolset, not the underlying platform.

Doesn't do Apple much good to innovate on its mobile platform some new feature only to have it go unused because A) other platforms can't do it yet and B) the Predominant Cross Platform Toolkit (whatever that may be, if one ever rises) doesn't support it either (because of A).

We see this today with folks browsers developing new capabilities, that "no one uses", because everyone wants cross platform compatibility.

So this move lets Apple accelerate their platform, being MORE competitive, because they "know" that their development community has no reason to hold back and not leverage the platform to the hilt.

Very well put, and very well written. That's an interesting take, especially with all the discussion on TheServerSide.com today about the problems with the Java Community Process (JCP) being dragged down by so many vendors accepting the lowest common denominator, as opposed to embracing innovation. Not sure if I completely agree, but you've certainly made the position much easier to understand. Thanks!

I think the headline here is a bit misleading - maybe it's the use of the colon that implies the second statement relates to the first one??

My first thought was of Java ME. I've been holding out hope that Java 7 memory, performance, and footprint would improve enough that we could argue keeping Java off the iPhone simply didn't make sense anymore (not that it ever did). This kind of puts the last nail into the Java ME coffin on iPhone.

Too bad since I was really thinking just how great mobile Java could be with a world class Java ME 3 implementation on the iPhone.

Well, everyone is speculating on this now. Is a lawsuit between Adobe and Sun over this cross compilation compiler issue far away?