How we review apps before they list
The review pipeline every app goes through, and why it exists
No app lists on Panoply without passing review. Not the first version, not an update, not an app from an established creator. This page is what happens between submitting and going live.
Why there's a review at all
Apps on Panoply run in the buyer's browser. Panoply serves them from its own Worker, which also handles signing the buyer in and, for apps that save data, storing it — the app has no server of its own. So the app's code runs on the buyer's machine, and a malicious app could try to steal data or abuse it. Buyers can't read the source before buying — so somebody has to, and it can't be the person selling it.
What submitting actually does
Submitting validates your upload and creates the listing at pending review. That is the whole of it. Nothing is scanned, and no review begins.
Your submission then waits in a queue until a reviewer opens it. Nothing about your app is automatic — a person starts every stage below, and until one does, an app that has been submitted has had nothing done to it at all.
The pipeline
1. A reviewer picks up your submission
A person opens your app from the review queue and starts the scan. This is the step people don't expect: the scan is not triggered by submitting, it is triggered by a reviewer deciding to look at your app. Time spent waiting here is queue time, not scan time.
2. Automated security scan
Once started, the scan is mechanical and fast: it looks for the categories in What review checks for and produces findings with severities.
If your app has a build step, the build runs here, as part of the scan, and its output is scanned too. That output is what gets deployed later — nothing is rebuilt after review, so what buyers get is what was scanned.
3. Safety review
Marcus, Panoply's Head of Safety & Governance, reviews the scan output and the app itself, and writes a decision. The scan finds things; the review decides what they mean. A scan finding isn't automatically a rejection, and a clean scan isn't automatically an approval.
4. Approval and deploy
A human accepts the verdict. That single action approves the app and deploys it — there's no separate confirm-then-publish step. The build the scan produced is deployed to <slug>.panop.ly and the listing goes live.
How long it takes
Review is a queue with people in it, so it isn't instant — and because the scan only starts when a reviewer picks your app up, a submission can sit with no scan against it for as long as the queue is deep. A submission with no security report yet has not failed anything; it has not been looked at yet.
While your app is pending, the submission page says so. There's nothing to poll and nothing you need to do — you'll see the status change.
What buyers see
The outcome is published on your listing: the categories checked with a passed or flagged mark against each, the reviewer's written note, when it was reviewed, and how many files were covered.
No score and no overall verdict are published, deliberately. Publication is the verdict.
What is not published is the machinery — the specific rules that fired, the patterns they matched, or the scoring. That's deliberate. Publishing the detection rules would tell a bad actor exactly what to avoid, which would make the review worth less to everyone.
Updates are re-reviewed
An update goes through the same pipeline. Your live version stays up while the update is in review, so an update that comes back for changes never takes your app offline. See Update or unpublish an app.
If changes are requested
A submission that doesn't pass comes back as changes requested — a written reason, a banner on the listing, and an email. A failed build lands the same way.
It isn't a rejection and isn't final: fix what was named and resubmit. Nothing counts against you. If you think the finding itself is wrong, see Report a problem.
(Removing a listing outright is a separate action, used for something that shouldn't be on the marketplace at all — not for an app that needs work.)