views:

211

answers:

4

So, we all know Apple forbids using private or undocumented APIs in iOS apps. I have no problem with this, as there are sound technical reasons for why this is a good idea. However, twice now I've had an app rejected for using private APIs, when this was not actually the case. It's not difficult -- the private APIs include symbols like connectionState, setThumbnail, setOrder and so on. Any calls you make to methods named as such will be flagged as a private API use, even if the method being called is something you have defined yourself. For a program doing something with connections, thumbnails or the order of things, the above mentioned method names aren't all that unlikely. Getting rejected for this and having to rename a method and resubmit delays everything by at least a week while you wait for a new review.

So is there a way, using nm, class dumps of the iOS frameworks, etc to find out for yourself if your method names conflicts with anything in there? If so, we could have a chance of correcting this before release and avoiding unnecessary rejection.

+3  A: 

Have you tried turning on Validate Build Product in the settings? It is supposed to perform all the initial checks done on your app during the review process

Liam
Yes. Not sure what exactly it "validates", but this isn't it.
calmh
+2  A: 

This is not exactly what you're looking for, but Xcode has two validate options that are probably worth trying.

The first is a build setting. It's not entirely clear what it checks -- the documentation doesn't say and even the WWDC talks didn't really elaborate -- but it is potentially useful. My guess is that it does not check for private APIs.

The second option is in the Organizer. In the "Archived Apps" view you can submit your app to Apple for validation. Again, they don't really nail down exactly what the checks are but I understand that this is more like the automated tests that they run before "manually" reviewing. My guess is that this does check for private API calls.

Stephen Darlington
Good ideas. The Organizer "Validate" seems to do the same checks that Application Loader does on submission -- that bundle ID:s are correct, file name valid, etc. No go on the private API:s though.
calmh
+1  A: 

Erica Sadun is currently working on something she calls APIKit which is a utility that scans your code and proactively warns you about private API usage. http://ericasadun.com/2009/12/apikit-goes-beta/#c2

The only problem is that I can't find anything to do with it anywhere. It's apparently in beta, but that was announced around 8 months ago.

I don't know of it's current status or whether or not it's actually available, but it's something you could look into. Maybe even try contacting her yourself? Erica hangs out in the #iphone-dev channel on IRC on freenode now and again, you might catch her there.

Jasarien
Thanks, I'll look into it.
calmh
I've been looking into it, and I think that her apikit script probably didn't work all the way, which is why it hasn't been released. Specifically, `nm`, `classdump` and friends don't see core data dynamic properties, which obviously Apples scanner does. Something which actually finds all used selectors is needed. `Strings` does the job, but filtering out all that **isn't** a selector is hard (impossible?). :/
calmh
+2  A: 

I'd suggest using App Scanner. It analyzes your .app file for private API method usage. The current version doesn't support private API instance variables but that might get worked into a future version.

It will catch methods that have been named the same as a private API method, even if it has it's own implementation. Also, it'll catch @selectors inside methods (just like the official iOS automated checker).

link --> http://www.chimpstudios.com/appscanner/

Andrew