CONFIRMED: UIAlert workaround (without Private APIs)

A quick note: my re-submission of Summation just got accepted.

(I got rejected for using Private API’s to modify UIAlert – a common workaround for bug(s) in the UIAlert dialog).

Good news: the *non-Private API* version (source code on the linked page above) … works. And more importantly: it got through submission.

Bad news: it’s ugly, and looks a bit strange (this is why developers were using the Private API version instead (i.e. the version Apple wrote and uses in their code)).

For those who asked “why?”

Here’s the (allowed) workaround:

Picture 1

And here, for contrast, is the Private API version. It’s much better, it’s safer, and it uses a method specifically designed to work this way. And – back when Apple was “only” using human reviewers – no-one objected.

According to Apple’s rules on private APIs, it was “wrong”. But it was so clearly *right* that – in my experience – you never got rejected for it:

Picture 2

So … is there something I’m missing here? Is there a specific problem with UIAlert – maybe a security issue, like rejecting Private access to the Camera API over privacy issues?

(I can imagine that Apple is afraid of apps *pretending* to popup the iTunes alert dialog, and supplying a fake “type your iTunes password” box – then uploading the iTunes password to a private server.

However, please note: I can do this *right now*, and *guarantee* to get it past Apple submission. This is *unlike* the Camera API, where I can’t see a way of sneaking the “illegal” stuff past Apple. So … I’m hard-pressed to believe that Apple objects to UIAlert on the grounds of security. If that *is* the reason, then … someone at Apple has got it wrong. They are getting no protection from the root problem!)

Post to Twitter

This entry was posted on Friday, December 4th, 2009 at 5:22 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply