Review
Every app is checked by a person before it goes live. Automatic checks run first, then a reviewer reads your code with AI help, installs your app, tries it like a customer would and decides.
How long it takes
A person reviews your app within 7 business days. They install and test every app.
Each submission carries that target date, slaDueAt, set 7 business days (Monday to Friday, UTC) after it joined the queue. A resubmission after changes keeps the original date.
Statuses
| Submission status | What it means |
|---|---|
| queued | In line for a reviewer. |
| in_review | A reviewer has started. You get an email. |
| changes_requested | Sent back with notes. Sent back isn't rejected: fix the notes and resubmit as often as you need. |
| approved | Passed review. The version is live in the App Store within minutes. |
| rejected | Not approved. Used when an app breaks the guidelines on purpose; the email carries the reviewer's note. |
| withdrawn | You took it out of the queue. The version is a draft again. |
Your app's own status follows: draft, in_review, changes_requested, live, rejected, and suspended or delisted if EzyStudio takes it down. A live app stays live while an update is reviewed. A reviewer can undo a decision for 10 minutes after making it.
Automatic checks
Five checks run when you submit. Each one passes, warns or fails, and the reviewer sees the result next to your app. They read your demo page (and your bundle's index.html when the demo page can't be read) and your bundle's package.json and lockfile.
| Check | What it looks at | Pass, warn, fail |
|---|---|---|
| Performance | Loads your demo URL and times it, grading a large page as if on a slow phone connection. | Pass up to 1.5 s, warn up to 3 s, fail above. No demo link: warn. Demo doesn't load: fail. |
| Accessibility | Images without alt text, buttons and links with no name, form fields with no label, a page with no language. Plus alt text on your listing images. | No issues: pass. 1 or 2: warn. 3 or more: fail. No page to read: warn. |
| Security | Your bundle's dependencies against known advisories, install scripts, packages from git or URLs, and payment details sent to an outside service. | Critical or high advisory: fail. Moderate advisory, install scripts, non-npm packages or outside payments: warn. No bundle, or no package.json in it: warn. |
| Data handling | That the data note says what is stored and why, and whether the app handles health information. | Note under 20 characters: warn. Health terms found: warn (and flagged). Otherwise pass. |
| Pricing | The price on your listing against prices and fees shown in the app. | Paid without a price, a percentage fee, or a free app asking for money: fail. Other amounts or upsell words (premium, unlock, credits…): warn. |
How we load your demo
- One GET with the user agent
EzyStudio-AppReview/1.0 (+automated checks), up to 3 redirects, an 8 second timeout and the first 2 MB of HTML. - Only public addresses on the normal web ports (80 and 443). A demo on a private network or another port can't be checked.
Flags
Some submissions get a flag that asks the reviewer to look closer. A flag is not a rejection.
| Flag | When |
|---|---|
| Health data | The listing or demo talks about patients, medical history, therapy and similar. |
| Outside payments | The listing mentions PayPal, Venmo, Zelle, crypto, payment links and similar, or the demo loads a payment service (Stripe, PayPal, Square and others) or has a form that sends to another site. |
| Price change | An update changes the price or the pricing model of a live app. |
| Hidden fee risk | Fees, upgrades or credits mentioned on a free listing, any fee mentioned on a paid one, or a percentage fee, other prices or upsell words in the demo. |
| New developer | You don't have a live app yet. |
| Below minimum price | A live app keeps a paid price that is under today's minimum paid price. |
What the reviewer checks
The reviewer opens your app in a throwaway test site (it lasts 2 hours) and ticks every item before they can approve:
The test site has its own database. Your migrations run on it when it is built, then it gets sample customers (they can't sign in), the template's starter records and your own sampleData rows if you ship them (Sample data for review). If your migrations or your sample data fail, the test site fails and the reviewer sees why.
- Installed and opened with no setup
- Tried a one-sentence customization
- Price matches the listing and checkout
- Screenshots match the real app
- Data note is clear and accurate
Your code is read before approval
Before approving, the reviewer opens the full source of your version, exactly as it was frozen from GitHub when you submitted, in a private, read-only copy, and reads all of it with AI help. A person makes the decision; the AI helps them read every file. They look for:
- What your app stores and where, compared with your data note
- Every call to another service, and the data it sends
- Payment links or payments taken outside the platform's checkout
- Sign-in and permission checks on your server routes and portal screens
- Keys, tokens or passwords in the code
- Minified, obfuscated or dynamically loaded code (eval and the like)
- Crypto mining, hidden tracking or other abuse
- Whether the code does what your listing says, and uses only what your manifest declares
- Migrations that drop, rename or rewrite data
- For an update: every change since the live version, against “What customers might lose” and your update notes for the AI
Send readable source. Minified or obfuscated code can't be reviewed and is sent back. When the code review finds something, the reviewer's note names the file and the line.
They also hold every app to the eight review guidelines: works out of the box, customizable by one sentence, no hidden fees, respects user data, accessible, fast, honest listing, a real support contact.
When changes are requested
Each ask names a reason and the part of your listing to change. Your draft shows them under “Reviewer asked for”, ticked as you fix them.
| Reason | Points you at |
|---|---|
| Missing alt text | Listing images |
| Price not clear | Pricing |
| Hidden fees | Pricing |
| Data note unclear | Data note |
| Screenshots don't match | Screenshots |
| Broken on mobile | Your app (bundle) |
| Slow to load | Your app (bundle) |
| Unlabeled buttons | Your app (bundle) |
| Reviewer note | Anything; resolved by your next submission |
Common reasons apps get sent back are listed on the developer program page.