Hey Erica,

I take Apple's Interface Guidelines to be just that-- guidelines on what should be used unless there are valid reasons to do otherwise.

I do believe that there are times when it makes sense to deviate from the "Guidelines" if it improves the user experience.

Example 1: A table view drill-down-- where the user drills-down several levels (say 3 or 4) and then drills up a level (or 2); then down, again. As you move up levels, it makes it easy on the user if the cell that was drilled-down from is highlighted (and remains so) upon drill-up. This especially true if the breadcrumb navigation buttons confuse because of too many levels (abbreviation) and/or many of the cell items have similar titles. (Think a parts catalog or RAM chips, or whatever).

Example 2: A table view level where you don't want to go elsewhere-- just perform some action on the cell in question-- check/uncheck, timestamp, tally, etc. In this case, the cell need not remain highlighted (unless it helps the user), but the table view should not be replaced with another view (?) so the user can validate the action.

After all, it is about the user!

Dick

I don't think Apple object to multiple selections in a list - they do it themselves when deleting or moving mail.

Without seeing the code in question, I suspect they just don't like keeping the hilight on, you _can_ put a checkmark on the row as the reply says.

What Apple are objecting to is confusing interaction acknowledged UI (hilight) and selection UI (checkmark) not the multiple selection paradigm.

Hello, I am in fact the one who got the application rejected.
Roger has it correctly. What apple objects to is keeping the highlight and the selection. The guidelines and table view programming guide are quite clear about what they would like to see. There is even example code in the guide.

Moreover adding the few lines of code needed to keep the visual state using checkmarks instead of highlights is simple.

What I initially objected is what Dick Applebaum is talking about. I was thinking the guidelines were just guidelines and not absolute. I have lost time (probably a week but I don't know as the approval or rejection of the new app version hasn't been decided) due to the lack of precise information about what can be cause for rejection. Not following apple's UI guideline was not supposed to be one.

I think that the table case is just an example the interesting discussion is more about should in general the guidelines be considered guidelines or rules to follow absolutely?

Even as an "absolute", the HIG is open to intepretation. I had an app rejected for using the standard "Refresh" button to refresh the contents of my view. The problem? Well the refresh it my case would sometimes change the contents of the view and apple said "this would confuse" users (wonder how Safari users don't get confused"). So what can you do...

Another reveiwer on another day may have passed the app. The inconsistencies in the review process are the real problem (and story here).

Michael.

@Benoit - I had the same experience (that is, app rejected with virtually identical wording). In my case, I thought I was doing the user a favor so they could see what they'd selected when they navigated back.

I tweaked the code so the row didn't remain highlighted. I decided the checkmark didn't communicate what I was after.

It took just over four days for my app to be approved after I resubmitted it.

FWIW, from all I've read, whether they're guidelines or rules depends on who's interpreting/applying them and how much attention they're paying at the time.

I have gotten updates rejection for 4 different applications for this reason. But, these same apps have been around for a few months now, I'm just why they decide to enforce this suddenly, which have lead me to getting 4 rejections at the same time.

Persistent selection actually makes sense if users are given a list and they have to tap on these list to navigate to a detail page, but have to come back to the same page to go through each row one by one. Showing the selection gives a hint of the last browsed item. To serve the same purpose, I opted to deselect the row when the view is popped back, so users can momentarily see the last selected item.

Think about it. When they launched the iPhone, they accepted anything that wouldn't crash the iPhone in the first 5 seconds of use. Now they have more time, they go back and check things more thoroughly. Maddening but understandable.

There is no objection to persistent selection: that's what the checkmarks do. The objection is to persistent highlighting.

By the way, if you don't like the way they are judging your application, do reply to them. At a second glance they do sometimes approve something they rejected the first time... at least, if it was an app that they had already accepted in the past.

I just got an application rejected too. Ugh, how annoying that Apple imposes their UI design taste on people. Its too subjective, and good luck if the reviewer is just a droid that memorized the HIG.

In my case, I wrote an app that mirrors the design of voicemail EXACTLY. It highlights rows, displays play/stop on the left-hand side of the table cell, and navigates to a detail screen when the right-hand-side detail arrow is clicked. The row remains highlighted as the sound is playing, and even after the user presses stop (again, EXACTLY like voicemail). They rejected it.

Does that mean voicemail is breaking Apple's own guidelines?? I'm totally frustrated. Wouldn't it be better for them to just add "HIG Compliance" as a 1-5 rating, and display it for users to see in the app store, rather than holding back applications on these technicalities? This way those users who are so insanely particular about highlighting rules can only choose to buy "LEVEL 5 HIG COMPLIANT" apps.

And developers can resolve these trivial issues without waiting for Apple's review turnaround time.