App Store Rejections, where's the line?
- Posted by Jonathan on Saturday, June 20, 2009, in iphone, development, appstore
Gruber summarized the rejection of the Commodore 64 emulator as:
Looks like an awesome app — a working C64 emulator with a gorgeous UI.
But while I hope this gets worked out and allowed into the store (I’d buy it in a heartbeat), it should not be considered a bogus/outrageous/controversial rejection. The rejection notice cites sections of the SDK guidelines (forbidding code emulators) which the app clearly violates.
While I agree that this app clearly violates that clause, I think we're crossing an interesting line with iPhone OS 3.0 with in-app purchases. The most common example is most likely going to prove to be "levels" for games -- race tracks, new RPG dungeons, etc.
I can't speak for all game engines, but in a few engines I've used in the past, logic can be built into the levels themselves. For example, an RPG dungeon might require you to push a block onto a switch before a door is unlocked.
Code Interpretation
Interpreting code is often a vague term, so I want to define it as the steps required:
- Parse input: Scan "code" to determine its structure and order
- Make decisions based on input: Based on the structure, perform the actions indicated
Now I posit that there are already clear-cut violations of this agreement (assuming Apple abided by their own agreement) if taken absolutely literally. What are they?
- Safari: Downloads, parses, and interprets (compiles in 3.0, from my understanding) Javascript code.
- Calendar: Parses CalDAV "commands" as to delete, insert, or update your calendar items. Think it's a stretch? I almost guarantee you that this code is written using a state machine with the equivalent of a switch statement.
- Calculator: You may think this is a stretch, but think about it: what's the first compiler or interpreter anyone ever writes? RPN calculator. In case you aren't familiar, a calculator is a classic example of parsing structured input (order of operations) and performing the operations specified by the input.
- MIDI players: These little musical machines are state machines that know several commands, like how to switch between instruments, how loud to play a pitch, and when to stop a pitch.
- Terminal/Shell Applications: Seriously, you're bring up a shell prompt which by their definition execute commands that you type in.
The key here is that with Safari, Apple cannot abide by their own agreement.
Clearly, all third party browsers should be banned if they don't disable Javascript. All terminal applications should be banned.
By not having a clear definition of what defines "code," the agreement puts all applications that download or take user input, parse it, and do something special based on it. That's all a programming language does -- it takes input, parses it, and does something based on that input. Thus nearly any program that parses a file and does something interesting with it should be banned.
How can levels be viewed as interpreting code?
As I mentioned before, logic can be built into the levels themselves that the host application is blissfully unaware of. This actually is another classification I would use to call something an interpreter or compiler: the application loads up unknown input, parses it, and performs actions based on the context of when the input was loaded.
Now we can get into semantics, but remember that code isn't always imperative. There's a whole world that can be called declarative programming. A common example of declarative programming is HTML. The author of HTML declares the content, and the browser must make sense of the content and display it. However, the HTML author is blissfully unaware of how it happens.
This perfectly describes an add-on level. The level declares what it will contain. The program knows how to parse this declarative model of a level, and thus it interprets it and runs the level.
What's the point
Most people would assume that Apple has this clause for security: you don't want programs to download code that would break your phone. However, I think this clause is actually more malicious than protective. I'm going out on a limb to accuse Apple of putting this clause in here to prevent Adobe from creating a stand-alone Flash player.
With this in mind, it makes perfect sense why this would be disallowed. But think about what we're missing out on (naming a couple off the top of my head):
- LOGO app: The ability to teach kids how to program using a simple language like LOGO.
- Mindstorms app: Think about the possibility of programming LEGO Mindstorms on an iPhone.
I really feel that the code execution/interpretation clause is hurting the iPhone more than it's helping. There is a minimal security risk, but there's already the same security risk with Javascript and media playing. Beyond that, if any bug in a programmers code can exploit the phone, the kernel and sandboxing aren't doing their job already.
This really boils down to the language of the agreement. The agreement is too open to interpretation that it's rendered useless. Apple needs to either get very specific in its definitions, or it needs to remove the clauses. There is nothing to be gained from pissing off developers. There is everything to gain from being the company who provides products that everyone loves developing for. Be that company, Apple.