App shielding and RASP overlap but are not the same thing. App shielding is the wider term: protection added to the app before release, such as obfuscation and integrity checks, usually together with checks that run inside the app. RASP (runtime application self-protection) names the runtime part: checks inside the running app that detect debugging, hooking, modified operating systems or emulators and apply a chosen response. Serious mobile protection needs both, scoped per platform. Otukan delivers them as two layers of one product for Android and iOS.
Definitions
App shielding (static layer)
- Added to the app before release
- Obfuscation of names, strings and control flow
- Resource and asset protection
- Integrity checks inserted into the build
- Makes the shipped app harder to read and change
Mobile RASP (runtime layer)
- Acts while the app runs on the user's device
- Detects debuggers and hooking frameworks
- Detects root, jailbreak and emulators
- Checks code and signature integrity live
- Produces signals and applies a response
App shielding
App shielding makes a mobile app harder to analyse, modify and misuse. The static part works on the app as shipped: code obfuscation renames and restructures code, and string and resource encryption hides sensitive values. Integrity checks sit on the boundary: they are added before release but run on the device, where they notice that the app has been changed or re-signed. Most shielding also embeds runtime checks, which is where the overlap with RASP begins.
Mobile RASP
Mobile RASP puts checks inside the app that watch its own execution. They look for a debugger or instrumentation framework attached to the process, for a rooted or jailbroken operating system, for emulators, and for changes to the app’s code or signature at runtime. When a check fires, the app records the signal, warns, restricts a function or ends the session, according to the app owner’s policy. The term began with server-side web applications, so read any material carefully.
Where the terms mislead
Some sources call a whole product RASP, obfuscation included. Others treat shielding and runtime protection as separate items, and app hardening or in-app protection are used for either. None of these labels tells you what is protected on Android, on iOS or in a given framework. The comparison below uses what each approach does, not what it is called.
Comparison
| Aspect | Static shielding | Runtime checks (RASP) |
|---|---|---|
| When it acts | Before release | While the app runs on the user’s device |
| Question it answers | How hard is the shipped app to read and change? | Is the app being attacked right now? |
| Typical techniques | Obfuscation, string and resource encryption, symbol stripping, inserted integrity checks | Anti-debugging, hooking detection, root detection on Android, jailbreak detection on iOS, emulator detection, runtime integrity checks |
| Attacks it slows | Decompiling, reading logic, extracting secrets, repackaging | Hooking, debugging, tampering with a running app, automation on emulators |
| What it produces | A harder app | Signals and a response your backend can use |
| What to plan for | Build steps, crash symbolication, app size | Response policy design, false-positive testing, runtime cost |
| How attackers work around it | Patient manual analysis | Hiding a checked condition or patching the check out |
Static resistance
Static protection makes the shipped app harder to understand and change, whatever device it lands on. It cannot see what happens while the app runs: an attacker who hooks a function at runtime does not need to read the code first.
Runtime checks
Runtime checks see the live environment and react to it. They run on a device the attacker may control, so they are strongest when static protection makes them hard to find and remove, and when their signals reach a server the attacker cannot touch.
Attacker studies the app
Decompiles the package to find the checks and the logic worth hooking.
Static layer resists
Obfuscation and integrity checks make the runtime checks hard to locate and patch.
Attacker hooks at runtime
Attaches an instrumentation framework to change behaviour live.
Runtime layer detects
RASP notices the hook and applies the response set for this flow.
Backend decides
The signal travels with the request, and your server accepts, steps up or refuses.
Deployment scope
Both approaches depend on the platform, and one platform’s behaviour tells you nothing about the other’s.
On Android, apps ship DEX bytecode, which decompiles to readable code, alongside native libraries. An APK can be modified, re-signed with a different key and installed outside Google Play, which is why integrity and repackaging checks matter. R8 provides baseline shrinking and renaming for Java and Kotlin code, but it does not touch native libraries or framework bundles.
On iOS, apps ship compiled native code, the operating system enforces code signing and apps run in a stricter sandbox. Running a modified copy usually needs a jailbroken device or re-signing with a developer or enterprise certificate. Objective-C class and method names remain visible in the binary, and some runtime signals differ from Android’s. Platform services such as App Attest on iOS and Play Integrity on Android let a backend check an app instance; they complement in-app checks rather than replace them.
Framework code, such as compiled Dart code in Flutter apps or React Native JavaScript bundles and Hermes bytecode, needs its own treatment on each platform.
When you need each
| Your situation | Static shielding | Runtime checks | Notes |
|---|---|---|---|
| Logic or algorithms are valuable intellectual property | Usually needed | Useful | Obfuscation of native and framework code matters most |
| Secrets or endpoints are embedded in the app | Usually needed | Useful | Move secrets to the server where you can |
| Payments, identity or account changes happen in the app | Usually needed | Usually needed | Send runtime signals with each sensitive request |
| Repackaged or modded copies circulate | Usually needed | Usually needed | Integrity checks plus server-side verification |
| Automated abuse from emulators or scripts | Useful | Usually needed | Combine with API protection on the server |
| Low-value content app with no stored secrets | Baseline | Optional | Standard platform tooling may be enough |
Counts of 'Usually needed' cells in the decision table above, across its six situations. It shows that neither layer covers the typical risk profile on its own.
The table is a starting point. Your threat model, your platforms and testing on your own builds decide the mix. Code-level controls are covered on code obfuscation and anti-tampering.
Questions to settle before you choose
- Which platforms and frameworks ship in your next release: Android, iOS, Flutter, React Native?
- What would an attacker gain from reading your code, and what from changing it while it runs?
- Which user flows need a runtime response, and what should that response be?
- Does your backend receive and act on signals from the app today?
- How will you test protected builds on your oldest and newest supported devices?
How Otukan combines the two layers
Otukan delivers static shielding and runtime self-protection as layers that reinforce each other. Obfuscation and integrity checks make the app, and the runtime checks inside it, hard to read and patch. Runtime checks detect hooking frameworks, debuggers, emulators, rooted Android devices, jailbroken iOS devices and modified copies while the app runs.
Every control is scoped separately for Android and iOS, Flutter and React Native apps included, and protection fits your existing build and release pipeline while your signing keys stay with your team.
The controls are covered on mobile app shielding and mobile RASP. For the full product, see mobile app security.