Will Apple reject apps for using undocumented features?

Member
Posts: 38
Joined: 2008.09
Post: #1
I am close to submitting my app but I want to know if there is a chance for using a undocumented feature in the API?

For example,
Code:
        UIAlertView* alert = [[UIAlertView alloc]
                              initWithTitle: @"My title"
                              message: @"some message to you"
                              delegate: self
                              cancelButtonTitle: @"Cancel"
                              otherButtonTitles: @"OK", nil];
        [alert addTextFieldWithValue:@"" label:@"Enter new text"];
        [alert addTextFieldWithValue:@"" label:@"Enter new value"];
        
        UITextField *tf = [alert textFieldAtIndex:0];
        tf.clearButtonMode = UITextFieldViewModeWhileEditing;
        tf.keyboardType = UIKeyboardTypeAlphabet;
        tf.keyboardAppearance = UIKeyboardAppearanceAlert;
        
        tf = [alert textFieldAtIndex:1];
        tf.clearButtonMode = UITextFieldViewModeWhileEditing;
        tf.keyboardType = UIKeyboardTypeNumberPad;
        tf.keyboardAppearance = UIKeyboardAppearanceAlert;
        [alert show];

The addTextFieldWithValue is an undocumented feature of the UIAlertView class.

Has anybody used this and submitted an app? If so, was it accepted?

Thanks
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #2
Toontingy Wrote:I am close to submitting my app but I want to know if there is a chance for using a undocumented feature in the API?

For example,
Code:
        UIAlertView* alert = [[UIAlertView alloc]
                              initWithTitle: @"My title"
                              message: @"some message to you"
                              delegate: self
                              cancelButtonTitle: @"Cancel"
                              otherButtonTitles: @"OK", nil];
        [alert addTextFieldWithValue:@"" label:@"Enter new text"];
        [alert addTextFieldWithValue:@"" label:@"Enter new value"];
        
        UITextField *tf = [alert textFieldAtIndex:0];
        tf.clearButtonMode = UITextFieldViewModeWhileEditing;
        tf.keyboardType = UIKeyboardTypeAlphabet;
        tf.keyboardAppearance = UIKeyboardAppearanceAlert;
        
        tf = [alert textFieldAtIndex:1];
        tf.clearButtonMode = UITextFieldViewModeWhileEditing;
        tf.keyboardType = UIKeyboardTypeNumberPad;
        tf.keyboardAppearance = UIKeyboardAppearanceAlert;
        [alert show];

The addTextFieldWithValue is an undocumented feature of the UIAlertView class.

Has anybody used this and submitted an app? If so, was it accepted?

Thanks

If they find it, the'll reject it.

If they don't find it, but somehow become aware of it later, they'll pull your app from the store.

If they don't find it, and the private interface changes, your application will fail, causing your users grief.

No good comes of this.
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #3
You can add text fields without using that. Just subclass UIAlertView.
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #4
You don't even need to subclass UIAlertView: it is a subclass of UIView, therefore you can add subviews to it. (And to expand the size of the alert view, you can just put a bunch of \n's into the message of the alert view. Unfortunately, setting the frame by hand has some interesting effects...)
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #5
longjumper Wrote:You don't even need to subclass UIAlertView: it is a subclass of UIView, therefore you can add subviews to it. (And to expand the size of the alert view, you can just put a bunch of \n's into the message of the alert view. Unfortunately, setting the frame by hand has some interesting effects...)

Mucking around with system-created view hierarchies directly is just as fragile as using private interfaces to do the same mucking around.

I would suggest either redesigning your UI to not require this, or to roll your own alert view. They are both more work, but also 100% in the clear.
Quote this message in a reply
Member
Posts: 38
Joined: 2008.09
Post: #6
Thanks. I figured that it might be a risky thing to do. I'll just create my own view to handle the input that I need from the user.
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #7
Frogblast Wrote:Mucking around with system-created view hierarchies directly is just as fragile as using private interfaces to do the same mucking around.

I would suggest either redesigning your UI to not require this, or to roll your own alert view. They are both more work, but also 100% in the clear.

Uh... the concept of having a private interface on the basis of "documentation agreement" doesn't strike me as a terribly good idea to begin with.... but I guess it is water under the bridge :-)
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #8
warmi Wrote:Uh... the concept of having a private interface on the basis of "documentation agreement" doesn't strike me as a terribly good idea to begin with.... but I guess it is water under the bridge :-)

-[UIAlertView addTextFieldWithValue:label:] isn't in any public UIKit header, which makes it a private API. If it were in UIAlert.h but had no usage information, that would be different, but not being in the header puts it squarely in the realm of private APIs.
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #9
Oh, and also file a bug report to request a supported way to create this design using UIAlertView.
Quote this message in a reply
Moderator
Posts: 449
Joined: 2003.08
Post: #10
Apple also has some method of detecting calls, so I'd advise against it.
Alex
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  CNET News reporter writing about future iPhone game features Cnetdan 0 1,574 Oct 8, 2009 09:04 AM
Last Post: Cnetdan