I finally got “bit” by the current Apple mania for ferreting out private API calls in App Store iPhone Applications.
You’d think with all my video game experience that I’d be more prepared for this (props to Toy Story 2).
Anywho, these are the two lines of code that got my submission smacked out of the park:
[[UIApplication sharedApplication] terminate];
Doesn’t look like much, does it?
Still, verboten all the same.
In the case of the terminate function call, all I’m trying to do gracefully end the application in the event that network connectivity is not available. There is a simple workaround here, and that is to instead use the C Language exit(0) call. Easy-peazy, lemon-sqeazy.
The second “offending” call, [NSHost currentHost], is simply a call to get the iPhone’s current IP address. The workaround here is to do something else, like this.
In any event, both of these changes were minor.
Was I in the “wrong” for using them? In the view of Apple, absolutely. And in view of what I agreed to as an iPhone Developer publishing apps on the App Store, again, absolutely.
But, believe it or not, I don’t memorize every API call and know right off the top of my head whether it’s official or not. Shocking, I know.
And, since the app that was being submitted has been in the App Store for over a year (as have these forbidden calls), it wasn’t like I was trying to sneak in some neato feature available only to Apple by using private calls.
Long story longer, I can easily correct these transgressions – and have done so – in about 15 minutes time.
The bad news is that the app sat in the approval queue for ten (10) days just to be rejected. An app that has passed numerous times before. And now must be resubmitted and waited upon. Again.
Another seven-to-fourteen visit to the purgatory of App Store Approval.
If you think you’re gonna sneak some hidden feature in, reconsider.
Unless, of course, you have all the time in the world to resubmit offending apps.