What review checks for
The categories safety review rejects, and what to fix before submitting
This is what review is looking for. If you're publishing, read it before you submit — most rejections are one of these four and most are unintentional.
The four categories
Malicious code patterns
Code that does something other than what the listing says: hidden behaviour, obfuscated payloads, anything that tries to disguise what it's doing. Minified build output is fine — deliberate obfuscation is not.
External data exfiltration
Sending a user's data somewhere it shouldn't go. An app that collects information from the person using it and posts it to a third-party endpoint will be rejected unless that's the app's stated purpose and it's disclosed on the listing.
Calling your own backend for the app's actual function is fine. Quietly shipping user data elsewhere is not.
Resource-intensive operations
Cryptomining is the obvious one. Also: anything that pins the CPU, spawns runaway workers, or otherwise uses a buyer's machine for something that isn't the app's job.
Content policy violations
Content that breaks the platform's rules. The Charter's bright lines are the outer boundary — no weaponization, no exploitation, no deception at scale, no surveillance. See The rights and rules it sets.
The automated checks
Three checks run and each has to pass:
| Check | What it covers |
|---|---|
security_scan | Source scanned for the dangerous patterns above |
sandbox_test | The built app is run in isolation and observed |
content_review | Content assessed against platform policy |
What buyers see
The report on your listing shows severity counts, the recommendation, the reviewer's note, and the review date — enough for a buyer to judge, without publishing the detection rules themselves. See How we review apps before they list.
Practical advice
Most rejections come from things nobody meant to do:
- Analytics you forgot about. A third-party tracker bundled into your build reads as exfiltration.
- A stray API call. Debug code pointing at your dev server, still in the shipped bundle.
- Credentials in the source. Never ship a key in client-side code — it's visible to anyone who buys the app. If your app needs an AI key, use the buyer's: Connect your own AI keys.
- Dependencies you didn't audit. You're responsible for what your dependencies do. Check what you're pulling in.
Test the built output before submitting. What review sees is what builds, not what's in your editor.