Section 3.3.1
What Apple doesn’t want—and as we see now, is not going to allow—is for anyone other than Apple to define the framework for native iPhone apps.
And:
Cross-platform software toolkits have never—ever—produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy. On the other hand, perhaps iPhone users will be missing out on good apps that would have been released if not for this rule, but won’t now.
Leaving aside the question of whether it’s reasonable to ban cross-platform applications rather than let customers decide whether they’re useful, I worry that this new regulation will also affect native applications. There are a variety of reasons that a developer might want to leverage other languages (either at build time or runtime) for code reuse, libraries, or development speed and power. Consider, for example, an AI or game engine written in Lisp that compiles down to ARM assembly or C. Hank Williams writes:
Developers are not free to use any tools to help them. If there is some tool that converts some Pascal or, Ruby, or Java into Objective-C it is out of bounds, because then the code is not “originally” written in C. This is akin to telling people what kind of desk people sit at when they write software for the iPhone. Or perhaps what kind of music they listen to. Or what kind of clothes they should be wearing. This is *INSANE*.
What will the next rule change be?
Update (2010-04-10): Hank Williams explains this a bit more:
By defining the rule as being about what language something is “originally” written in, we now must be supposedly concerned about the provenance of our code, and not just what it does. If a math library, or a physics engine, or a string package, or whatever, was originally written in some other language, and ported, then it violates this rule. This concept of what language something is written in is an insidious concept and strikes at the core of product development and of computer science in general. Everything is built on other stuff, the language provenance of which is often unclear. This language is fundamentally unreasonable, and un-enforceable.
I’m not convinced by his legal arguments (IANAL), but I think the important point is that Apple’s attack on cross-platform interface toolkits (of which I’m no fan) causes collateral damage and bans (should they choose to enforce 3.3.1) lots of libraries, tools, and techniques that could be used to develop top-notch, fully native iPhone OS software.
12 Comments RSS · Twitter
To Clout:
What we suppose is that the intent is to block cross-platform widget toolkits (user interface), but the actual effects will go much deeper. If you write the back-end of your application (the non-UI part that does the actual work) in another language, following this new rule you can't even reuse the back-end by putting a native Cocoa Touch interface around it.
As Ars Technica says, the wording is so broad that even writing an english description of the program first could make "english" the original language and forbid you from publishing on the App Store. They obviously won't take it that far, but the point is that this rule outlaws so many things outside of alternative UI toolkits that it's ridiculous.
For instance, I have manually ported a game from D to C++ so I can compile it with Apple tools, but the "original language" of the game is still D (the iPhone UI is Cocoa Touch though, and feels much more native than most games). Is this game disallowed now? Or is manual porting allowed while an automatic tool that does the work is disallowed? What about a semi-automatic conversion to C++?
The net effect is *almost* the same as if they wrote this: "every program is forbidden (but we'll enforce this rule only against apps we don't like)"... which doesn't really change what they seem to be doing anyway (rejecting apps they don't like).
At this level, I think Apple has reached hubris. I am certain there are plenty of developers which already use, even in part, source code other than [Objective-]C[++] - there certainly are Fortran libraries out there, for instance. I'm trying to rally developers to make Apple understand they are trying to boil the ocean here: http://wanderingcoder.net/2010/04/09/rally-3-3-1/
@Pierre Lebeaupin: Thanks for the link. I was thinking that going by the language of the agreement, even something as innocuous as SQLite would be banned several times over (if it weren’t already built in). The C code and headers are generated by scripts, and the parser is generated by Lemon. It also runs afoul of the “no interpreters” clause, because it compiles SQL to VM opcodes and then interprets them.
[...] So, once you start developing for iPhone OS 4.0 you can’t complain about or even mention Section 3.3.1. [...]
@Michael Tsai: You're welcome. Heh, rereading my post again I find myself a bit cheesy here. But hey, you gotta start and learn somewhere…
[...] or parser-generators for their engines. And I doubt that most developers who are upset about Section 3.3.1 care much about Flash. If Apple had simply said that Flash was banned, in any form, they would [...]
You can write Lisp to C, D to C++, Pascal to C, Javascript queries on NoSQL Databases. "Original Language" means the language the applications run on. Converting has nothing to do with it. Apple surely won't question if you deliver perfect machine code, doesn't matter how you did it.
However, they won't allow for virtual machine stuff (Java), probably won't approve video game emulators, full programming environments or.... newsflash... Adobe's FLASH.
@Dr. Vanderbilt I see no evidence for those statements. The Flash code in question is delivered as machine code, and Apple has already approved some applications that use the Lua virtual machine.
[...] much like Adobe did with Flash, and support all of the iPhone OS APIs. Not a surprise, given Section 3.3.1, but it’s too bad because the iPad seems like the perfect way to deploy a HyperCard [...]
[...] not be a stretch to say that apps using XML also contain interpreters. Sections 3.3.1 and 3.3.2 effectively ban standard computer science and engineering [...]
[...] although it’s important to note that it’s basically a reversal of the damage done in April, rather than an improvement over the status quo ante. By my interpretation of the guidelines, [...]
So you couldn't use Adobe's products before to make an iPhone app. Now a future Adobe product can't write to a future iPhone OS....
And this is reason to care why?.....
It appears to me that Apple is and has been continuing to advance it's devices hardware and software. (Remember when you couldn't put an app on the iPhone?)
To your second point I have rarely used a cross platform app that didn't have that lowest common denominator feel.