Slashdot Mirror
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."
It's not an "excuse", it's clearly against the terms of the *agreement* the developer *agreed* to *before* starting work on it.
You can argue that Sega ought to be treated the same way (and I'd agree with that), but to call it an "excuse" when the terms specifically and explicitly forbid it smacks of throwing one's toys out of the pram and screaming "waaaaaaaahhhh"! "I want, I want, I want!" is such an ugly character flaw when it's seen in "adults"...
Simon
Physicists get Hadrons!
...because I am tired of reports of apps not working on iPhone and other ways Apple limits it. If people care so much about freedom, why don't they stop using it?
What are they worried about, that a revival of BASIC will crowd out Apple market share...? Or did Sega maybe have a quiet word with Apple about the competition?
That which does not kill us makes us... st
An iPhone emulator that runs on a Commodore 64? Color me surprised!
Hopefully this means that I can upgrade my old boxes by emulating dual core processors on them. Links, anyone? ;)
-b
No offense, but I've stopped responding to AC's.
If I recall correctly, the limitation in the SDK license is that Apple will not allow an interpreter that runs arbitrary code. That would mean that an interpreter that executes a single hardwired game does not violate the license.
Apple is about quality first and they are just holding back the release date until the iPhone's cassette tape inferface is ready.
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.
From Apples perspective, I don't see this as entirely unreasonable.
They want to manage customer experience by controlling the environment. An app which can host arbitrary code could lead to exploits or other badness.
Code from the original ROMs is pretty well bounded and not going to do anything unexpected or malicious.
Now, that doesn't mean a bunch of people won't howl about this. But, for the average person buying a iPhone, I doubt they'll care.
Cheers
Lost at C:>. Found at C.
I think what Apple wants is to make sure you can't "add" more games without going to the appstore.
Individual games (eg the Sega ones referred to) are each a seperate app that you get from the App store. You arent getting a single "Sega" emulator which you can then get more roms (legit or otherwise) seperately from the app store.
Presumably the C64 emulator had no such limitation.
(I have an iPhone, its jailbroken and unlocked, and even though I can explain Apple's motivation for their restrictive policy, they can kiss my ass)
This isn't Apple using their broad unspecified powers to reject an app arbitrarily or for a moronic reason. If it were, I'd agree with you.
This is an app that should never have even been started, because it very clearly violates the SDK agreement, and anyone with half a brain would have known that Apple would reject it.
As for the assertion that Sega's games are just emulators...
So get the hell off your high horse already and live in the real world.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
You gotta do it the Apple way or go home. We have seen this time and time again with the app store.
Of course Sega is exempt; their programs are a single ROM, run via emulation. You don't buy a Sega hardware emulator and then download ROMs for it, so they can test it fully before allowing it to be released. An open emulator, able to run any ROM you give it, is essentially a way to run un-tested, 3rd party code on the platform. There's no way for Apple to be sure the programs stay within their virtual environment. In essence, it would be a way to circumvent the security and execution protection on the phone entirely; it's a jailbreaker.
I'm about as far from an Apple apologist as you can get, and can't wait for this app store bullshit to quiet down. But let's not start reviling them for merely following their stated policy. If these people want to release their emulator, they'll need to do what their competitors have: bundle it with specific games and sell THOSE instead.
Reject the one app that would have guaranteed me purchasing an iPhone.
The general pattern is:
1) App is arbitrarily rejected for some reason.
2) Angry story on Slashdot about rejection.
3) App is resubmitted and accepted with some minor change (or no change at all like in the case of the eBook reader).
The stories are lame because the review system is a little subject to the whims of any given reviewer now, after two submissions that fail then I'd start saying it might be worthy of a story.
That said, this rejection does not fall into this pattern. The development guidelines have been very clear about emulators, they are not allowed. This was widely reported. I personally think the person who submitted the app did do because they knew they would get rejected, knew they would then get publicity, and say "Hey, I'm releasing on the Cydia App Store".
So you are right to vote this down, but not for the reasons you think... this story is pure marketing.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If you RTFA, you will find that Manomio contacted Apple Europe before developing the app and they "seemed really excited".
Which could mean anything down to "I went to an Apple reseller and blathered about my idea to a salesdroid, and he seemed to like the idea."
Remember, this is Apple we're talking about. They get nothing from a C-64 emulation, fully licensed or otherwise.
But Apple ][ on the other hand ...
"No matter how cynical you get, it is impossible to keep up." -- Lily Tomlin
Last time I checked, the iPhone could not run C64 programs natively. So, essentially, the games are interpreted by the emulator (as it is with pretty much all emulators).
According to that logic, you'd have to ban any application with built in scripting (like, say, any office application that I'm aware of), hell, a PDF reader would be banned as well because PDFs may include scripts. If you want to go bonkers, you could pretty much ban any application that takes any kind of not built-in data because technically, this is interpreted by the application as well.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I hope so too. I'm not defending Apple here as much as defending the rightness of enforcing a contract. As I point out above, I don't believe he contacted Apple Europe anyway, because if he did he'd have something in writing along the lines of "Yes, you can develop your emulator and we will let you load it onto the iPhone".
Talking to someone from Apple marketing over the phone and getting a verbal "hey that sounds cool" is completely and utterly worthless. Getting written permission as above would give him a fully justifiable case (and probably a lawsuit). He's probably somewhere in the middle, but unfortunately unless you have the written permission, you have nothing.
Simon
Physicists get Hadrons!
It's pretty obvious. The people looking at app store submissions likely have only a very basic understanding of the issues involved, and the SDK agreement isn't very precise as to what falls and doesn't fall under this rule. So the results basically depend on the guy's gut feeling when he checks out the app. For example, I'm pretty sure the vast majority of them would consider a SID player a simple music player, even though it actually runs C64 machine code, just as they would probably accept a game with downloadable levels which include some form of built-in scripting as OK, as long as that part isn't explicitly pointed out somewhere.
No part of this is surprising. It's a crappy technical rule, and crappy technical rules don't work well when more than one person is supposed to enforce them.
This article is extremely misleading, resulting in tons of off-target flaming.
Apple doesn't prohibit apps using emulation, they prohibit apps that download and run arbitrary code, bypassing the Apple Store. The mistakes that the developers made were (1) putting a C64 Store into the app, and (2) putting a BASIC interpreter in the emulator. If it's tweaked slightly so that the games are downloaded through the Apple Store 3, and the BASIC interpreter is removed (it's useless anyway), I'm sure that it would be approved.
The developers probably decided to push the boundaries a bit in order to generate some news/press coverage. Pretty clever, actually - now Slashdot and other geek news sites is promoting them, and their app will still get approved in a week or two.
Enable 3D printed prosthetics!
It's my right because I OWN the device.
Just because you have the right to do something doesn't mean the manufacturer has to support it.
You are perfectly free to jailbreak your iPhone and install all sorts of unapproved software on it. So far as I know, there's nothing illegal about it, and the jailbreak community is pretty good at keeping on top of updates that fix previous methods of jailbreaking. Personally, I'm pretty happy with the selection of apps available through the App Store, and don't consider the hassle of jailbreaking worth the extra functionality I would be able to get. For others, the calculation is different.
"Moral authority" doesn't enter into it, mate.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
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.
The difference is that Apple wants a cut of every app sold for this platform and absolute control over everything that runs on it. Allowing anything not filtered through their review and sales process to execute on the phone, even in a sandboxed, virtualized environment, screws up their business model. And you know how companies get when you present a threat to their business model.
as potential programmers they are mentally mutilated beyond hope of regeneration.
What a stinky, steaming pile of horse crap!!! (Even if Holy Saint Dijkstra said it.)
Hundreds of thousands of programmers got their start writing C-64, TRS-80, Apple & Sinclair BASIC on their home computers before graduating to structured languages, and 10s of thousands of them turned out to e good or great programmers.
In fact, I know that it's perfectly possible to write good structured code in COBOL-74. You "just" need a good knowledge of the features of the language (in addition to the standard prerequisites required by all good programmers).
"I don't know, therefore Aliens" Wafflebox1
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
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.
No. But about the only one person who speaks for Apple is Steve Jobs. Other than that, everyone else has their own opinions on what's cool and what isn't.
Last week at WWDC, I spoke to someone at Apple who was interested in an App I'm working on. The problem is, parts of it need to run in the background for the best user experience. He agreed with me. That does not mean if I submit said app, it would be approved. What that means is that one person agrees with me--that my App would be better if it could run in the background.
Where would I go from here? Well, I need to find out from that one person who I would talk to about getting my app approved--the person I talked to wasn't the one person who gets to decide these things. I would need to talk to that person and see if there was a way for my app to be approved. Perhaps fly to Cupertino, CA, and demonstrate the usefulness of my app and the benefits of it being able to run in the background. Discuss the deficits of my App running in the background in regards to reduced battery life and general slowness and how I can ameliorate these issues.
In other words, I need to work my ass off playing politics with Apple.
Now, let's say Apple "seemed really excited." Apple may have seen this as a development tool. Let's say I wrote a C64 game. I could conceivably buy this guy's software, package it up with my game, and sell it in the iTunes Store. That may be why Apple "seemed really excited" about this--not as an App but as a tool for BASIC programmers to develop iPhone apps.
Actually, it is the reverse, in my experience. Most programmers I know started their craft with a Commodore 64, Apple II, or Atari computers; programming in BASIC. Only after realizing how limited and slow the language was were they even exposed to Assembly or Machine Language.
In my experience, then, programming in BASIC gave them the inspiration, the interest, and the impetus to learn the lower level languages, precisely because a good high-level language was not available. The fact that they knew BASIC, and could even exploit its intricacies, did not hinder their appreciation for other languages, nor their ability to learn or apply them.
-dZ.
Carol vs. Ghost
You cannot load executable code.
I'm not really sure how to interpret "load executable code". Is there non-executable code? What makes it code, then?
Browsers load and execute javascript. Is javascript not code, or is it not executed, or does it break the rules, or is there some option I'm missing?
Is GLSL also code? That means you can't run third party color filters like the compiz plugin which simulates colorblindness. I'm sure that's an important restriction... wait, what?
Can anyone explain to me what "load executable code" does and doesn't cover? And even better, what's the motivation for the distinction?
An important distinction here is that JavaScript code is known to be properly sandboxed by Apple and AT&T. This is also OK for the Sega games running as emulation of the original ROM; That is no different from a game app that has a data file in it. The problem comes when you allow users to load any code they want into a potentially unprotected environment. Then, this becomes a liability issue.
Apple wrote the JavaScript engine that runs on the iPhone. If there are flaws, they can push updates to fix it, or if it's severe enough disable some or all JavaScript until a fix can be made. The implications here are staggering - suppose a bug gets out into the wild which involves a JavaScript 'sploit followed by a 3G DDoS attack. AT&T's whole network becomes saturated, iPhone or not. This can disrupt E911 services. Because of a JavaScript bug, someone might die. It's unlikely, but if it happens it's a HUGE liability. Everyone from the family of the deceased to the state would have a stake in that lawsuit.
Apple has a failsafe here - they can shut it down before it spins out of control because they have access to the code. They can push updates out before their phones become an army of virus-spewing BlueTooth devices nailing ever PC (or even Mac) they come with in 30 feet of.
Now imagine it happens through a bug in this Commadore 64 App, or any other App that would allow executable code. Apple has little control over that, much less so than if a flaw was their own problem. Don't get me wrong, Apple has a good reputation for security, they build solid products, and what I describe here is very unlikely to happen.
...but it's not impossible.
CAn'T CompreHend SARcaSm?