Otukan obfuscates what an analyst reads in a decrypted iOS binary without breaking how the app runs. It renames your own Swift and Objective-C classes, methods and properties, reduces what Swift type metadata reveals, encodes the string literals you choose and restructures the control flow of sensitive functions. It keeps the names iOS or your code resolves by string at run time: selectors built from strings, key paths, storyboard classes, Core Data entities and types exposed to Objective-C. Third-party XCFrameworks stay as shipped. The result is an app that behaves as before and is much slower and costlier to understand.
For the cross-platform view, see mobile code obfuscation.
Swift and Objective-C binary coverage
An iOS executable is a Mach-O binary. App Store encryption is removed when iOS loads it, and on a jailbroken device the decrypted binary can be written out and opened in a disassembler. What it shows depends on the language, and Otukan treats each part on its own terms.
| Material | Where it sits in the binary | What it reveals unprotected | What Otukan does |
|---|---|---|---|
| Objective-C classes and selectors | Objective-C runtime metadata | Class, method and property names | Renames them, keeping names resolved by string |
| Swift types | Swift reflection and type metadata | Type, field and conformance names | Reduces what they reveal, keeping names reflection needs |
| Swift function names | Symbol table | Mangled names that decode to readable signatures | Removed by stripping; renamed where they remain |
| String literals | C string and constant sections | Endpoints, error text, feature flags, lookup keys | Encodes chosen strings until used |
| Control flow | Code section | The order of checks in sensitive logic | Restructures the functions you choose |
Stripping symbols in the release build is worth doing and costs little, but it leaves most readable metadata in place. Otukan targets exactly what stripping cannot remove.
Mixed and cross-platform code
Many apps mix Swift and Objective-C, bridged through headers and @objc. A name crossing that bridge must match on both sides, and Otukan keeps the two sides consistent. Apps built with Flutter or React Native carry most of their logic in a Dart framework or a JavaScript or Hermes bundle, and Otukan protects that layer with techniques suited to each framework, not only the Swift shell.
Selectors, reflection and embedded frameworks
Most obfuscation breakage on iOS comes from names looked up at run time. Otukan’s keep rules are built around these cases, and your team can add names specific to your code.
Names Otukan keeps
- Selectors from strings. Code that builds a selector from a string, or checks whether an object responds to one.
- Key-value coding and observing. Key paths are strings that must match property names.
- Interface Builder. Storyboards and XIBs refer to custom classes, outlets and actions by name.
- Core Data. Model entities name their managed object classes.
- Archiving and Codable. NSCoding archives and Codable types without explicit coding keys store property names in the data.
- Swift reflection. Code that reads type or property names through Mirror or string descriptions.
Embedded frameworks and extensions
Otukan protects your own dynamic frameworks like the main executable, keeping the public interface other binaries call. Third-party XCFrameworks arrive built and signed by their vendor, and Otukan leaves them as shipped so their signatures stay valid. Each app extension is a separate executable, and you decide which ones to protect.
The runtime side is covered on iOS app shielding.
Symbolication, performance and build validation
Symbolication
Each archive produces dSYM files matched to the build by UUID, and crash reporting tools use them to turn addresses into function names. With renaming, those names are the obfuscated ones, so Otukan produces a private rename map with every protected build. Keep it alongside the dSYM files, and your crash reports read in your own names.
Performance
Renaming has little run-time cost. String encoding and control-flow obfuscation add work and size, so Otukan applies them to the functions and strings you choose. We compare launch time and app size with your team against the unprotected build on the oldest iPhone and iOS version you support.
Build validation
Otukan validates each protected build with your engineers:
- Archive and sign the protected build exactly as for release.
- Disassemble it and record which class names, Swift metadata and strings remain readable.
- Run storyboards, Core Data migrations, Codable round trips and every SDK integration.
- Install on physical devices, update from the previous release, sign in and run your sensitive flows.
- Symbolicate a test crash with the build’s dSYM files and rename map.
- Record iOS versions, device models, results and the reviewer.
For the platform view, return to iOS app security. If your iOS app is already on the App Store, you can request a free App Exposure Check of the public release.