I think while probably fair intentioned, the tool that is in use right now must not account for a variety of situations that are perfectly legitimate like yours. It seems like the tool is really just doing a very simple check of the binary for strings that are flagged as private. Perhaps its even as simple as running strings on the binary or something similar. Seems like it needs to be made smarter to be effective and fair.

Perhaps a better approach would be a special build of the OS that is used in the review process. In this special OS build private methods could log when they are called directly from client code. I haven’t really thought about the runtime and if that is really possible or not.

There is a bit of good news though. It seems that the policy has changed so that its not an immediate rejection, at least in some cases to be a warning to change by your next release.

See this article : http://www.macworld.com/article/145044/2009/12/private_apis.html

What we do have is an attribute named “thoroughfare” in a Core Data class. setThoroughfare is generated from @dynamic.

Does this imply that all attributes in all core data classes must have names that in no shape or form resembles an attribute found in any of the private API’s?

I think they normally would if it was really a private method. It turns out though, previousViewController is not actually a private method. The error here seems to be in the analysis of the binary incorrectly flagging that as a private.