O-MVLL 1.9.1 extends string encoding to Objective-C CFString literals

What happened on this date

On 2026-07-06 (10:19 UTC), the open-obfuscator project published O-MVLL 1.9.1 on GitHub. The release lists compatibility with Xcode 26.5 and NDK r29, and three changes: a fix for the 1.9.0 release with dependency updates; StringEncoding support for Objective-C strings (CFString); and ScopedTrace timing instrumentation. For context, the 1.9.0 notes from June 23 contained a single item, NDK 29 support. O-MVLL is an LLVM-based obfuscation plugin that transforms native iOS and Android code at compile time. Note that GitHub's Atom feed shows an updated time of July 8 for this release, while the release page shows July 6 as the publication time; this entry follows the release page.

What it means for protecting app logic

In Objective-C, literals such as @"..." end up in the binary as CFString constants rather than plain C strings. For iOS projects that still contain a lot of Objective-C, having string encoding cover these literals means less readable text when the binary is browsed statically. The boundary needs stating plainly: string encoding only affects static readability. At runtime the program must restore strings to use them, so dynamic observation can still see them, and it cannot protect API keys or other secrets, which belong on the server. A practical issue is version coupling: compiler plugins like this are tied to specific Xcode and NDK versions, so toolchain upgrades often wait on the plugin catching up, which is a maintenance cost in itself.

Checks to run on your own builds

First, confirm that the Xcode and NDK versions your team actually uses match the compatibility listed in the release notes, and validate on a branch if they do not. Second, run strings or otool on your own release build before and after enabling the feature, and compare readable text in sections such as __cstring and __cfstring, so you confirm the effect rather than assume it. Third, inventory any secrets that still appear in the client and move them server-side instead of relying on string encoding. Fourth, run full regression tests after obfuscation, paying attention to launch time and string-heavy code paths; check the project documentation before relying on ScopedTrace. Fifth, re-sign after transformation and verify install, launch and key flows on real devices.

Your checklist

• Match Xcode 26.5 / NDK r29 against your own toolchain
• Compare readable __cstring/__cfstring text in your build before and after
• Move client-side secrets server-side instead of relying on string encoding
• Re-sign and run on-device regression after obfuscation