Question

I have asked a similar question here and got some answers, so first of all sorry for making you people bother once again.

But I have an argument this time. First I will show my piece of code

- (void) showTheAlert{
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Hey!" message:@"?" delegate:self cancelButtonTitle:nil otherButtonTitles:@"Yes",@"No",@"Don't know eaxactly.",nil];
    [alertView setTag:101];
    [alertView show];
}

- (void)willPresentAlertView:(UIAlertView *)alertView{
    if(alertView.tag == 101){
        [[[alertView subviews] objectAtIndex:2] setBackgroundColor:[UIColor colorWithRed:0.5 green:0.0f blue:0.0f alpha:0.5f]];
        [[[alertView subviews] objectAtIndex:3] setBackgroundColor:[UIColor colorWithRed:0.0 green:0.5f blue:0.0f alpha:0.5f]];
    }

}

And my final alert looks like

Now my confusion is that, [alertView subviews] is not documented as some people may say but alertview is a subclass of UIView, which has a property called subviews.

So I am using the documented property of a superclass which is definitely allowed.

So if this alertview may cause rejection of my app or not? ( I don’t think apple will have any base to say I am using the undocumented or a private api. The look and feel is also alike to alertview.)

Answer 1

To follow on Henrik’s reply, in the iPhone Human Interface Guidelines section “Designing an Alert”, they say the following:

Although you can choose the number of
buttons to place in an alert, a
two-button alert is often the most
useful, because it is easiest for
users to choose between two
alternatives. It is rarely a good idea
to display an alert with a single
button because such an alert cannot
give users any control over the
situation; instead, it can only
display information and provide a
dismiss button. An alert that contains
three or more buttons is significantly
more complex than a two-button alert,
and should be avoided if possible. In
fact, if you find that you need to
offer users more than two choices, you
should consider using an action sheet
instead (see “Using Action Sheets” and
“Designing an Action Sheet” for more
information on this type of view).

Because users sometimes respond to
alerts without reading them carefully,
be sure to provide an appropriate
default choice. To help guide
inattentive users towards this choice,
make the light-colored, right-hand
button the safe, default alternative.
For example, you might choose to make
this button the Cancel button, to help
users avoid inadvertently causing a
dangerous action, or you might make it
represent the most common response, if
the resulting action isn’t
destructive.

The following guidelines describe how
buttons are configured in an alert:

• In an alert with two buttons, the button on the left is always
  dark-colored and the button on the
  right is never dark-colored.

• In a two-button alert that proposes a potentially risky action, the button
  that cancels the action should be on
  the right and light-colored.

• In a two-button alert that proposes a benign action, the button that
  cancels the action should be on the
  left (and therefore dark-colored).

• In an alert with a single button, the button is light-colored.

You are clearly violating the guidelines in size, shape, number, and color of the buttons in your alert view (red has a very clear meaning as a destructive action, not a confirmation). Even if Apple doesn’t reject your application in review (which they tend to do for clear violations of the Human Interface Guidelines), this would be extremely confusing to your users.

Also, navigating the hidden view hierarchy for any Apple-supplied user interface element is a very bad practice. The view hierarchies are undocumented, and do change often. Many of the applications that started crashing when people upgraded to iPhone OS 3.0 did so because those applications did something funky with subviews of UI elements, and those elements changed in the new OS version. Apple even specifically called this out in the iPhone OS 3.0 migration documents (which I can’t find now).

Because of the problems this caused, they appear to have cracked down on this practice and have been rejecting applications because of it. Even if they don’t, it shows contempt for your users if you do this, because it means that you don’t care if your application breaks with future OS upgrade.