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"...
I am sick and tired of this meme. You confuse authority and defensibility. Yes, Apple has the authority to do this. No, it is NOT ethically right for Apple to do this. It's not a new meme. In 1734, Alexander Pope published "An Essay on Man [theotherpages.org]":
And spite of Pride, in erring Reason's spite, One truth is clear, Whatever is, is right.
The idea was corrosive back then, and it remains corrosive today. Knock it the fuck off.
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...
Is there any proof of this?
Even if there is, there is a distinct difference between an emulator packaged with a single ROM, such
High horse? At least I'm not stuck in the intellectual mud like you are. All of you people are ignoring the larger problem here, which is that Apple purports to control the applications a customer runs on a device he's purchased outright. It's ludicrous. Apple has no moral authority to set these rules at all.
The larger problem here is that Apple can reject applications at all. You people seem to have passively accepted it. It's as if you were in Salem arguing about whether a witch should have been burned or hanged while ignoring the larger question is whether you should execute the alleged "witch" at all!
That device didn't pretend to allow for complete customizability. It was sold as a device that could and couldn't do certain things. If someone doesn't like the lock Apple has on the application store, then they have the option of not buying the device.
I disagree. While Apple has the right to reject the emulator from their own store I refuse to accept that they have the right to bar this person from developing any product he wants for it. Just because a wrench is designed for a 5/8" bolt doesn't mean you can't use it as a pry bar, but that is specifically what Apple is trying to do with their "EULA" of the SDK and I find that reprehensible.
While it is true that a person has the option to not buy a product. You fail to take into account that they also have the innate right of altering any product they own however they see fit. Anyone who disagrees with that is ignoring one of the fundamental driving forces of innovation for the last several millenia.
Hear hear. If you want to write an AIM client that runs in the background you can do so. If you want to buy an iPhone, take it apart, and put it back together in a Kindle, that's fine. No problem. Do whatever you want to do. Apple isn't stopping you from doing whatever you want to do with your iPhone.
Just don't expect Apple to distribute it for you. Just don't expect Apple to make it convenient for you to distribute it. Just don't expect any support from Apple after you've done these things.
Basically, if you do these things, you're on your own. That doesn't preclude you from doing it. It just means nobody is going to help you out if you turn your iPhone into a very expensive brick. It means that if your battery won't hold a charge because you wrote an app that drained the battery in 20 minutes and you now have to send your phone in for battery replacement 4 years earlier than expected, don't blame Apple.
That device didn't pretend to allow for complete customizability. It was sold as a device that could and couldn't do certain things.
And the annoyance is that those limitations are entirely imposed by Apple's business and marketing sides. Before the app store, Apple and its fanboys were firmly declaring that there shouldn't be third party apps for the iPhone because it didn't have enough power to run them, and it would lead to widespread viruses and disruption of the phone network, and web apps were just as
The device was sold specifically without that capability, so why is modding it to do so seen as a right?
It's my right because I OWN the device.
As a former owner, Microsoft has no control over what I do with the device. If I sell a house, I have no say over whether the new owner paints all the rooms lime green and puts in red shag carpeting. It's not my house anymore. Likewise, when I buy a 360, it's not Microsoft's 360 anymore.
It's called "private property", and it's been part of Western culture for at leas
The device was sold specifically without that capability, so why is modding it to do so seen as a right?
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.
I'm not seeing this as an ethical issue. I may wish that Apple's terms of use for the iPhone were more accepting of a particular type of application, but all developers know the terms before they even start coding. This case is different from Sega because this one interprets arbitrary code while Sega's apps run hard-coded ROMs. The term arbitrary is important, and it clearly means that this app is indeed against Apple's terms of inclusion into their store.
Does it suck? Yeah. Unethical? That's a stretch...
Maybe that's how it used to be, back in the good old days (of "help I'm dying of polio!").
These days, there is no competition in SMS pricing; it's 25c no matter what carrier you go with. If that's not collusion, I don't know what is. SMS is something rather useful for a significant portion of the cell-phone-purchasing population, so it would make sense for carriers to compete on price in order to garner the most market share. But they don't; each SMS is 25c, no matter what.
Seems like something our legislative overlords should have more than a passing interest in...
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.
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.
Their emulator is capable of executing arbitrary BASIC code. That's like complaining that you spent a bunch of time writing a Java emulator for the iphone but then it was rejected. It's clearly disallowed, and that's not unreasonable--if they didn't disallow it, it would basically make the app store completely useless. People could write apps that were specifically intended to run on your execution platform, and completely bypass the app store. While you may not agree with this decision, it's reasonable as-is.
What I'm certain they'll be able to do is what Sega and others have done, and release a game pack that has a few games, but doesn't support downloadable content, or release one (or a few) game(s) at a time that uses their emulator backend for $0.99 each. I suspect as long as they don't expose their emulator directly, they'll be fine.
(And frankly, if you're going to argue that a programmable calculator or even a chip-8 emulator is in the same category as a BASIC interpreter, you're simply wrong).
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).
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.
I agree with you Space cowboy. When the SDK agreement came out I was talking to someone who was working on a C64 emulator for the iPhone (not the emulator in this story incidentally) and I said "But the agreement expressly forbids emulators."
Yes, I agree it's wrong that Sega can do this (assuming they actually are and there isn't some change with how they're doing stuff under the hood), but the fact is me, a non-coder, has known that emulators wouldn't be allowed under the agreement.
I guess the best outcome would be that with this gaining attention and the Sega thing that the rules change. That would be great, but even if he was told it's okay, I would expect he didn't check multiple times. One thing I've learned over the years with red tape is if you speak to three different people, you'll invariably get 3 different answers. Getting one response is not very helpful.
If the author really DID have a leg to stand to on, he'd have evidence to prove to Apple he was told it would be okay.
Instead it's yet another case of an app being turned down and the Slashdot community crying "fuck Apple" and the usual tired cliches.
On the contrary, I've owned and sold companies even. I have a *lot* of experience with contracts at a reasonably high level, which is why I stressed the importance of getting something in writing.
In my dim and distant youth, one large company (which shall remain nameless) strung us along for years before finally buying us. I'm well aware of the dangers of nods-and-winks, and I'm well aware that they're completely and utterly worthless. Get it in writing or you don't have anything.
What I don't have any sympathy for is agreeing to X then complaining it means you can't do Y, when the initial agreement specifically pointed out you can't do Y. It's not as though it's some unexpected corollary of a sub-clause hidden in the fine-print - it's right out there in the open. You cannot load executable code. End of story.
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?
...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?
...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?
Hint: They don't [care so much], otherwise they would stop using it. The only ones who really do care are 0.00001% of iPhone users (who also happen to read slashdot, by the way).
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
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?
They don't want to lose the ability to approve all apps. If the emulator in its current form can load other ROMs or BASIC programs then you have a way of bypassing the App Store after the first purchase. I assume Sega made sure that their package could only run the one game it sold with and thus could not be used to bypass the app store.
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.
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.
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.
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.
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.
>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.
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.
Right. Now you've discovered that Apple's restrictions don't have anything to do with technical quality. Instead, they're just designed to provide Apple an excuse to ban any application that might threaten Apple's revenue stream.
That kind of behavior shouldn't be allowed on a mass-market platform like the iPhone. Nobody should have the authority to tell me what applications I can run on a device I own, just like a publisher can't tell me not to resell a book.
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.
"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.
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 do
Editorialise much ? (Score:4, Insightful)
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
Re:Editorialise much ? (Score:5, Insightful)
I am sick and tired of this meme. You confuse authority and defensibility. Yes, Apple has the authority to do this. No, it is NOT ethically right for Apple to do this.
It's not a new meme. In 1734, Alexander Pope published "An Essay on Man [theotherpages.org]":
The idea was corrosive back then, and it remains corrosive today. Knock it the fuck off.
Parent
Oh, don't be an idiot. (Score:3, Insightful)
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...
Re:Oh, don't be an idiot. (Score:5, Insightful)
High horse? At least I'm not stuck in the intellectual mud like you are. All of you people are ignoring the larger problem here, which is that Apple purports to control the applications a customer runs on a device he's purchased outright. It's ludicrous. Apple has no moral authority to set these rules at all.
The larger problem here is that Apple can reject applications at all. You people seem to have passively accepted it. It's as if you were in Salem arguing about whether a witch should have been burned or hanged while ignoring the larger question is whether you should execute the alleged "witch" at all!
Parent
Re: (Score:3, Insightful)
Re:Oh, don't be an idiot. (Score:4, Insightful)
While it is true that a person has the option to not buy a product. You fail to take into account that they also have the innate right of altering any product they own however they see fit. Anyone who disagrees with that is ignoring one of the fundamental driving forces of innovation for the last several millenia.
Parent
Re:Oh, don't be an idiot. (Score:5, Insightful)
Hear hear. If you want to write an AIM client that runs in the background you can do so. If you want to buy an iPhone, take it apart, and put it back together in a Kindle, that's fine. No problem. Do whatever you want to do. Apple isn't stopping you from doing whatever you want to do with your iPhone.
Just don't expect Apple to distribute it for you. Just don't expect Apple to make it convenient for you to distribute it. Just don't expect any support from Apple after you've done these things.
Basically, if you do these things, you're on your own. That doesn't preclude you from doing it. It just means nobody is going to help you out if you turn your iPhone into a very expensive brick. It means that if your battery won't hold a charge because you wrote an app that drained the battery in 20 minutes and you now have to send your phone in for battery replacement 4 years earlier than expected, don't blame Apple.
Parent
Re: (Score:3, Interesting)
That device didn't pretend to allow for complete customizability. It was sold as a device that could and couldn't do certain things.
And the annoyance is that those limitations are entirely imposed by Apple's business and marketing sides. Before the app store, Apple and its fanboys were firmly declaring that there shouldn't be third party apps for the iPhone because it didn't have enough power to run them, and it would lead to widespread viruses and disruption of the phone network, and web apps were just as
Re: (Score:3, Insightful)
It's my right because I OWN the device.
As a former owner, Microsoft has no control over what I do with the device. If I sell a house, I have no say over whether the new owner paints all the rooms lime green and puts in red shag carpeting. It's not my house anymore. Likewise, when I buy a 360, it's not Microsoft's 360 anymore.
It's called "private property", and it's been part of Western culture for at leas
Rights vs Support (Score:4, Insightful)
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
Parent
Re:Oh, don't be an idiot. (Score:4, Insightful)
>Apple has no moral authority to set these rules at all.
Let me put this in simple terms for you.
It's their ball. They get to choose the rules.
They do not have the monopoly on phone handsets. Buy another and get over it.
I can't be the only person who loved the iPhone but thought "I'll wait till a handset that I can put my own apps on comes along".
The openmoko project is an attempt at this, and one day it will happen, but until then I'll keep my cash in my wallet.
Parent
Re:Editorialise much ? (Score:5, Insightful)
Does it suck? Yeah. Unethical? That's a stretch...
Parent
Re: (Score:3, Insightful)
> And I'm sick and tired of this entitlement meme.
It's not "entitlement" to desire control of one's own property.
Yes: an iPhone becomes my property when I buy it.
So does a copy of "The Martian Chronicles" (on book, ebook or DVD).
Re:Editorialise much ? (Score:5, Interesting)
Maybe that's how it used to be, back in the good old days (of "help I'm dying of polio!").
These days, there is no competition in SMS pricing; it's 25c no matter what carrier you go with. If that's not collusion, I don't know what is. SMS is something rather useful for a significant portion of the cell-phone-purchasing population, so it would make sense for carriers to compete on price in order to garner the most market share. But they don't; each SMS is 25c, no matter what.
Seems like something our legislative overlords should have more than a passing interest in...
Parent
Re:Read the article much ? (Score:5, Informative)
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.
Parent
Re: (Score:3, Interesting)
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."
Re:Read the article much ? (Score:5, Insightful)
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
Parent
Re:Editorialise much ? (Score:5, Insightful)
He's not trolling. Did you read the article?
Their emulator is capable of executing arbitrary BASIC code. That's like complaining that you spent a bunch of time writing a Java emulator for the iphone but then it was rejected. It's clearly disallowed, and that's not unreasonable--if they didn't disallow it, it would basically make the app store completely useless. People could write apps that were specifically intended to run on your execution platform, and completely bypass the app store. While you may not agree with this decision, it's reasonable as-is.
What I'm certain they'll be able to do is what Sega and others have done, and release a game pack that has a few games, but doesn't support downloadable content, or release one (or a few) game(s) at a time that uses their emulator backend for $0.99 each. I suspect as long as they don't expose their emulator directly, they'll be fine.
(And frankly, if you're going to argue that a programmable calculator or even a chip-8 emulator is in the same category as a BASIC interpreter, you're simply wrong).
Parent
Re: (Score:3, Interesting)
What about arbitrary javascript on web pages? By your logic, a Flash player would be out of the question.
Re: (Score:3, Interesting)
Hell, a browser would be out of the question (for the same reasons...)
Re:Editorialise much ? (Score:4, Interesting)
And what exactly is so important about the app store that it cannot be bypassed?
Parent
Re:Editorialise much ? (Score:5, Funny)
And what exactly is so important about the app store that it cannot be bypassed?
Profit.
Parent
Re:Obligatory Edsger Dijkstra (Score:5, Insightful)
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).
Parent
Re:Obligatory Edsger Dijkstra (Score:4, Insightful)
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.
Parent
Re:Editorialise much ? (Score:4, Funny)
Me too. I'm waiting for the obligatory "The 1980s called and they want their language back" jokes. :o)
Even the 1980's don't want that language back
Parent
Re:Editorialise much ? (Score:4, Insightful)
I agree with you Space cowboy. When the SDK agreement came out I was talking to someone who was working on a C64 emulator for the iPhone (not the emulator in this story incidentally) and I said "But the agreement expressly forbids emulators."
Yes, I agree it's wrong that Sega can do this (assuming they actually are and there isn't some change with how they're doing stuff under the hood), but the fact is me, a non-coder, has known that emulators wouldn't be allowed under the agreement.
I guess the best outcome would be that with this gaining attention and the Sega thing that the rules change. That would be great, but even if he was told it's okay, I would expect he didn't check multiple times. One thing I've learned over the years with red tape is if you speak to three different people, you'll invariably get 3 different answers. Getting one response is not very helpful.
If the author really DID have a leg to stand to on, he'd have evidence to prove to Apple he was told it would be okay.
Instead it's yet another case of an app being turned down and the Slashdot community crying "fuck Apple" and the usual tired cliches.
Parent
Re:Editorialise much ? (Score:5, Insightful)
In my dim and distant youth, one large company (which shall remain nameless) strung us along for years before finally buying us. I'm well aware of the dangers of nods-and-winks, and I'm well aware that they're completely and utterly worthless. Get it in writing or you don't have anything.
What I don't have any sympathy for is agreeing to X then complaining it means you can't do Y, when the initial agreement specifically pointed out you can't do Y. It's not as though it's some unexpected corollary of a sub-clause hidden in the fine-print - it's right out there in the open. You cannot load executable code. End of story.
Simon.
Parent
Executable code: includes javascript? I'm confused (Score:4, Interesting)
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?
Parent
I voted the story down.. (Score:5, Insightful)
...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?
Re:I voted the story down.. (Score:5, Insightful)
...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?
Hint: They don't [care so much], otherwise they would stop using it. The only ones who really do care are 0.00001% of iPhone users (who also happen to read slashdot, by the way).
Parent
Right idea, wrong reason (Score:3, Insightful)
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
Re:Right idea, wrong reason (Score:5, Funny)
So, you're saying that whining on Slashdot is actually useful?
The mind boggles, it does.
Parent
The hell are they thinking? (Score:3, Interesting)
Re: (Score:3, Insightful)
They don't want to lose the ability to approve all apps. If the emulator in its current form can load other ROMs or BASIC programs then you have a way of bypassing the App Store after the first purchase. I assume Sega made sure that their package could only run the one game it sold with and thus could not be used to bypass the app store.
Re: (Score:3, Funny)
Backwards, I hope (Score:5, Funny)
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
Running specific or arbitrary code? (Score:5, Insightful)
Re:Running specific or arbitrary code? (Score:5, Informative)
Parent
Re:Running specific or arbitrary code? (Score:5, Informative)
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.
Parent
GET THE FACTS: Not rejected from the App Store (Score:5, Funny)
Apple is about quality first and they are just holding back the release date until the iPhone's cassette tape inferface is ready.
Non entirely unreasonable ... (Score:3, Insightful)
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
Idiotic Summary (Score:5, Insightful)
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.
Re: (Score:3, Informative)
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 (Score:5, Informative)
>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.
Parent
What would they do with an Apple ][ emulator? (Score:3, Interesting)
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 ...
What is "executable code"? (Score:5, Insightful)
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.
Re:What is "executable code"? (Score:5, Insightful)
Right. Now you've discovered that Apple's restrictions don't have anything to do with technical quality. Instead, they're just designed to provide Apple an excuse to ban any application that might threaten Apple's revenue stream.
That kind of behavior shouldn't be allowed on a mass-market platform like the iPhone. Nobody should have the authority to tell me what applications I can run on a device I own, just like a publisher can't tell me not to resell a book.
Parent
This article is extremely misleading (Score:3, Insightful)
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.
Are the ROMs downloaded on the fly? (Score:3, Informative)
"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: (Score:3, Insightful)
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 do