Recently in the news, a Commodore 64 emulator with a bunch of legally licensed games was rejected from the iPhone App Store. Normally this would be a simple case of âdidnât you read the license agreement?â except that apparently they had previously run the idea past Apple Europe to positive response.
I was chatting to a developer from a competing phone company at JavaOne, and he was telling me how annoying the competition found Apple's ability to turn the negatives of their platforms into positives.
The example he gave me was security. Other phone manufacturers have to go to great lengths to sandbox third-party applications, building a complex security model to defend against malware. Apple instead said âscrew thatâ and moved the security model up a level into the app store. I'm sure it's possible to get a malicious app approved, but it would involve registering as a developer and writing a potentially commercially viable app that would pass Apple's quality control, and Apple could throw the kill switch on it the moment they discovered it was malware.
This is the root of the âno emulatorsâ provision. Apple needs to control the code running on the iPhone. Emulators open the door to unapproved code. Hence emulators can not be approved.
It is likely a C64 emulator would itself protect the iPhone from malicious apps, since emulated apps already run in the sandbox of emulated hardware. Sure, Apple wants to control the content on the phone, but given the new capabilities of iPhone 3.0, how are downloadable games different from any other kind of in-app purchasable content pack? This is what happens to rules once they are written down and removed from the reasoning behind them.
Certainly, Apple could go the extra mile and build a better application sandbox for the iPhone. But this just turns into the classic software development scheduling problem: âSure, we can do that. We can do anything you want. Just tell me which three features I should cut from the next release to get it done.â
Interestingly enough on the same trip I ran into a developer who was dipping his toe in Android development. He told me his second biggest frustration1 was the hardware. He was developing some cool graphical/physics demos, but even being sure that they could run smoothly on arbitrary Android phones, or even run without crashing, was turning out to be far too much work.
Once more, it's turning a weakness into a strength. Apple controls the iPhone hardware and the software that runs on it, against all the âhey, didnât the open PC platform win?â logic of the industry. Turns out that's the same logic that attracts games developers to the predictable hardware and software of consoles, despite the license hassles and limited hardware, over trying to tame the beast of PC gaming.
1 The first, apparently, being the primitive implementation of the Java Virtual Machine. These performance tips read like the sort of advice you'd give a 1990âs era Java developer, which makes sense once you discover the VM lacks a JIT compiler.
Previous Topic
