Sure, but to access a private class, I'd typically need to message the class to obtain an instance. I could obsfucate my access of the class, but equally I could obsfucate obtaining the selector.

The fact that selectors aren't tied to classes is exactly the reason this is so insane, as the example above (and the OP's) show!

> Sure, but to access a private class, I'd typically need to message the class to obtain an instance

Apple is also (and probably most) worried about you messing with objects borrowed from/exposed by Cocoa, so looking for calls to [Class alloc] is not enough.

> I could obsfucate my access of the class, but equally I could obsfucate obtaining the selector.

The problem is that after compilation every call is obfuscated. Compilation throws away types, so all you're left with is tons of identical function calls with generic pointers pointing to `isa` structures that aren't definitive at compile time. I imagine this is really hard to statically analyze, especially that you can easily "launder" origin of objects by passing them through containers like NSArray, notifications, etc.

Well, the objects they really don't want you using (that grant access to resources with no public API) are often exposed as shared instances via class methods. This is actually the case with PhotoLibraryServices, the framework with these private methods[1].

In general, I agree with what you're saying. My point here is really just this approach to detecting private API usage is obviously going to throw up loads of false positives. I get that they'd rather have false positives than false negatives, but it doesn't make it any less annoying.

[1] https://github.com/JaviSoto/iOS7-Runtime-Headers/blob/master...