Reference
How stores review an app
Shipping is a pipeline of gates most makers never see until a rejection email. Reading your own submission the way a store will — before you submit — turns a wasted review cycle into a clean upload. Here are the five generic gates and a pre-submit checklist. Open the submission lab →
- Built with a current SDK
A store sets a yearly cutoff date; after it, new submissions must be built with a recent software-development kit or the UPLOAD is rejected before any human reviews it. The fix is a rebuild, not a redesign.
- The right age rating
Ratings are set by what an app CAN do, not what it intends. Unrestricted web access, open chat, or simulated gambling raise the minimum age. A rating lower than the content allows is rejected.
- An honest privacy label
Disclose every kind of data the app — and any bundled kit — collects. Collecting data is fine when it’s opt-in, declared on the label, and deletable; collecting it SILENTLY is not. A bundled kit’s collection is YOUR collection.
- Complete & follows the rules
The app must be finished — no “lorem ipsum”, no crashes, no half-built screens — do what the description says, and use only public, documented APIs. Most rejections are for something MISSING, not the idea.
- The kids’ section is stricter
A children’s app must not show third-party behavioral ads, must not send kids to the open web or a store without a parental gate, and must not collect personal data. A walled garden by default.
Check your own submission before you ship
- Rebuild on the current SDKConfirm the build uses this year’s SDK before you upload — the cutoff is a hard gate on the upload itself.
- Rate for the riskiest thingList everything the app CAN do (web, chat, purchases). Pick the rating that matches the riskiest, not the average.
- Make the label match realityAudit every kit you bundled. If any collects data, the privacy label must say so — or remove the kit.
- Open every screenNo placeholder text, no crashes, no dead buttons. Reviewers open everything; finish it before you submit.
- Wall the garden (kids)No third-party ads; gate every external/store link behind a parental gate; collect no personal data.
- Read the current rulesStores change their rubric every year, and none of this is legal advice. Read the store’s OFFICIAL current guidelines before you rely on any checklist — including this one.
These gates are generic store criteria in the spirit of a real submission pipeline — not any one vendor’s official rules, no affiliation implied, and not legal advice. Stores change their rules every year: read the official current guidelines before you rely on any checklist. Nothing you check here leaves your device. Check a submission →
Where this idea comes from
The label’s family tree
The United States passed the Nutrition Labeling and Education Act in 1990, and from 1994 packaged food carried the black-and-white Nutrition Facts panel: the same boxes in the same order on every product, so you could compare two at a glance.
One thing to hold: A “nutrition label” for privacy, proposed in 2009 by Patrick Gage Kelley, Joanna Bresee, Lorrie Faith Cranor and Robert Reeder at Carnegie Mellon University: a website’s data practices in one fixed grid. In December 2020 Apple’s App Store began showing privacy labels on every app, and Google Play added a Data safety section in 2022.
Why it matters: A label works when it is the same shape everywhere, so the reader learns it once. App-store submissions ask developers to fill in that shape, which is why getting the answers right is part of shipping.
What we don’t know: Whether labels change what people choose is still studied. Research on app privacy labels has found that many labels do not match what the apps actually do, so a label is a claim, not a check.
Dates:
- 1990 The Nutrition Labeling and Education Act passes.
- 1994 The Nutrition Facts panel appears on packaged food.
- 2009 A privacy “nutrition label” is proposed at Carnegie Mellon.
- 2020 App Store privacy labels begin.