Scan an Android APK or iOS IPA

What you can scan

• Android APK - the production binary you ship to Play Console.
• iOS IPA - the archive you upload to App Store Connect.

We do not need a debug build, an unsigned variant, or your signing keys. We do not need source code. The release binary is enough.

Limits

• Per-binary size: 50 MiB. Most production APKs and IPAs land well below this. If your binary is larger, split out heavy assets before upload or contact us.
• Rate limit: 6 mobile uploads per organisation per hour. Heavy abuse protection; not meant to throttle legitimate use.
• Single platform per scan: APK and IPA are scanned as separate targets. Upload each independently to get cross-platform coverage.

How the flow works

1. Open Settings > Cloud integrations > Mobile binary on the dashboard.
2. Click Upload binary and pick the APK or IPA from disk. We detect the platform from the filename + a quick magic-byte sniff.
3. A new target of type mobile_app is created in the active project. The binary lands in a private storage bucket gated to the service role - no dashboard staff can inspect it.
4. Hit Run scan on the new target. The worker decompiles the binary in an isolated scratch directory, runs static analysis + dependency CVE detection + secret pattern detection + manifest review (AndroidManifest.xml for APK, Info.plist for IPA) + bundled SDK fingerprinting.
5. Decompiled artifacts are deleted as soon as the scan completes. Only the parsed findings + the original binary (if you want to re-scan later) are retained.
6. The findings appear on the target detail page and in every PDF report - executive, developer remediation, compliance, and trend.

What the report tells you

• Risky permissions declared in the Android manifest or iOS entitlements that the user is not made aware of in your store listing.
• Hard-coded secrets in compiled classes or string tables (API keys, signing secrets, debug tokens left behind).
• Known-vulnerable third-party SDKs bundled into the binary, mapped to CVEs + the fixed-in version.
• Insecure transport (cleartext HTTP, missing ATS exception, certificate pinning gaps).
• Misconfigured storage (world-readable file modes, exported content providers, insecure shared preferences).
• SDK inventory - every analytics, ads, and third-party library bundled, with a public CVE check per SDK version.

What the report does NOT tell you

• Runtime exploitation. We do static + binary analysis. We do not boot your app on an emulator and try to interact with the running process. That is the manual pentest workflow; we do not pretend to replace it.
• Reverse-engineered business-logic flaws. Decompilation tells us what the binary contains, not how your back-end interprets it.
• Server-side issues. Mobile binary scan covers the client. Pair it with an API or web target on the same workspace to cover the back-end.

Privacy

• The binary lives in a private storage bucket. Only the worker (service-role) can fetch it.
• Decompiled artifacts are deleted as soon as the scan ends.
• We never publish, mirror, or ship your binary anywhere outside our infrastructure.
• If you delete the target, the binary + every finding referencing it are deleted within minutes.

FAQ

My APK is signed with a release key. Is that OK?
Yes. We do not need your signing keys. We decompile the public binary; the signature is preserved end-to-end.

What about iOS bitcode-only archives?
Supported. The bitcode is parsed alongside the Mach-O for symbol + entitlement extraction.

Can I scan a Flutter / React Native / Expo APK?
Yes. We detect cross-platform framework binaries and adapt the SDK fingerprint pass accordingly. The framework version itself is reported as a finding when out-of-date.

Does this replace MDM / SAST on source code?
It complements them. If you have source-code access too, connect a GitHub repository target on the same project and the SAST pass picks up source-level issues the compiled binary cannot reveal.