App hardening
Crab Directed Hardening (小蟹定向加固) can also target the App main binary at IR. It sits in the same family as OLLVM: passes run on LLVM IR, not on a renamed Xcode source tree and not on a packed IPA. Control-flow flattening, bogus control flow, and instruction substitution happen while the App still has IR, so the shipped Mach-O is harder to reverse. If you only need to protect a shipped SDK, use Framework hardening.
When this path is the right one
You are protecting the App target you will archive and submit — native, or a Unity / Flutter / Cocos Xcode export — not a standalone Framework you give to other apps. You can still compile the App through Clang/LLVM. You want IR-level control-flow protection, not only language-level renaming.
How it differs from the other entries
Xcode-project obfuscation (Unity, Flutter, Cocos, native) changes symbols, resources, and call-stack shape. Uni-app IPA hardening works on an already packed IPA. Framework hardening targets the SDK at IR. App hardening targets the App binary at IR, in the same OLLVM style. Mixing the entries is the usual mistake: dropping a prebuilt Mach-O with no IR into Directed Hardening, or applying for Framework hardening when you mean the whole App.
What you still cannot skip
IR hardening raises reverse-engineering cost. It does not invent a new App Review fingerprint by itself, and it does not hide features from review. If two apps look related, you still need the compile-level confuse path and honest listing metadata; see 4.3 and obfuscation vs hardening. An App that has already been stripped to a Mach-O with no IR left is out of scope here, same as the confuse FAQ.
Request a trial with the App’s Bundle Id and write 「App hardening」. Detail on the IR passes: Framework IR hardening and OLLVM — the passes are the same, the target is the App.
Request a trial, then archive and submit
Download App Center, choose the General or Uni-app edition, then apply for a license on the registration-code page. The docs cover the operator steps.