已经在用小蟹工程混淆的团队，有时还要把对外提供的 Framework 单独保护起来。这件事对应的是小蟹定向加固：对准 Framework 的 IR 级方案，路线和 OLLVM 同类。它不是开源 OLLVM 仓库的一份 fork，也不是语言混淆或 IPA 加固上的同一个按钮。总览见 Framework 加固。同一套 pass 对准 App 主程序时，走 App 加固。
为什么是 IR，为什么拿 OLLVM 类比
OLLVM（Obfuscator-LLVM）出名的是在代码生成前改 LLVM IR：控制流平坦化、虚假控制流、指令替换。定向加固做在同一层。Framework 还有 IR 时，编译器可以改基本块和指令，不必长期维护一套被改乱的源码。目标文件一旦吐出来，这些 pass 就用不上了。所以已经剥光、没有 IR 的 Dynamic Mach-O 不能走这条入口——和 FAQ 里工程混淆不支持 Dynamic Mach-O 是同一类限制。
「定向」指什么
pass 对准的是 Framework / SDK 这个 Target，不是整个宿主 App。宿主界面、插件、商店资源如果还要做指纹隔离，仍走各自的工程混淆或 IPA 路径。SDK 二进制拿到的是 IR 级控制流保护。申请试用时不写明，就容易拿到错误的安装包。
它替代不了什么
IR 加固是逆向成本这一层。编译级混淆是指纹这一层（名字、资源、调用栈）。IPA 加固给的是没有可维护 Xcode 树的包，例如 Uni-app。审核仍要求 listing 和二进制一致，见 2.3.1。两个宿主看起来像一家时，先看 4.3 和工程混淆，不要只靠 Framework 的 IR。
申请时写 Framework 的 Bundle Id，或宿主 Bundle Id 加 SDK 名，并注明「Framework 加固」。操作细节仍在 文档站。