Wow! This was unexpected. I was Googling for references to my recent Time Bomb app, curious if anyone has mentioned the game on any web sites, and I came across a blog entry on CNET.com, called "You Stole this (iPhone) Game!".
What do you know? It's an article talking about how my Time Bomb app pops up a message when users run a pirated version of the app. Specifically, if the app detects it is not a valid copy, it will display the message "You stole this game! Since this isn't a legal copy of the game, it is not going to function properly." And then, as promised, the app isn't going to function properly.
Sure, if someone wants to invest the time, they can by-pass these countermeasures (I wouldn't be surprised if they already have). And, then, in my next update, I can add more countermeasures which will take even more time for someone to bypass. But at some point, you have to wonder, why is someone spending so much time trying to crack an app that only costs 99 cents?
I decided to be obvious about the theft detection. Based on what I've read on some forums, other developers are taking a more stealthy approach and are silently gathering information from the offending iPhone or iPod Touch. Personally, I don't think the theft of my app gives me the right to violate the thief's privacy. It's the whole "two wrongs don't make a right" thing.
Tuesday, February 24, 2009
Friday, February 13, 2009
The biggest hurdle with iPhone app development - Apple!
Many developers have complained about this topic, and now it's time for me to officially add my voice to growing chorus. Apple's app review process needs improvement. It is totally inconsistent and arbitrary. One app might get rejected for reason X, while dozens of other apps are already approved in the iTunes store demonstrating the same rejected feature.
The reviewers will often attempt to justify the rejection as the app fails to meet Apple's Human Interface Guidelines (HIG). These guides are published in a PDF document freely available on Apple's developer website. My main complaint is what the review states in reference to a HIG violation is often not even found in the HIG.
For example, I recently received a rejection email from Apple for an update to my app "The Gavel".
First, let me explain what my app does. It displays an image of a gavel and lets the user shake the phone to move the gavel on the screen. When the gavel hits the edge of the screen, it plays a sound simulating an actual gavel. This version of the app is already in the store. Also, to clarify, there are 9 other objects simulated in the app, each with a unqiue sound effect. (If you are interested, you can see the app in the iTunes store here.)
Now, my latest update to the app included random effects that might occur. There's a random chance you might crack the screen of the phone (and a crack is randomly drawn on the screen). There's also a random chance that an object might break and the graphics and sound effect update to reflect the broken item. None of the random breakage is permanent. If you scroll to a new object, the broken item is automatically repaired, and any crack simulated on the screen goes away after 20 seconds and (of course) goes away if you exit the app.
Best I can determine from Apple's email is they don't like the fact that I simulated a cracked screen. Based on their email, Apple's reason for rejection is my app "uses standard iPhone screen images in a non-standard way, potentially resulting in user confusion." They go on to elaborate that "simulating failures of those graphics, actions, or images is a violation of the iPhone Developer Program agreement which requires applications to abide by the Human Interface Guidelines." There is nothing in the HIG that says this. Yes, the HIG says you should only use buttons and icons to represent actions that are standard for whatever that button might be. For example, you shouldn't use the standard supplied Trashcan icon to send an email message.
But, in my case, I'm not changing the behavior of any graphics. I'm not even altering any of Apple's standard screen images. I am overlaying the whole screen with a bitmap image that looks like a crack, but the behavior of the phone and the underlying graphic images are unchanged. Everything still works.
And, to quote from the HIG:
In the app update description I clearly state that new random events were added to the app and that none of the simulated damage is permanent. I even use the phrase "Don't panic" to make it clear this is all just part of the fun of the app.
Perhaps I'm missing the key passage in the HIG that says "simulating failures of those graphics, actions, or images is a violation of the iPhone Developer Program agreement". I've double-checked my copy of both the HIG and the SDK agreement and can't find where they mention this.
It's difficult and extremely frustrating for a developer to try to produce software under these conditions. You must first spend the time developing a piece of software and not until you are finished will you know whether Apple will accept it. Granted, the programming for "The Gavel" is not rocket science programming. Thankfully, it's a pretty basic app so I didn't lose too much time. But, the point is, I've lost some time and that's the risk you run developing apps for the iTunes store.
Right now, I'm leery of committing any serious amount of time towards developing an app when I have no idea whether it might be rejected in the end by Apple.
After having successfully submitted over 30 apps to Apple, I have seen my share of rejections for various nit picky reasons. At this point it's getting tempting to just bail on the whole idea of working through such a frustrating approval process.
In case you are curious, here are some screenshots demonstrating the offensive material in my app:
The reviewers will often attempt to justify the rejection as the app fails to meet Apple's Human Interface Guidelines (HIG). These guides are published in a PDF document freely available on Apple's developer website. My main complaint is what the review states in reference to a HIG violation is often not even found in the HIG.
For example, I recently received a rejection email from Apple for an update to my app "The Gavel".
First, let me explain what my app does. It displays an image of a gavel and lets the user shake the phone to move the gavel on the screen. When the gavel hits the edge of the screen, it plays a sound simulating an actual gavel. This version of the app is already in the store. Also, to clarify, there are 9 other objects simulated in the app, each with a unqiue sound effect. (If you are interested, you can see the app in the iTunes store here.)
Now, my latest update to the app included random effects that might occur. There's a random chance you might crack the screen of the phone (and a crack is randomly drawn on the screen). There's also a random chance that an object might break and the graphics and sound effect update to reflect the broken item. None of the random breakage is permanent. If you scroll to a new object, the broken item is automatically repaired, and any crack simulated on the screen goes away after 20 seconds and (of course) goes away if you exit the app.
Best I can determine from Apple's email is they don't like the fact that I simulated a cracked screen. Based on their email, Apple's reason for rejection is my app "uses standard iPhone screen images in a non-standard way, potentially resulting in user confusion." They go on to elaborate that "simulating failures of those graphics, actions, or images is a violation of the iPhone Developer Program agreement which requires applications to abide by the Human Interface Guidelines." There is nothing in the HIG that says this. Yes, the HIG says you should only use buttons and icons to represent actions that are standard for whatever that button might be. For example, you shouldn't use the standard supplied Trashcan icon to send an email message.
But, in my case, I'm not changing the behavior of any graphics. I'm not even altering any of Apple's standard screen images. I am overlaying the whole screen with a bitmap image that looks like a crack, but the behavior of the phone and the underlying graphic images are unchanged. Everything still works.
And, to quote from the HIG:
An immersive application tends to hide much of the device’s user interface, replacing it with a custom user interface that strengthens the user’s sense of entering the world of the application. Users expect seeking and discovery to be part of the experience of an immersive application, so the use of nonstandard controls is often appropriate.
In the app update description I clearly state that new random events were added to the app and that none of the simulated damage is permanent. I even use the phrase "Don't panic" to make it clear this is all just part of the fun of the app.
Perhaps I'm missing the key passage in the HIG that says "simulating failures of those graphics, actions, or images is a violation of the iPhone Developer Program agreement". I've double-checked my copy of both the HIG and the SDK agreement and can't find where they mention this.
It's difficult and extremely frustrating for a developer to try to produce software under these conditions. You must first spend the time developing a piece of software and not until you are finished will you know whether Apple will accept it. Granted, the programming for "The Gavel" is not rocket science programming. Thankfully, it's a pretty basic app so I didn't lose too much time. But, the point is, I've lost some time and that's the risk you run developing apps for the iTunes store.
Right now, I'm leery of committing any serious amount of time towards developing an app when I have no idea whether it might be rejected in the end by Apple.
After having successfully submitted over 30 apps to Apple, I have seen my share of rejections for various nit picky reasons. At this point it's getting tempting to just bail on the whole idea of working through such a frustrating approval process.
In case you are curious, here are some screenshots demonstrating the offensive material in my app:
Thursday, February 5, 2009
Time Bomb - an iPhone game
I'm am very happy to announce Stormy Productions' latest iPhone game is now available for purchase on iTunes.
It's called "Time Bomb" and is basically a simple "beat the clock" dexterity game. You are presented with a time bomb and need to use your assortment of tools to deactivate it. Use a screwdriver to remove the access panel, then a probe to listen for the armed wires, and finally cut the proper wires to complete the job.
The bomb settings are all customizable and the top ten times for each bomb type are saved.
You can read more about it (and watch a really rough video demo) at the official web site TimeBombGame.com.
It's called "Time Bomb" and is basically a simple "beat the clock" dexterity game. You are presented with a time bomb and need to use your assortment of tools to deactivate it. Use a screwdriver to remove the access panel, then a probe to listen for the armed wires, and finally cut the proper wires to complete the job.
The bomb settings are all customizable and the top ten times for each bomb type are saved.
You can read more about it (and watch a really rough video demo) at the official web site TimeBombGame.com.
Subscribe to:
Posts (Atom)
Posts
