Licensed C64 Emulator Rejected From App Store

Miasik.Net writes "A fully licensed Commodore 64 iPhone emulator has been rejected from the App Store. The excuse Apple used is a clause in the SDK agreement which doesn't allow for applications that run executable code. It seems Sega is exempt from that clause, because some of its games on the iPhone are emulators running original ROM code."

Re:Read the article much ?

[Bluecobra]

If you RTFA, you will find that Manomio contacted Apple Europe before developing the app and they "seemed really excited". So here we have yet another developer wasting time and money just to have Apple reject another application despite approving others that do the same thing. I really hope Manomio decides to port his C64 app to the Android instead so some of us can enjoy it.

Re:Running specific or arbitrary code?

[MtHuurne]

After reading the article and the Manomio's site, I get the impression that they do not run arbitrary code, but they do download the game images separately from the emulator, which the license does not allow.

Re:Oh, don't be an idiot.

[Vellmont]

This is an app that should never have even been started, because it very clearly violates the SDK agreement

Apple UK didn't seem to think it violated the SDK agreement, as they gave the go-ahead (As per the article). It was only later that the app was rejected when it was submitted to the app-store.

So get the hell off your high horse already and live in the real world.

I live in the real world. My real world has people being behind agreements (multiple people with competing interests), not them being a series of arbitrarily laws that are followed in a vacuum without looking at the larger picture. I suspect what will happen here is that either Apple will change its mind and allow this app, or the app will be slightly modified to satisfy Apple's requirements.

Re:Idiotic Summary

[Anonymous Coward]

The only way a C64 program could "break out" is if the emulator has a security hole - and how is this different from any other app? sendmail and BIND aren't emulators, yet they've had tons of security holes.

Re:Idiotic Summary

[eddy]

>But let's not start reviling them for merely following their stated policy.

If they are following their stated policy, explain how "sid player [apple.com]" was okayed, since it's an emulator that interprets executable code, which is downloaded on-the-fly.

I think the problem people have with the appstore, is that Apple enforce their policies using dice.

Are the ROMs downloaded on the fly?

[strags]

Look - here's the relevant part of the agreement:

"3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s)."

Particularly this part:
"No interpreted code may be downloaded and used in an Application"

Does the emulator allow users to download ROMs over the internet? If so, then there's a problem. If not - ie. there are a number of licensed ROMs embedded in the application, then there should be no problem. Simple. He just needs to release each game-pack as a self-contained app - that's all.

Re:Backwards, I hope

[Sique]

It's easy if you are allowed to emulate a second per hour.

Re:Running specific or arbitrary code?

[Anonymous Coward]

Because if one day Apple accepts one interpreter that runs arbitrary code, then from now on people can publish their app as a data file for the interpreter, sidestepping Apple's accept/reject process for apps.

Re:SIDs contain code.

[Foolhardy]

The 6581 SID chip, which produces sound on the C64 is not programmable. The 6510 CPU has to spoon feed it commands to produce a song.

.MID files and windows metafles are a sequence of commands with parameters and (for MIDIs) timings that describe content. These commands are a high level description of the content. A generic player is capable of interpreting these instructions to render output. The C64 never had a common format like that for music. Instead, each song is a unique program for the 6510 CPU dedicated to a single song that outputs through the SID chip. Instead of describing notes directly, it has 6510 machine code instructions for loading registers, doing arithmetic, storing to memory, controlling hardware, etc. just like it was a real computer. These are usually created by excising the music portion of a larger program to make it a standalone program that just plays a song with no input. To play a song, an emulator for the 6510, 6581, memory, ROM and enough other hardware is required to let the sound program execute like it would on a real 64, controlling emulated the SID chip the same way.

This format is popular because the vast majority of original music was already in program format, and the machine code programs are much shorter than a literal description of the program's SID output.

See MOS Technology SID - Software emulation [wikipedia.org]

I agree that Apple should be able to verify that full emulator is safe to execute arbitrary code that can't escape, but as other posters have noted, this may not be Apple's only concern.

Re:Running specific or arbitrary code?

[laird]

Exactly. Congrat's on being the only person in the discussion to read the article.

Apple did not reject the app because of emulation. Apple rejected the app because it contains a C64 Store that looks like it bypasses the Apple Store, allowing users to download C64 software straight into the emulator. That's prohibited, whether it's interpreted or compiled.

All of this was clear in Apple's rejection notice, quoted in the actual article.