Code Obfuscation
Code obfuscation hardens protected mobile apps against static analysis, reverse engineering, repackaging, and targeted tampering. AppTego applies obfuscation during protected build creation, so teams can increase binary resistance without redesigning application source code.
Obfuscation is one layer in an app shielding program. Pair it with runtime detection, app integrity, certificate pinning, secure coding practices, and release monitoring.
Use obfuscation profiles deliberately. More aggressive hardening can improve resistance, but every change should be validated against startup, performance, crash reporting, reflection, native bridges, and third-party SDK behavior.
Protection Profiles
| Profile | Recommended controls | Best for |
|---|
| Baseline Android hardening | Strip Debug Info, Rename Private Members, and Rename Classes | Most Team or Enterprise Android apps that need stronger resistance without heavy overhead. |
| Advanced Android hardening | Baseline plus Control Flow Obfuscation, Call Indirection, Instruction Substitution, Arithmetic Encoding, Dead Code Injection, and Anti-Disassembly | Apps with valuable business logic, fraud controls, payments, licensing, or proprietary workflows. |
| Enterprise Android shielding | Advanced hardening plus Encrypt Strings and Encrypt All Code | High-value Android apps where static analysis resistance is a release requirement. |
| iOS symbol and metadata hygiene | Strip Debug Symbols, Strip Bitcode, Reduce Objective-C Metadata, and Reduce Swift Reflection Metadata | iOS apps that need reduced metadata exposure in release artifacts. |
| Enterprise iOS string and selector hardening | Encrypt Strings, Encrypt Unicode Strings, and Objective-C Selector Indirection | High-value iOS apps where readable strings and selectors expose sensitive workflows. |
Android Obfuscation Controls
iOS Obfuscation Controls
Enabling Obfuscation
- Open the AppTego Portal.
- Select the intended configuration version.
- Open Code Obfuscation.
- Enable the desired controls.
- Save the configuration.
- Build a new protected app.
- Run functional, performance, startup, crash reporting, and release-signing validation before promotion.
Rollout Guidance
| Stage | Recommended approach |
|---|
| Development | Enable one or two controls at a time and confirm the app starts, logs in, and completes core flows. |
| Staging | Test the full intended obfuscation profile on physical devices, representative accounts, and production-like network conditions. |
| Production | Use the validated profile and monitor crash, performance, startup, and security telemetry after release. |
| Incident response | Keep a known-good hardening profile documented so protected builds can be reproduced quickly. |
Compatibility Notes
- Obfuscation can increase protected build time and artifact size.
- Advanced controls can affect reflection, dynamic lookup, dependency injection, native bridges, generated code, or third-party SDK behavior.
- Apps built with React Native, Flutter, Unity, Cordova, MAUI, Xamarin, and similar frameworks should test critical native bridge paths after obfuscation changes.
- If a control changes binary structure, the app must be rebuilt and redistributed for the change to take effect.
Validation Checklist
| Area | What to test |
|---|
| Startup | Cold launch, warm launch, login, and first-run flows. |
| Critical features | Payments, document capture, networking, offline mode, deep links, push notifications, and native bridges. |
| Observability | Crash reporting, logging, analytics, and support diagnostics. |
| Performance | App size, startup time, memory, and core workflow latency. |
| Release signing | Protected output installs through the intended distribution path. |