I have submitted my first iPhone app and am now waiting for approval. My only fear is having it rejected because of some subtle nuance in the HIG, this is from googling around.
How does Apple treat the HIG, as guidelines or as gospel?
+2
A:
Guidelines. The bottom line is that it has to work, not use any private API or violate the terms of the agreement. If it does what it says it's going to do and doesn't crash right away, you'll probably be fine.
samkass
2010-08-28 02:51:13
That's like so nice (if apple were nice about it) :-)
Martin York
2010-08-28 02:53:52
Is not such a big deal, it's easy to get approved, but don't feel so secure about ignoring HIG. For example, if you have an iPad app with the new UIPopoverController and you popover arrow doesn't point to the object that revealed it, you get rejected.I was there.
sicario
2010-08-28 18:28:54
+6
A:
It all depends.
If you use the wrong icons for certain functionality. They will reject it.
If it is confusing to the user. They will reject it.
If the standard UI components do not work as expected. They will reject it.
If an operations fails without appropriate feedback. They will reject it
But they will usually tell you one item in the GUI that they rejected it for.
Thus when you fix it and send it back they can tell you about the next one.
Martin York
2010-08-28 02:57:25
Bottom line is that UI components that are standard, and are covered in the HIG, **must** behave as specified. You have a lot more leeway with controls and components that you create yourself. But to the extent that you use the standard stuff, triple-check every use against the HIG.
quixoto
2010-08-29 01:54:14
A:
The HIG is more a way to change your odds in a lottery. You greatly improve your odds by not doing anything that clearly looks like a violation of the HIG. There are web sites that list things that appear to at least one reviewer to be violations.
But there are many apps with fairly crufty UIs (that don't look HIG compliant to other devs) but somehow got accepted into the App store. On the other hand, one hears about other apps that are rejected for something that looked to the reviewer very different than it looked to you (would you confuse icon X for the completely different icon Y? & etc.) Or mistake the word "or" for "and" in one of the SDK Agreement rules?
hotpaw2
2010-08-28 04:24:50
+2
A:
It really depends on how much your devition results in a better user experience.
The HIG is there to help you build an application that users will understand how to use more or less from the start, and make the application easy to use.
If you do some custom things that improve life for the user, Apple will probably let it go. But if you are deviating in ways that make the application harder to use, they will tend to come down on you.
A lot of the possible rejections are pretty reasonably things - for example I was rejected once for a rotated view where the UI elements didn't quite all replace correctly. Once fixed (and it really was a bug on my part) the app was accepted.
Kendall Helmstetter Gelner
2010-08-28 05:00:59
+1
A:
They are definitely guidelines, but if you don't have confidence or a good amount of experience with UX, you should treat them as gospel. When developing mobile apps, I kind of feel that providing a good UX should be the highest priority. A lot of developers are pretty bad at UIs, and the HIG provides a very good set of guidelines to follow, at least at the start. You should owe it to yourself to give a HIG a thorough read.
David Liu
2010-08-29 01:47:43