So Apple just rejected PlaceTagger for the 3rd time. This go around, the reviewer kindly sent this useless message:
Your application, PlaceTagger, cannot be posted to the App Store at this time because it does not adhere to the iPhone Human Interface Guidelines as outlined in iPhone SDK Agreement section 3.3.5.
When the device is not connected to a network, PlaceTagger does not display a network alert. This behavior might lead to user confusion. It would be appropriate to display either a notification or an alert stating that internet connectivity is required.
That’s fine and dandy but PlaceTagger does not require a network connection to function. It just requires location services. If a network connection is available, it is used to display the optional map. We’ve submitted the app for the 4th time (edit: with an additional label on the screen). digg this and save a unicorn.
Update: It took a little while but Apple did finally approve PlaceTagger and we appreciate it.
Good luck! Seems like this app store model is unsustainable…
Ridiculous! As a beta tester, I know this is a really useful and interesting application. Apple is preventing the iPhone from rechingits full uesfulness. ‘Cummon!
Although I like what I hear of the app, if you refuse to change it, you aren’t going to succeed in getting the app in. I want the app, but if the developer refuses to change it, I too will refuse to support it, and ask others not to get it.
@Jobos – As stated in the article, we did make a change to comply with their request. The problem is, the change was completely unnecessary; PlaceTagger does not rely on a network connection to function properly. This rejection process will delay the release of our app by at least another week. Also, please note that this is the 3rd rejection. The first two were because of very small, but real, problems. We fixed those and resubmitted without complaint. If anything, that should prove that we are more than willing to make any necessary changes.
You are delayed a week to comply with usibility guidelines? what is the big deal? A week going to break your company? If so, really tight timing, but if you have fixed the problem already and submitted again, what are you hoping to rally behind? “Apple please don’t reject us again. People think that we are all ok, see?”
I hope you get through this time but I honestly don’t know what the rally and cry is about. Standard interfaces = better understood flow for all users. Perfect? no. Apple to the core for all of its products from day one? oh yes.
and no, not a zealot. I have several OSes and enjoy them all and wouldn’t pick just one.
Obviously the point of this post is being missed. If the app truly did not comply with the human interface guidelines, there would be no issue. The fact is, the issue it was rejected on already complied fully with the guidelines. This, along with many other instances discussed ad nauseam around the web, prove that Apple’s app approval process is incompetent and in great need of an overhaul.
No, a weeks worth of lost sales will not break our company, but losing any sales because of Apple’s mistake is unjust. That’s the point.
@andy – great, but how does that usability requirement apply if the app doesn’t require a connection to perform its main function?
amro,
I am often surprised that people expect that much from the reviewers. Keep in mind, the reviewers aren’t programmers. With Apple’s workload, I bet all the programmers are doing development, QA if not development, developer support if not QA, tech documentation if not support….
You get my idea.
They may have some programming training, but they aren’t gods and they can only make guesses how you implement your code. Heck, if I see your app running, will I assume it is using network?
They may be wrong. Everyone can be wrong. So what? If you are not using connection, tell them that, offer to show your code. Tell them to turn iPhone into flight mode and test again.
After all, reviewers are human too.
@John – I agree with you completely. Problem is, there’s no way to communicate with the reviewer. Perhaps a place to outline step-by-step instructions of the purpose of the app for the reviewer to see would be a possible solution. Regardless, all it takes is for the reviewer to make an incorrect assumption and back to the end of the line you go. There should be no room for assumptions, give us a place to be specific.
@ Drew, i think what apple is getting at, is that you have to notify the app user that you’re going to use the network. The idea being that the app shouldn’t be using a network unless the user is aware.
I can understand why apple rejected it, it’s just too bad that it’s the third time around being rejected. Also there should be an option to not allow the app to use the internet, and to make apple really happy you should have a dialog box come up the first time it tries to connect to a network just to warn the user.
@Eric – I think I’ve not explained the reason for rejection very well. The problem is actually just the opposite.
If an internet connection is not available, PlaceTagger cannot load its maps. In the rejected build, it simply did not show the map (it kept the logo on screen). Our reasoning was since location data can still be recorded, there was no reason for user interaction (why make someone hit a button when the primary purpose is still being achieved?).
I suppose users could use the application with the map up all the time, but with the limited battery life of iPhone, we expect they’ll just put it in their pocket so the screen will shut off (ala the proximity sensor) and focus on taking pictures. Given that the purpose of this app is to record location data and later geotag photos, we believe not seeing the map (and more importantly not bothering a user who’s trying to take pictures) is the right thing to do. Perhaps Apple’s reviewer disagrees. That’s fine. We added a label and it is what it is. That doesn’t change the frustration that comes along with feeling like 3 weeks of your time have been wasted.
These issues seem to crop up over and over for silly things (imo, poorly trained folks who misinterpret the UI guidelines..). In this case, we really believe it’s nonsense. There are other cases where the rejection decisions are entirely valid.
@ Amro
Oh ic what you mean, i was thinking that they wanted a dialog of when it connected, but you’re saying they wanted a dialog when it lost it’s connection?
Kinda seems a little odd, i can see that you would want to notify users as to why the map isn’t working, but you’d think that users would pick up on that pretty fast.