Ask HN: Would Apple reject this app?
Here is a chat I had in #iphonedev on freenode. I am torn between making an app better for 90% of my users (as confirmed by actual user testing) and following Apple's Human Interface Guidelines to the letter.

What are the chances it will get rejected? See below.

<EGreg_> hey guys
<EGreg_> would apple reject my app for using a tab-bar instead of a toolbar
<EGreg_> http://grab.by/7NnH
<EGreg_> in my user testing, fully 90% of the users had no idea what the buttons did
* _rush_ has quit (Ping timeout: 245 seconds)
<EGreg_> so I am trying to delight my users but am afraid that Apple will reject the app for using a component in a "non standard way"
<KucukMubasir> EGreg_: have you read HIGs ?
<EGreg_> yes
<KucukMubasir> if you don't violate it, why should it be rejected
<EGreg_> it violates apple's HIG
<EGreg_> but in real world testing, the version I just linked to: http://grab.by/7NnH is understood right away byt he users, whereas the version that follows HIG draws blank stares from 90% of users, and of them 50% are unable to complete "select all" without assistance
<EGreg_> what to do?
<ilteris> drunkn718: actually if you look at the examples you there's a session object which takes care of the authorization. it's in the samples
<EGreg_> http://grab.by/7No1
<KucukMubasir> EGreg_: I have no idea; but if it violoates...
<KucukMubasir> toolbar buttons don't stay as selected unlike tabbar ones, right?
<EGreg_> in order to follow HIG I have to make my app LESS understandable by 90% of people
<EGreg_> as comfirmed empirically in user acceptance testing
<EGreg_> tabbar buttons don't have to stay selected
<Codhisattva> the problem isn't tabbar vs toolbar
<Codhisattva> the problem is select all doesn't belong down there at all
<EGreg_> where does it belong, then?
<EGreg_> if not right underneath the checkmarks
<KucukMubasir> EGreg_: why don't you put it to the top?
<EGreg_> and where would it appear, exactly?
<EGreg_> the top is already taken up by the search bar
<jer> EGreg_, add a segmented control to the toolbar, move one of the buttons (i.e., the right + button) into the segmented control
<Codhisattva> I doubt select all is even all that useful
<EGreg_> oh, so now we are talknig about taking out the select all option, all because of the inability of app developers to put captions on their icons
<Codhisattva> :)
<EGreg_> codhisattva: sure, why not let the user manually select 100 contacts :)
<EGreg_> If you are suggesting somehow completely rearranging the interface, taking out the Select All button, taking out the +, and so on, in order to satisfy some misguided insistence that icons MUST NOT have captions, I would ask, why not simply add captions to the icons?
<BleuLlama> if users are confused by your toolbar icons, you need better toolbar icons.
<jer> if your tabbar doesn't have captions on its icons, you have a UX problem
<Codhisattva> EGreg_: if by "confused" you mean "they had to try it to find out what it was" then sure. *Icons* are almost always like that.
<EGreg_> Once again, the factor that changes users perception *IS* adding captions underneath icons.
<EGreg_> Codhisattva: users should not have to try something in order to understand its function
<jer> EGreg_, you are going about this entirely the wrong way
<Codhisattva> EGreg_: and that is the crux of your problem
<jer> you're trying to patch your UI in a way that conforms with what your users want given this particular UI
<Codhisattva> EGreg_: that is *exactly* the wrong frame of mind for a UI developer
<EGreg_> Codhissatva: a UI developer must pay attention to ACTUAL user testing and ACTUAL user use. Not a crystal ball
<jer> EGreg_, right, and when something isn't working how you want and you won't get it through review, you try other UIs and resubmit to your team of users
<Codhisattva> the primary reason why icons have meaning to users is experimentation
<EGreg_> ACTUAL user testing reveals with a HUGE statistical significance margin, that the problem is lack of captions under icons.
<EGreg_> So tehrefore I ask, can I put captions under icons?
<jer> on the tabbar?
<jer> you have them already
<EGreg_> I am forced to use a tabbar because the toolbar does not support icons+captions
<EGreg_> All I am asking is
<EGreg_> Will apple reject the app for the sole reason that it uses a tabbar when it "should have" used a toolbar (and thus made 90% of users confused)
<EGreg_> That seems preposterousto me and I am just wondering whether apple would do it
<Codhisattva> EGreg_: let us know how that works out
<EGreg_> I'm asking YOU
<BleuLlama> regardless, users (and apple) have an expectation that a (Tab bar|other element) does one thing and your app ueses it dfferently, then it causes issues.
<BleuLlama> apple has defined certain elements to be used in certain ways. past that, it's your job to use visual cues as to what the user can do. If it's unclear, then you need different visual cues (icons, eg)
<EGreg_> I presume it is "Apple is King and we cannot use empirical reality to serve as a basis for our decisions. If empirical reality says that an interface change will hurt the experience for 90% of users, we must IGNORE it because Apple's HG is sacred."
* pLk has quit (Quit: pwned!)
<BleuLlama> EGreg_: pretty much
<jer> LOL
<jer> you're funny
<EGreg_> crap, that's what I thought :(
<BleuLlama> Apple defined it, we go along with it. If you have issues, submit a radar to apple, and they might change it
<EGreg_> radar?
<BleuLlama> the joys of closed platform development, and agreeing to their terms when joining.
<BleuLlama> radar. bug/issue report, feature requests, etc.
<EGreg_> I just don't understand this particular policy of not putting captions underneath icons
<EGreg_> no matter how clear an icon is, it is not clear to a first time user
<EGreg_> imagine if all your macos menus were icons :)
<EGreg_> and you had to just "try them out" to know what they did!!
<BleuLlama> i'd love it if they were.
<jer> i'd prefer if they were
<jer> xcode's menu takes up a ton of screen real estate
* EGreg_ now knows what is meant by apple minions
<EGreg_> lol
<jer> of course, tbh i still to this day prefer the NeXTSTEP app menus, vertical not horizontal
<EGreg_> sure, you should have the OPTION of removing the captions
<BleuLlama> apple has good designers, they'd come up with good icons that describe what they did well.
<BleuLlama> and if not, i'd read the info/readme/help and know
<EGreg_> bleullama: okay but I am trying to draw attention to the actual problem.
<EGreg_> No matter what icon is used for "select all", it is not clear unless it says "select all"
<EGreg_> This has been VERIFIED. By actual TESTS.
<EGreg_> We tried a circle with a checkmark, a square witha checkmark, a checkmark
<wiliz__> EGreg_: what does this screen do? sends email/sms to all selected contacts?
<EGreg_> argh this is just so frustrating. For apple to reject my app because it implements an interface change that helps most users (not in their imagination) go from WTF to OH COOL
<EGreg_> wiliz__ YEP easy to understand right? :)
* cying has quit (Quit: cying)
<EGreg_> even though there are only 2 fake contacts on it
<jer> EGreg_, so plead your case to apple, file a radar, and cross your fingers and toes
<EGreg_> what's "filing a radar"?
* esses (~esses@94.166.161.120) has joined #iphonedev
<wiliz__> EGreg_: why not first create the email and then select the contacts? that is how mail app works
<EGreg_> jer: let me also point out that there are dozens of more horrible non standard apps in the apple store. I doubt they would reject this actually
<BleuLlama> EGreg_: check out the photos app. it lets you select multiple items. Mail.app does multiple item selection as well.
<jer> EGreg_, if there were only dozens i'd be surprised
<EGreg_> wiliz__ because apple does not let any such functionality be developed by 3rd party apps
* Modius has quit (Ping timeout: 264 seconds)
<EGreg_> jer: so then what am I worried about
<EGreg_> 99% of this app is HIG compliant
<EGreg_> i'm just worried about the 1% :) most apps have like 20% lol
<EGreg_> http://www.lehigh.edu/~sol0/TabBarGradient.jpg
<BleuLlama> EGreg_: try this. move that tab bar to the top. and resubmit.
* flyman_ has quit (Quit: This computer has gone to sleep)
<BleuLlama> er. that "Tab bar"
<BleuLlama> since it's not really used as a tab bar
<BleuLlama> ;)
<BleuLlama> yes, screen placement is important.
<EGreg_> hmm interesting ide moving it to the top
<EGreg_> it goes against the actual use of the app though (select users, then do something)
<wiliz__> EGreg_: i don't know, as a list? i just got the impression that "send the selected items as an email/sms"
<BleuLlama> users expect controls for the current view to be at the top
<EGreg_> but I like it
<BleuLlama> and different view selectors at the bottom
<EGreg_> nice idea
<EGreg_> wbleu ios toolbars are always on the bottom
<EGreg_> eg in photo app
<jer> ios toolbars are not always on the bottom
<EGreg_> they aren't?
<jer> no
<EGreg_> show me an apple app where they are not
<jer> photos
<jer> there's two
<jer> bottom and top
<EGreg_> i see no toolbar at top
<EGreg_> where do you see it
<EGreg_> the top one is a navigation bar
<BleuLlama> music playback now playing has a tool bar thing that appears under the nav bar
<EGreg_> jer: the toolbars are always on the bottom in apple apps, agree?
<jer> EGreg_, do not agree
<EGreg_> You see! Your suggestion violates HIG:
<EGreg_> Appearance and Behavior
<EGreg_> On iPhone, a toolbar always appears at the bottom edge of a screen or view, but on iPad it can also appear at the top edge.
<BleuLlama> guess i'm on igonre now.
<EGreg_> See what I mean? Slavishly sticking to the HIG we are probably all violating it.
* BleuLlama is off to do something else.
<EGreg_> bluellama no I hear you :)
<jer> EGreg_, open up photos, pick a photo, any photo. tap on it once. you see all the 5 icons at the bottom, that's on a toolbar, and at the top you see another toolbar
<EGreg_> I am just a little frustrated because I am trying to keep close to the HIG and everyone's acting so high and mighty "NO, Don't put readable captions on icons!" and then it turns out EVERYONE is violating the HIG in some other way :)
<EGreg_> jer: Appearance and Behavior
<EGreg_> On iPhone, a toolbar always appears at the bottom edge of a screen or view, but on iPad it can also appear at the top edge.
<EGreg_> on the top is a NAVIGATION bar, not a toolbar
<esses> bye
<BleuLlama> i don't put toolbars at the top. just suggested it as a way to sneak your misused tab bar in as a toolbar
<jer> EGreg_, nonsense... i have one iphone app with only one toolbar, it lives at the top because i pop an ad up from the bottom and it looks better this way
<jer> it's on the store
<EGreg_> well then you have violated HIG blatantly and got in the store :)
<EGreg_> which is cool by me
<jer> so what?
<EGreg_> EXACTLY! So what!
<jer> the HIG does not prohibit placing a toolbar at the top
<jer> read it
<jer> =]
<BleuLlama> apple is MUCH more concerned about misuing a widget with expected behavior than placement of that widget.
<jer> BleuLlama, right
<nissefant> Example a scrollbar that is 70% a scrollbar
<EGreg_> I just quoted to you how it prohibits it:
<EGreg_> Appearance and Behavior
<EGreg_> On iPhone, a toolbar always appears at the bottom edge of a screen or view, but on iPad it can also appear at the top edge.
<EGreg_> three times
<jer> i'm not seeing "Apperance and Behaviour" here: http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/Introduction/Introduction.html
<jer> so link me to the subitem

Anyway we go round and round but no one really knows anything about Apple's process. My guess is, with all the other bad apps, I should be fine with a toolbar that has CAPTIONS under the icons, right?