This is admittedly a little technical. But the gist of it is that RogueSheep sort of got screwed by having their app rejected for this. Their app linked to a version of the Three20 framework that overrode, not called, a private API — i.e. it replaced a private method with its own method of the same name. And Postage, the app, wasn’t even actually calling it. Apple’s tool apparently can’t discern the difference, so developers need to be aware of this or risk automatic rejection.

RogueSheep’s Chris Parrish concludes:

Personally, I’d love to see Apple give us access to the analysis
tool to run against our own builds before submission. Or if
that’s not possible, perhaps a modification to the review
process so this automated analysis happens sooner in the process
so we don’t lose so much ground in the now 14-day wait for the
review process to complete.

Making the static analysis tool available to developers would indeed be helpful. But I suspect it wouldn’t work in terms of game theory. Honest developers could make good use of having access to the tool, to help ensure their projects are free of private API violations. But dishonest developers would use the tool to figure out ways to slip private API calls past the checker. Parrish’s second request, for Apple to run the tool against submissions far sooner in the review process, strikes me as a good and reasonable one.

Update: Here’s a note from an informed DF reader:

Overriding private methods in a category is far worse than calling them directly.

Everything in your process will get the overridden behavior of
the private method and assumptions about side effects go out
the window.