Filed under: Bad Apple, App Store, SDK
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
![TUAW [Cafepress]](http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-cafepress-promo.png)
Reader Comments (Page 1 of 1)
Chris said 1:38PM on 11-26-2009
Nooo... is this whats holding up my Tweetie 2 update :(
Reply
Jeremy said 1:38PM on 11-26-2009
Every time you think the App Store is as bad as it can possibly be, Apple proves you wrong by making it worse.
Reply
kmcgrady90 said 1:55PM on 11-26-2009
This is most likely a rare case. The likely hood you name your methods the same as a private method is unlikely. Devs who are actually using private API's shouldn't be. If this person contacts Apple as TUAW suggest it should be sorted out quickly. Using private API's risks an apps stability and compatibility so although the system isn't perfect, it is good for the consumer.
(I'm a dev and I don't see any problem with Apple running this check)
Hunter said 3:01PM on 11-26-2009
@kmcgrady90: Seriously? If you are doing anything similar to the what some undocumented library is doing (like, i dunno... setting an order in a set or a thumbnail in list of pictures per the example) then you will run directly into this. Name collisions happen all... the... time. That's why most every big language has mechanisms for dealing with just this problem.
No one sees a problem with them running the check, but running it on plain text names is just plain silly and catapults development back into the days of global namespaces. Worse even, global namespaces with a whole slew of names _you_don't_see_.
Summary:
a) Dinging people for breaking a rule containing information that isn't public is rude and basically just wrong.
b) Global namespace collisions happen all the time because similar functionality will tend to be similarly named by developers of similar caliber.
c) Their plain text testing is lazy. They should do static code analysis, or if they are terrified of someone using dynamic shenanigans they should do runtime analysis. Given you only have to make the testing system once and they are using it on 100k applications, this is just lazy.
Carlos said 12:52PM on 11-27-2009
Maybe Apple could make available a developer tool (or web service) for developers to check for private APIs in his applications, before they send them for reviewing. I think it could (at least) speed up the approval process.
Carlos said 12:57PM on 11-27-2009
@Hunter I guess they are doing (simple?) static code analysis on ELF binaries. AFAIR, due to the way Objective-C works, it's hard to know what selectors ("method names") are used on what objects or classes. It's similar to how Smalltalk and Python works. So it ain't an easy thing to do, specially if you don't access to the source code being analyzed. I'd not call them lazy.
hmlong said 1:57PM on 11-26-2009
So any use in my code of a name that's used somewhere in Apple's API's will cause a rejection?
Even common things like getID() or process()?
That sucks. You'd at least think they'd check the library the symbol is bound to and figure out that it's [my process] and not [apple process].
Reply
cowfodder said 2:23PM on 11-26-2009
No, if your custom names happen to match one of the PRIVATE APIs your app might be rejected. The public ones are public, and available for everyone's use.
Jay said 2:59PM on 11-26-2009
What bothers me about this is that apple is not just checking class names, but method names. If it were just classes the best solution would be to prefex each with your company name, such as apple does with NSWhatEverThisDoes. But doing so with each and every method you create would be burdensome.
Flagging a method name such as -setOrder is going to cause a whole lot of false positives, -setThumbnail probably not as many but it's still something I can see being used quite a bit by developers.
I agree that the automated checks are a necessary evil but I think that apple should be using them as a flag to spend a little more time reviewing the app to be sure those API's are not being used. I do not believe that they should be using the information to simply reject the app.
Reply
Jason said 4:40PM on 11-26-2009
I guess I don't understand how the linking works in an Objective C app. Wouldn't they just look at the undefined symbols in the executeable+dynamic libraries that application delivers? If they're looking at all symbols in the application, that just seems to be a descent into madness.
Reply
Matt said 3:53PM on 11-26-2009
I think whats missing here is that if Apple is going to use an automated validation system, they should make a tool available to developers that will allow users to scan their code and pre-validate it. that way a dev can submit with relative assurance that the machine wont spit it back at them.
Reply
Charli said 5:02PM on 11-26-2009
now that is a valid thought and perhaps one that they are working on. it seems at the least they are telling folks where the conflict lies so a rename or whatever can be worked out. which is better than telling them they got an answer wrong but not which of the 500 questions it was.
Bertil Holmberg said 6:41PM on 11-26-2009
Very funny. The finished app does not contain any method or property names, only machine code that might be checked for calls to known API's.
Reply
Erica Sadun said 6:43PM on 11-26-2009
You might want to unzip an ipa file, go into the Payload folder, into the .app folder and run nm on the executable.
Jihoon Kim said 3:47AM on 11-27-2009
IMHO, private methods should always start with underscore( _ ) so that name collisions will never happen.
Reply
Ben Barnett said 6:41AM on 11-27-2009
Actually, Apple recommend you *don't* start your private methods with underscores to avoid colliding with theirs.
Jihoon Kim said 9:07AM on 11-27-2009
I am not talking about placing underscore in the names of my methods. I am noting the fact that it looks like Apple forgot to use underscores in the names of unpublished APIs. -setOrder and -setThumbnail should've really been -_setOrder and -_setThumbnail...
David Frantz said 1:26PM on 11-27-2009
This is one of those things where I actually think Apple wants to be legitimately helpful. Let's face it Touch OS will continue to improve and develop, which will eventually lead to private APIs being exposed in the future. So they are trying to give developers a leg up to help with future OS revision compatibility.
One does have to wonder why the automated software is offered to developers. It might be due to security with Apple not wanting to expose future OS directions. Or it could be the tool being in a really crude state right now. I don't know but would hope that future SDK revs offer up the tool.
As to developer whining yeah it could be a problem with existing apps but you can't really blame Apple here. The OS would evolve with or without the checks. Without the checker we would simply have more apps breaking as a surprise. Some may not like this but I do believe it is up to the developer to choose naming conventions that are durable and avoid namespace collisions. Generally any program of even modest complexity needs to have thought put into naming conventions, especially if third party libraries are used.
What seems to be objectionable here, at least to me, is the small minority of people raising objections to Apples efforts here. People need to get with the program here and realize that Apple is actually helping them out long term here. I know the current mind set is to bash Apple for any and all reasons but people are making themselves look stupid lately with respect to app store and the approval process.
This is not to say that Apple is perfect with respect to app store management just that I've seen a lot of complaints from developers over things they really have no basis to complain about. This is in reality one of them. Especially considering it is a long term positive for developers.
Dave
Reply
Neuro said 11:11PM on 11-27-2009
Dave, do you actually understand programming? It's not 1970s anymore, any modern language has at least 1 layer of name grouping, probably two (struct/class, namespace). The issue here is that the automated process ignores the classes and looks only on the method name itself. There is zero risk that me naming a method setOrder in my own class will break anything, now or in the future (hey, I probably wrote 100 methods with that particular name in my life). But the check process doesn't understand that, it sees "setOrder" and thinks "yeah, what if it's setOrder calling the secret api? Oh noes"...