Upload a build. Read what review would say.

Verdict reads the file you are about to submit and reports the problems a reviewer would find, each cited to the guideline it breaks. Here is the whole path, and what a finished report actually contains.

Verdict tells you why your app would be rejected, while you can still fix it.

Three steps, no configuration, and no account for the first look. Drop in the build you were about to ship and you get back the same findings a reviewer would reach, each one cited and paired with the change that clears it.

You upload

The build you were about to submit

An .ipa exported from Xcode, an .apk or .aab from your Gradle release task, a zipped macOS .app, or a Windows .msix.

Trailhead.ipa42.6 MB

.ipa.apk.aab.app.msixup to 1000MB

Verdict reads it

The same things a reviewer's tooling reads

Signatures, entitlements, manifests, permissions, embedded SDKs, and deprecated APIs. Nothing is executed.

CFBundleIdentifier

NSCameraUsageDescription

NSAppTransportSecurity

UIRequiredDeviceCapabilities

Info.plistMach-OAndroidManifestDEX

You get back

A score, and every problem with its fix

Each finding is cited to the rule it breaks and paired with the exact change that resolves it.

Blockers2

Warnings3

Advisories1

Risk scoreGuideline citedEvidenceThe fix

App review is the last gate before a release, and it is the one part of shipping a mobile app that developers have the least visibility into. Roughly a quarter of submissions are rejected, usually for something small and mechanical, and the feedback arrives days later as a guideline number with little explanation.

Verdict closes that gap. It reads the build you are about to submit and reports what a reviewer would find, before you spend a review cycle finding out. Every finding names the rule it comes from and shows the evidence in your own binary, so you can judge it rather than take our word for it.

It is built for the teams who feel this most: solo developers shipping their first app, studios releasing on a schedule, and anyone who has watched a launch slip because of a missing key in a configuration file.

What it is

A reviewer’s-eye read of the build you are about to submit, every finding cited to the rule it comes from.

What it’s not

Not an approval guarantee, and it does not speak for Apple or Google, or judge whether an app is original enough.

Checks on every build

Store policies tracked

0.0s

Median scan time

Verdict

An independent tool. Not affiliated with, endorsed by, or sponsored by Apple or Google.

Then the report becomes a to-do list.

Reading what is wrong is one afternoon. Shipping is the weeks after it, usually with other people. The same workspace carries that part, on every plan including free.

Turn a finding into a task

One press on the report, and it carries the rule, the guideline, and the fix. When a later build stops reporting that rule, the task closes itself.

Give the app a date

Set the day you mean to submit and the dashboard counts down to it. Point the recurring check at your site and Verdict re-reads it every day or week.

Keep the team in one place

Everyone in a workspace shares the same board and the same feed, and a Slack or Discord channel hears about every scan, task, and check.