Two platforms, two very different ways to fail
Android and iOS fail in different places — one leaks through exported components and over-permissive storage, the other through keychain misuse and weak tamper resistance. We test both on real devices, and we do not stop at the app boundary.
What this covers
- Static and dynamic analysis on real rooted and jailbroken devices
- Insecure local storage, keystore and keychain misuse
- Exported components, intents, URL schemes and deep-link abuse
- Certificate pinning and transport security bypass
- Authentication, session handling and biometric bypass
- The backend APIs your app depends on
- Reverse engineering, tampering and anti-debugging resistance
- MASVS and MASTG aligned reporting for both platforms
The app is a client, not a system
Android and iOS need separate test plans
Most mobile findings are backend findings
How we run it
Questions about mobile app testing
It helps and it speeds things up, but it is not required. We can work entirely from a release build using static analysis and dynamic instrumentation. Source access mainly lets us give you a line number instead of a code location — useful, but not a blocker.
Yes, and we usually should, because that is the build your users actually have. We will test the store version and, where you have one, a release candidate with debugging symbols so the reporting is more precise.
It raises the effort required and is worth doing, but treat it as a speed bump rather than a control. Anything shipped to a device can eventually be reverse engineered. The durable fixes are server-side: never trust the client, and never ship a secret you cannot rotate.
Ready to look at this properly?
A 30-minute call, no pitch deck. We will tell you whether we are the right fit — and if we are not, we will point you somewhere better.