Apple App Store提交的内容，除了Apple对非公共API的使用进行自动测试外，还有其他人吗？

Question

Apple clearly has this automated in some way, I would like to have access to a version of the system they're using.

Barring that, I'm interested in knowing if anyone out there has implemented a this on their own. I sometimes work in a team where the lesser experienced developers may unknowingly use a non-public API or I may be asked to use a third-party library that unbeknownst to me is using an API that is non-public.

I know that the app executable can be scanned for the method names. I'd like to run those against a database of either the known non-public methods or against the public ones. In Objective-C/SQL part of the process might be like:

for (NSString *selector in methodsArray) {
   NSArray *array = [DataSource arrayWithQueryString:[NSString stringWithFormat:(SELECT `selectors` FROM `publicAPI` WHERE `selector` = '%@'),selector]]; 
   BOOL public = ([array count] > 0);
   if (!public) 
      return NO;
}

My guess is most of the work would be in how to isolate the method names and store them in the database in a way that checking against them would be most efficient.

I could create a version of this myself but if there's someone who's already done it, I'm interested in knowing about it, and I don't care what language it's achieved in.

Answer 1

就是这个了，App Scanner http://www.chimpstudios.com/appscanner/

Answer 2

If you're calling an API that isn't in one of Apple's public headers, you'll get compiler warnings like "selector not recognized". It should be quite rare that you would accidentally use private APIs.

Now, it's possible to suppress the compiler warnings if you take specific steps to do so— creating your own interface to an object containing declarations of the private API methods, for example. If you've got a rogue developer on your team, or you're inheriting code, something like that might catch you by surprise.

You also have to be careful if you're using a testing framework like the GTM iPhone test kit, which uses private API calls. If it accidentally gets compiled into your submitted binary, you'll get dinged. Xcode 4 helps mitigate this risk because testing in the new IDE is a whole separate action, not just a separate target.