WKWebView在github上源码地址：
https://github.com/WebKit/webkit/tree/master/Source/WebKit/UIProcess/API/Cocoa
TestProtocol.mm 中看到了 NSURLProtocol 熟悉的身影：
从 registerSchemeForCustomProtocol: 这个方法名来猜测，它的作用的应该是注册一个自定义的 scheme，这样对于 WebKit 进程的所有网络请求，都会先检查是否有匹配的 scheme，有的话再走主进程的 NSURLProtocol 这一套流程，猜测这么做可能是为了保证效率 (NSURLRequest 的 HTTPBody 属性在 WKWebView 中被忽略了应该也出于这个原因)，毕竟 IPC 代价挺高的。后续翻 WebKit::CustomProtocolManager 和 WebKit::WebProcessPool 等相关源码也印证了这个猜想。
关于私有 API现在 WKWebView 中的所有请求都可以被 NSURLProtocol 修改了：
按照 @sunnyxx 的总结，Apple 检查私有 API 的使用，大概会采取下面几种手段：
- 是否 link 了私有 framework 或者公开 framework 中的私有符号，这可以防止开发者把私有 header 都 dump 出来供程序直接调用。
- 同上，使用@selector(_private_sel)加上-performSelector:的方式直接调用私有 API。
- 扫描所有符号，查看是否有继承自私有类，重载私有方法，方法名是否有重合。
- 扫描所有string，看字符串常量段是否出现和私有 API 对应的。
而本文所介绍的方法，一共有两个地方使用了私有 API：
这两个地方都是通过反射的方式拿到了私有的 class/selector，对应上面的第四条。其中第二行那个还好说，因为 registerSchemeForCustomProtocol 这个名词看上去相当普通，如果把这种字符串也禁掉了的话会误伤一大票开发者，所以有风险的主要是 WKBrowsingContextController 这个字符串，要前缀有前缀，要 camel case 有 camel case，再跟私有 class 名撞车的话就跟可能被拒了。
那么怎样绕过这个字符串呢？查询 WKWebView.h 可以看到，有个方法 - browsingContextController 的方法名跟 WKBrowsingContextController 长得很像，通过 KVC 取出来（没错，KVC 不但可以取 property 取 ivar，还可以取无入参 selector 的返回值）发现它就是 WKBrowsingContextController 的一个实例，这样一来这个私有类就可以通过 KVC 的方式来得到了：
Class cls = [[[WKWebView new] valueForKey:@"browsingContextController"] class];
比起粗暴地 NSClassFromString，使用 valueForKey 的方法安全了许多。当然，如果还有什么要担心的话，这些字符串也可以不明着写出来，只要运行时算出来就行，比如用 base64 编码啊，图片资源里藏一段啊，甚至通过服务器下发……既然到了这个程度，苹果的静态扫描就很难再 hold 住了。