Advertisement

Dear Aunt TUAW: My "private" APIs... aren't

Sometimes Auntie TUAW gets emails from anxious iPhone developers. In this case, the correspondent is running into issues with Apple's new automated checks for private API use in iPhone apps.

Dear Auntie TUAW,

I got an email from Apple's App Review team saying the code in my iPhone app uses private APIs. They pointed to -setOrder, which is a method I created in code, and -setThumbnail, which was created automatically from a Core Data property.

But those are all from my own code, and thumbnail is actually a property for my CoreData class. Any idea why? I don't even have a setter for thumbnail, it is just a dynamic property for the CoreData class.

I don't want to rename my properties because I'm not sure that CoreData will automigrate my renamed items and my users are going to start crying if everything breaks.

Love & snuggles,

Lauren

Read on for Auntie's reply.



My darling Lauren,

Apple's new automated private API detection is, itself, automatically generated. setThumbnail: is a private API used by the Media Player framework and setOrder: by the private DataAccess framework. Even though your methods are perfectly legitimate, and are not in fact calling the unpublished APIs, they are getting flagged because of the name confusion.

The easiest solution is to rename your properties and resubmit, but that seems a hazard given this is an already deployed application with existing data stores for your users. (Core Data can migrate existing stores but I'm not sure of the details on how that might work for you or the overhead that would be involved.)

Definitely make App Review aware of the problem. Reply to them and let them know that you are not, in fact, using those unpublished and private calls. Submit a bug report to radar.apple.com and consider adding your problem to the OpenRadar project, so other devs can help reinforce your radar. (Yes, it is a popularity contest. The more duplicates each bug receives, the more likely Apple will fix that problem.)

As a rule, if you think your (legit) code will encounter problems during Apple review, make sure to note how your code works in the Demo Account box when you submit. That text box provides the best free-form text way to communicate with reviewers. Although it's a big burden, you may also want to cross check your custom method names against a class dump of the Cocoa Touch header files to find what items might get flagged before you submit.

Don't forget to get plenty of rest during this flu and cold season.

Love,

Auntie T.

Thanks to Emmanuele Vulcano