O-MVLL 1.11.0: Xcode 27 support and two new obfuscation passes

What happened on 2026-09-29

At 12:11 UTC on 2026-09-29, the open-source LLVM obfuscator O-MVLL published 1.11.0 on GitHub. The release notes list Xcode 27.0 and NDK r29 as compatibility targets. Following the Xcode 27.0 release, support for Xcode 27.0 was added and the xcode-x86_64 target was removed. Two passes are new: BasicBlockSplit, which splits basic blocks in half, and ShuffleOps, which shuffles instructions within a basic block. Passes can now be selected through annotations. The release also includes miscellaneous bug fixes and improvements and an updated sample-omvll-config.py. The notes give no figures on the performance or size impact of the new passes.

What it means for protecting native iOS and Android code

O-MVLL evaluation already has its own guide, so this entry looks only at what changed. First, toolchain coupling shows up again. The plugin version must match the Xcode and NDK versions, so teams upgrading to Xcode 27 have to upgrade the obfuscator too. Removing the xcode-x86_64 target may affect teams that still use related build environments or artifacts, and the actual impact has to be checked against your own build configuration. Second, the two new passes change basic-block structure and instruction order within blocks. They mainly raise the cost of static reading and diffing. On their own they do not hide string constants or keys, and they do not replace keeping core rules on the server. Third, annotation-based pass selection lets developers apply heavier transformations only to key functions, which helps control size and performance overhead. It also means the team must clearly document which functions are protected, or they are easy to miss during later refactoring.

Checks to run on your own builds

First, confirm that the Xcode, NDK and O-MVLL versions in CI match the combination in the release notes, and check whether any build still depends on the removed xcode-x86_64 target. Second, trial BasicBlockSplit and ShuffleOps on a small set of key functions marked with annotations. Measure the change in package size, startup time and hot-path performance before deciding to widen the scope. Third, run the full test suite on obfuscated release builds and verify that crash symbolication still works. Fourth, keep a list of protected functions, and during code review check that new or renamed key functions still carry their annotations.

Your checklist

• Verify the Xcode, NDK and O-MVLL version combination in CI
• Trial new passes on a few annotated functions and measure size and performance
• Keep a protected-function list and check annotations in code review