Kids Category App Review checklist for child-safe releases

Decide whether the Kids category is truly the product promise

Do not select the Kids category because it sounds more trustworthy. Choose it only when the product is designed for children and the whole experience can meet a child-directed standard. If adults are the primary users and children are incidental subjects, the category decision may be different from the age-rating decision.

Write a one-paragraph audience statement before submission: who uses the app, who supervises, what a child can do alone, and what requires an adult. This statement helps engineering and product teams catch features that were built for general audiences but now sit inside a Kids category app.

Run a child-first tap-path audit

1. Start from a clean install with no account and tap every visible control on the first three screens.
2. Record any path to the web, social sharing, email, chat, purchases, app ratings, external media, or account creation.
3. Confirm adult-facing paths are behind an effective parental gate, not only a small text warning.
4. Verify the child can return to the intended activity without reaching a dead end or support page.
5. Repeat after completing onboarding, unlocking sample content, and denying permissions.

Treat ads and third-party code as review evidence

A child-directed app should not depend on broad behavioral advertising assumptions. If ads, analytics, attribution, crash reporting, or embedded media SDKs exist, document what they collect, whether they track, and whether the child-facing surface changes because of them.

AppReviewReady interpretation: the SDK list is part of the Kids review packet. Compare SDK vendor documentation with the privacy label, privacy manifest, ATT decision, and in-app consent model. If a dependency cannot be explained in child-safety terms, remove or isolate it before review.

Minimize account and data requirements

• Avoid requiring a child's name, precise birthday, school, location, contacts, photos, microphone, or camera unless the feature truly needs it.
• Use local progress where possible, and explain account benefits in adult-facing language.
• Make deletion, support, and privacy contact paths reachable by an adult without exposing child data in public screens.
• Ensure any parental email workflow cannot be used by a child to send arbitrary messages or reveal personal information.

Prepare a Kids review proof packet

Use Review Notes to show the reviewer where the child-safe controls are, not to make broad assurances. The app should be self-evident when tested, but a concise note reduces the chance that a hidden adult path is mistaken for a missing control.

Kids review evidence:
Primary audience: [age range and supervisor]
Adult-only controls: [links, purchases, account, sharing]
Parental gate method: [how it works]
Third-party SDKs: [names and purposes]
Data collected from child-facing flow: [minimum fields]
Permissions requested: [reason and timing]
Test path: [screens to verify]

Freeze child-safety changes before the final build

Last-minute marketing SDKs, web links, cross-promotions, or monetization experiments can invalidate the review packet. Freeze child-facing controls before the final QA pass and require a new Kids audit for any dependency or screen that changes after that point.