A mobile security team should evaluate SDK protection in three passes: list every code and asset layer in the release, from native libraries to the third-party SDKs you embed; confirm that protection fits your compilers, frameworks, extensions and update routes; then validate the protected build for crash symbols, start-up and dependency behaviour. This guide serves two readers: app teams whose release contains many SDKs, and SDK providers whose code runs inside other companies’ apps. It covers Android and iOS builds, including Flutter and React Native. Server-side code and the host app’s own choices sit outside an SDK provider’s reach.
For the product view, see mobile SDK protection. Framework support is covered on supported environments.
Component scope: the layers in your release
Four layers to inventory
| Layer | Android examples | iOS examples | Typical protection question |
|---|---|---|---|
| Native code | C and C++ shared libraries | Swift and Objective-C frameworks, C and C++ | Symbol stripping, control-flow obfuscation, anti-debugging |
| Managed and framework code | Kotlin and Java bytecode, Flutter ahead-of-time compiled Dart, React Native Hermes bytecode | Flutter ahead-of-time compiled Dart, React Native Hermes bytecode | Renaming, string protection, integrity |
| Embedded SDKs | Third-party libraries in your dependency graph | Third-party frameworks and packages | Exclude, protect or leave as shipped |
| Packaged assets | Resources, bundled files, model files | Bundled resources, model files | Encryption and integrity |
- Fill in this table for your own release, per platform.
- Which layers hold the logic, keys or models an attacker would target first?
- Which embedded SDKs rely on class names, reflection or their own integrity checks?
If you ship an SDK
- Which parts of your SDK must stay readable to host apps, such as the public interface?
- Which runtime checks can your SDK run on its own, and which need the host app to cooperate?
- How will you tell host app developers what changed in a protected release, and how do they report a conflict with their own build settings?
How Otukan answers. Otukan protects native code, managed code and packaged assets on Android and iOS, with protection chosen per layer. It protects Flutter compiled Dart code and React Native Hermes bytecode as well as the native shell. For SDK providers, Otukan obfuscates your SDK’s internal classes, strings and logic while your documented public interface stays readable. Runtime checks look for hooking, debugging and emulation around your SDK’s own calls without inspecting the rest of the host app.
Release fit: compilers, runtimes, extensions and updates
- Which compiler and build tool versions does each option state it supports, and how does it handle their updates?
- On Android, does protection work with your R8 or ProGuard configuration and with dynamic feature modules?
- On iOS, does it cover app extensions such as widgets, share extensions and notification services?
- If you ship an SDK, does protection survive the host app’s own shrinking and optimisation?
- How are over-the-air content or script updates treated, and does protection still apply afterwards?
How Otukan answers. Otukan is added to your existing build and release pipeline, including CI/CD, as a repeatable step. It lets you exclude third-party SDKs and specific classes or symbols from obfuscation where a dependency relies on names. A protected SDK ships keep rules so it stays compatible with the host app’s own shrinking and obfuscation on Android. Signing keys remain with your organisation throughout.
Validation: behaviour, symbols, start-up and dependencies
Test the protected build as you would test any release candidate, then add these checks.
App behaviour
- Run your full automated test suite against the protected build on both platforms.
- Exercise every path that loads code dynamically or uses reflection.
Symbols and crash reporting
- Trigger a test crash and confirm the stack trace symbolicates: mapping files on Android, dSYM files on iOS.
- Confirm the files your crash reporting needs are archived with each release.
Start-up and size
- Measure cold start, package size and your heaviest screen on devices you choose, before and after protection.
Third-party dependencies
- Confirm analytics, payments, advertising and login SDKs initialise and report normally.
- Confirm SDKs with their own tamper checks do not flag the protected build.
How Otukan answers. Crash reporting keeps working: R8 or ProGuard mapping files on Android and dSYM symbolication on iOS stay part of your release, and every protected SDK release comes with a private mapping file for crash-frame translation. Otukan encrypts sensitive packaged assets, checks the integrity of code, resources and signing certificate, and reacts to repackaged copies. We expect you to measure start-up and size on your own devices.
Testing practice is covered on testing protected apps.