An SDK provider protects code inside third-party host apps by hardening what it owns and leaving the host’s decisions to the host. Otukan obfuscates your SDK’s internals while its public interface stays as documented, checks that your SDK’s code has not been altered, watches for hooking, debugging and emulation around your SDK’s own calls, and sends findings to your backend with your SDK’s normal traffic. It does this for SDKs shipped to Android and iOS host apps. What your SDK cannot control is the host’s signing, its other libraries and whether the whole app shuts down; this page sets out that boundary.
Boundary
What your SDK owns and what the host owns
An SDK runs inside a process it did not build, signed by a company it does not control. Clear ownership keeps protection effective and keeps host developers willing to ship your update.
| Area | Your SDK | The host app |
|---|---|---|
| Internal code and strings | Obfuscated by Otukan | Cannot read them in clear form |
| Public interface | Kept stable and readable | Calls it as documented |
| Integrity of SDK code | Checked by the SDK itself | Not involved |
| App signing and store release | No control | Signs, submits and rolls out |
| Response for the whole app | Reports the finding | Decides whether the app reacts |
| Server-side decisions | Your backend decides on your service | Its backend decides on its own service |
Secrets deserve a word of their own. An API key embedded in an SDK can be read from any host app that includes it, however well the code around it is protected. Otukan protects code and strings that must ship; credentials that grant real access belong on your server, issued per host or per session.
Distribution
Packaging
Android SDKs usually ship as an Android Archive and iOS SDKs as an XCFramework, each published to the repository your customers already pull from. Otukan protects the SDK before you publish, inside your existing build and release pipeline, and your signing keys stay with you. Host developers add the protected SDK exactly as they added the unprotected one.
Host compatibility
Host apps apply their own build steps to your code. On Android, a host with minification enabled runs R8 across every library, including yours, so your SDK ships consumer keep rules that stop the host from renaming its public interface. Otukan’s protection respects those rules. On iOS, an XCFramework built with library evolution enabled ships a stable module interface that hosts can build against with the same or a newer Swift compiler, and Otukan’s protection keeps that module interface intact.
Otukan tests the protected SDK in sample host apps that reflect how your customers build: with and without host minification on Android, across the Xcode versions your customers use on iOS, and alongside other common SDK categories such as analytics and payments.
Versioning
Each protected SDK version is a separate release with its own private mapping. Host companies update on their own schedule, so several SDK versions run in production at once. Keeping a mapping per version, and recording which version a host runs, lets your support team translate crash frames from any of them. Protection changes ship like any other SDK change, in a new version with release notes host developers can read.
Runtime controls
What works without the host
Some controls live entirely inside your SDK. Obfuscation protects your logic whatever the host does. Self-integrity checks confirm your own code and resources before a sensitive operation. Runtime checks around your SDK’s calls look for hooking frameworks, debuggers and emulators. Findings travel to your backend with your SDK’s own requests, so your service can refuse a request from an altered environment without asking the host for anything.
What needs the host’s cooperation
Other behaviour affects the whole app and needs the host’s agreement. Ending the app, blocking a screen outside your SDK or changing the host’s sign-in flow are host decisions. Otukan’s approach is for your SDK to decline its own sensitive operation, report the finding, and expose it through your API so the host developer can choose a wider response. Checks on the app’s signing certificate also need care: on Android the host’s certificate, or the one Google applies with Play App Signing, is what devices receive, and on iOS the host’s team re-signs your embedded framework. Otukan’s engineers agree with you which of those facts your SDK should rely on.
Setup detail sits in the SDK security integration guides. For how Otukan fits a build, see mobile app security integration. For app-level protection, return to mobile app security. For a structured way to evaluate options, see the SDK protection solution guide.