Scan an Android build before the store reviews it
Upload an .apk and Veriify reads what a reviewer reads: the manifest, the permissions, the bundled SDKs, the signing and target API. It reports what will likely be flagged, scored on the same rubric, with the same evidence trail, as every other Veriify scan.
Sign in with a Premium account to upload an Android build and get a Store Readiness report.
Sign in →What you will be able to point it at
Coverage depends on what you hand over. The build artifact is where nearly all store-rejection risk is actually decidable, so that is the primary input.
Build artifact
.apk, .aab or .ipa. The manifest, permissions, SDKs, secrets, signing and size.
Store listing
A published app's public metadata, no upload needed.
Repository
Source-level checks through the existing repo connector.
Live device
Crashes, ANRs, cold start and the real accessibility tree.
Store acceptance criteria
The checks that map to what Apple and Google actually reject for. Unlike a web check, store policy is time-bound (target API levels move every year, privacy manifests became mandatory) so every one of these records the policy revision it was judged against.
STORE-A Google Play submission
Requirements enforced at upload and in policy review.
- Target API level meets Play's current minimum
- 64-bit libraries present alongside any 32-bit
- Shipped as an App Bundle, signed with a modern scheme
- Permissions that require a declaration form: SMS, call log, all-packages, all-files, background location
- Foreground service types declared, as Android 14 requires
- Ad ID permission present when an ads SDK is bundled
- Account deletion offered wherever accounts can be created
STORE-I App Store submission
Guideline requirements that are decidable from the build.
- A purpose string for every permission-gated API used, a missing one is both a rejection and a crash
- Purpose strings that are specific, not placeholder
- Tracking description present when IDFA or tracking SDKs are detected
- Privacy manifest present, with required-reason API declarations
- Encryption export compliance declared
- Sign in with Apple offered alongside third-party social login
- No deprecated web views, no non-public API symbols
STORE-C Listing quality
Checks that apply to both stores.
- Screenshot count and dimensions meet each store's minimum
- No placeholder text or lorem ipsum in the description
- Content rating consistent with detected capabilities
- Privacy policy URL resolves to an actual privacy policy
MPRIV Privacy and permissions
Where declarations meet reality.
- Declared data collection contradicted by the SDKs actually bundled, the check stores enforce hardest
- Dangerous permissions with no matching capability in the app
- Tracker and analytics SDKs, named individually
- Children's policy signals when the app targets minors
- Consent tooling present where EU-targeted ads are detected
And everything Veriify already checks, applied to mobile
Scored on the same dimensions as every other Veriify scan, plus a store-readiness dimension and a mobile weight preset. Security carries the most weight; dimensions that cannot apply are marked not-applicable and their weight redistributes, so nothing is penalised for being irrelevant.
MSEC Security
Aligned to the OWASP mobile standard.
- Cleartext traffic permitted, or transport security weakened per-domain
- Debuggable or backup-enabled release builds
- Components exported without permission guards
- Web views with scripting plus a native bridge or file access
- Hardcoded credentials in the binary, resources or strings
- Weak cryptography and insecure randomness
- Bundled SDKs with published vulnerabilities
- Deep links declared without verification, allowing hijacking
MUX / MPERF Accessibility and performance
What a static build can prove.
- Interactive elements with no accessibility label
- Touch targets below the platform minimum
- Text scaling or dynamic type disabled
- No right-to-left, dark mode or large-screen support
- Download size against each store's ceiling
- Oversized assets, unstripped symbols, redundant native ABIs
MFUNC / MREL Correctness and reliability
The things that ship by accident.
- Placeholder or lorem ipsum strings left in the build
- Endpoints pointing at localhost, staging or a private address
- Debug menus reachable in a release build
- Declared privacy, support or marketing URLs that fail to resolve
- No crash reporting configured
MGEN Genuineness
Does the app do what the listing claims?
- A web view wrapper with no native capability, the concrete form of Apple's minimum-functionality rejection
- Store metadata claiming capabilities the build cannot deliver
What it will not claim
- It will not predict approval. Review is human judgment. Veriify reports measurable risk against published criteria, "this will likely be flagged under Play's foreground-service policy", never "this will be rejected" or "this will pass".
- Crash rate and ANR are not knowable from a build. Those come from a live device run or your store vitals, and will be reported as such.
- Whether your screenshots represent your app is judgment, not something a scan can decide.
- iOS coverage is narrower than Android. A build gives us the property list, privacy manifests, frameworks and binary strings, enough for the checks above, not full symbol analysis.
- A declared data-safety form cannot be fully verified without watching real network traffic. We detect contradiction, not completeness.
Veriify also scans websites, web apps, repositories and AI products today.
Read about scan modes