Apple iPhone SDK – Now Allowing Interpreted Code … Sort Of … Maybe … In Theory … If Steve Jobs Likes You
There’s small reason to rejoice today if you’re a software developer. Apple has loosened up it’s no-interpreted-code policy in the iPhone SDK used for development of apps on the iPhone, the iPod Touch, and the iPad.
The old iPhone SDK end user licensing agreement (EULA) stated quite clearly and adamantly that, “No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).“ This prevented anyone from using languages like Adobe’s Flash or Sun/Oracle’s Java. Or Python. (My personal favorite language.) Amongst many others. It also prevented the use of third-party development tools such as Adobe’s iPhone packager, which converts Flash scripts into native iPhone machine code. Or third party libraries such as .NET, Mono, Qt, etc.
It’s a limitation that many developers feel is not only senseless and needlessly inhibitive, but even has the government fighting (DoJ and FTC) for the chance of an antitrust investigation into Apple for their non-competitive practices.
The new iPhone SDK however has a change of heart.
Just a little bit.
A few minor changes of wording in the iPhone SDK leave a little bit of theoretical wiggling room. Such as, “Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).“ Which makes it sounds as if, theoretically, you could request from Apple a waiver to release your interpreted-code app.
Because then that theoretical possibility of using an interpreted language is further qualified in the iPhone SDK with, “Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.“ My own emphasis on the key qualifiers there. So of course you still need to write the majority of your code in an Apple-approved language. You still can’t use any third-party development tools, libraries, or languages.
It still doesn’t really fix anything. Except for perhaps a few rare instances of development, quite possibly in minor things like spam filters, spell checkers, and small pieces of engines used in games.
But maybe it sounds a lot less closed to antitrust investigations perhaps?
One thing is for certain, Apple does not equal Open.