You can easily detect most trivial methods of performing direct message sends to private framework objects via static analysis - both the name of the class and

You can easily detect most trivial methods of performing direct message sends to private framework objects via static analysis - both the name of the class and the message are used as string data. You can even find a naive message send using strings and grep, regardless of the use or non-use of a header! The use of the header is irrelevant - using [NSClassFromString(@"WebView") _enableRemoteInspector]; is going to show up the same way in a static analysis tool regardless of whether I made a WebView.h header defining +(void) enableRemoteInspector; or not - it compiles to the exact same thing! You have to be at least one level more clever to defeat Apple's static analysis tool - it looks at the values of the objc_msgSend's message only. Hence, using methodForSelector defeats it - the static analyzer sees a "methodForSelector" message (which isn't blacklisted), ignores the parameters, and then sees a straight function call (also not blacklisted).