My first kids app got rejected three times. The first rejection: no parental gate. The second: an external link that bypassed parental controls. The third: AdMob ad formats that didn't comply with the Kids category rules.
I had read Apple's documentation carefully. The problem is that there's a significant gap between what the documentation says and what reviewers actually check — a gray zone that trips up even experienced developers on their first kids app.
This guide walks through everything needed to ship a kids app in Rork Max to the App Store Kids category. The structure is intentional: I'll show you where things go wrong before explaining how to fix them.
Why the App Store Kids Category Is Fundamentally Different
The Kids category covers three age groups: 5 and Under, 6–8, and 9–11. Each group has different content requirements and implementation constraints.
The reason the Kids category gets special treatment is that Apple's guidelines overlap with COPPA (Children's Online Privacy Protection Act) and similar laws globally. The result is a set of rules that affect not just your content, but the core architecture of your app.
Key constraints unique to the Kids category:
- Parental gates are required before external links, purchases, and transitions to other apps
- External website links are either fully prohibited or must be guarded by a parental gate
- Third-party data collection and behavioral tracking SDKs must be COPPA-compliant
- All ads must be Kids-safe (COPPA-compliant formats only)
- Social features — chat, friend requests, user reviews — are prohibited or heavily restricted
Age Tiers and Content Rules
When you submit to the Kids category, you declare a target age tier. The content restrictions are roughly:
- Ages 5 and Under: Most restrictive. Even cartoon violence is out. Simple educational content only.
- Ages 6–8: Fantasy competitive games are allowed. Chat and social network elements are not.
- Ages 9–11: Light humor and competition elements are allowed. Purchases must go through Ask to Buy.
What matters in practice is that your content must fit the declared tier, and reviewers will make that judgment call looking at your screenshots and description.
The Third-Party Data Problem
COPPA is a US federal law, but it effectively applies to the global App Store. The core rule: collecting personal information from children under 13 requires verifiable parental consent.
This affects your Rork Max app in several concrete ways:
- Firebase Analytics, Facebook SDK, Amplitude — all collect behavioral data that's COPPA-restricted
- AdMob requires specific configuration for children's content
- User accounts collecting email addresses or birthdays need parental consent flows
- Crash reporting tools (Crashlytics, Sentry) may collect device identifiers
Rork Max can default to including Firebase Analytics in some configurations. For a Kids category app, you'll need to either enable COPPA mode or replace these SDKs entirely.
COPPA Implementation Checklist
Here are the three areas that require the most attention.
Firebase Analytics: COPPA Mode
If you're keeping Firebase Analytics, configure it for COPPA compliance at initialization:
// app.ts or App.tsx initialization
import analytics from '@react-native-firebase/analytics';
async function initAnalyticsForKids() {
// Disable all personalized tracking
// This automatically turns off:
// - Ad identifier collection (IDFA/GAID)
// - Age/gender inference
// - Cross-app tracking
await analytics().setConsent({
ad_personalization: false,
ad_storage: false,
ad_user_data: false,
analytics_storage: false,
});
// Stop user ID collection entirely
await analytics().setUserId(null);
// Mark as children's app (Firebase SDK 10.x+)
// Disables all ad-related auto events
await analytics().setDefaultEventParameters({
app_audience_type: 'children',
});
}In practice, I've found that removing Firebase Analytics entirely makes the review process cleaner. Privacy-respecting alternatives include Apple's SKAdNetwork-based measurement and self-hosted PostHog (where data never leaves your infrastructure).
AdMob: Kids Safe Configuration
Using AdMob without proper configuration will serve behavioral targeting ads to children — a COPPA violation. Here's the correct setup:
import MobileAds, { MaxAdContentRating } from 'react-native-google-mobile-ads';
async function initAdMobForKids() {
await MobileAds().setRequestConfiguration({
// Strictest content rating
maxAdContentRating: MaxAdContentRating.G,
// Tag for child-directed treatment
// This guarantees:
// - No behavioral targeting
// - COPPA-compliant content only
tagForChildDirectedTreatment: true,
tagForUnderAgeOfConsent: true,
});
await MobileAds().initialize();
}
// Only use banner ads in Kids category
// Interstitial ads are prohibited (they force screen transitions)
const bannerConfig = {
adUnitId: 'ca-app-pub-XXXXXXXXXXXXXXXX/XXXXXXXXXX',
size: BannerAdSize.BANNER,
requestOptions: {
requestNonPersonalizedAdsOnly: true, // Required
networkExtras: {
max_ad_content_rating: 'G',
},
},
};Common mistake: tagForChildDirectedTreatment: true can be overridden by the AdMob dashboard's content settings. Check that your ad units are set to G-rating in the AdMob console, not just in code.
Data Minimization
The guiding principle: only collect data that the app needs to function. For most kids apps, that means keeping everything local.
// Bad: collecting personal data for an account system
const badDesign = {
email: 'user@example.com', // Off-limits without parental consent
birthdate: '2018-01-01', // Age-identifying data — restricted
};
// Good: anonymous local progress storage
import AsyncStorage from '@react-native-async-storage/async-storage';
async function saveProgressLocally(level: number, score: number) {
// Store only non-identifying game state
// This data never leaves the device
await AsyncStorage.setItem('game_progress', JSON.stringify({
level,
highScore: score,
lastPlayed: new Date().toISOString(),
}));
}If you need server-side data storage, you'll need a full parental consent flow before collecting anything. Many successful kids apps sidestep this entirely by keeping state device-local.
Implementing the Parental Gate
A parental gate is a checkpoint that prevents children from accidentally — or intentionally — taking certain actions. Required before:
- External links of any kind
- Purchase and subscription screens
- Transitions to other apps (including your own App Store pages)
- External service logins
What Apple Considers a Valid Parental Gate
Apple's requirement is that the gate uses knowledge-based questions that children can't easily answer. Things that don't count:
- Tapping specific numbers (children can tap randomly and get through)
- Simple pattern matching
- Image recognition (children are often better at this than adults)
Valid approaches: multi-digit arithmetic (two-digit multiplication), text input, or date of birth entry.
Complete Implementation
// ParentalGate.tsx — math question-based parental gate
import React, { useState, useMemo } from 'react';
import { View, Text, TextInput, TouchableOpacity, Modal, StyleSheet, Alert } from 'react-native';
interface ParentalGateProps {
visible: boolean;
onSuccess: () => void;
onCancel: () => void;
}
function generateMathQuestion(): { question: string; answer: number } {
// Two-digit multiplication: easy for adults, hard for young children
const a = Math.floor(Math.random() * 70) + 20; // 20–89
const b = Math.floor(Math.random() * 70) + 20; // 20–89
return { question: `${a} × ${b}`, answer: a * b };
}
export const ParentalGate: React.FC<ParentalGateProps> = ({ visible, onSuccess, onCancel }) => {
const [inputValue, setInputValue] = useState('');
const [attempts, setAttempts] = useState(0);
// Generate a fresh question each time the modal opens
const { question, answer } = useMemo(() => generateMathQuestion(), [visible]);
const handleSubmit = () => {
const userAnswer = parseInt(inputValue, 10);
if (userAnswer === answer) {
setInputValue('');
setAttempts(0);
onSuccess();
} else {
const newAttempts = attempts + 1;
setAttempts(newAttempts);
setInputValue('');
if (newAttempts >= 3) {
// Close after 3 failures — prevents brute-force attempts
Alert.alert(
'Verification Failed',
'Please ask a parent or guardian to try again.',
[{ text: 'OK', onPress: () => { setAttempts(0); onCancel(); } }]
);
} else {
Alert.alert('Try again', `${3 - newAttempts} attempt${3 - newAttempts !== 1 ? 's' : ''} remaining.`);
}
}
};
return (
<Modal visible={visible} transparent animationType="fade" onRequestClose={onCancel}>
<View style={styles.overlay}>
<View style={styles.container}>
<Text style={styles.title}>Parent or Guardian</Text>
<Text style={styles.subtitle}>
This section requires a parent or guardian to confirm.
</Text>
<View style={styles.questionBox}>
<Text style={styles.questionLabel}>Solve this math problem:</Text>
<Text style={styles.question}>{question} = ?</Text>
</View>
<TextInput
style={styles.input}
keyboardType="numeric"
value={inputValue}
onChangeText={setInputValue}
placeholder="Enter your answer"
maxLength={6}
autoFocus
/>
<View style={styles.buttonRow}>
<TouchableOpacity style={[styles.button, styles.cancelButton]} onPress={onCancel}>
<Text style={styles.cancelButtonText}>Cancel</Text>
</TouchableOpacity>
<TouchableOpacity
style={[styles.button, styles.submitButton]}
onPress={handleSubmit}
disabled={!inputValue}
>
<Text style={styles.submitButtonText}>Confirm</Text>
</TouchableOpacity>
</View>
</View>
</View>
</Modal>
);
};
const styles = StyleSheet.create({
overlay: { flex: 1, backgroundColor: 'rgba(0,0,0,0.5)', justifyContent: 'center', alignItems: 'center' },
container: { backgroundColor: '#fff', borderRadius: 16, padding: 24, width: '85%', maxWidth: 360 },
title: { fontSize: 20, fontWeight: '700', textAlign: 'center', marginBottom: 8 },
subtitle: { fontSize: 14, color: '#666', textAlign: 'center', marginBottom: 20, lineHeight: 20 },
questionBox: { backgroundColor: '#f5f5f5', borderRadius: 12, padding: 16, marginBottom: 16, alignItems: 'center' },
questionLabel: { fontSize: 13, color: '#555', marginBottom: 8 },
question: { fontSize: 28, fontWeight: '700', color: '#333' },
input: { borderWidth: 1.5, borderColor: '#ddd', borderRadius: 10, padding: 12, fontSize: 18, textAlign: 'center', marginBottom: 20 },
buttonRow: { flexDirection: 'row', gap: 12 },
button: { flex: 1, padding: 14, borderRadius: 10, alignItems: 'center' },
cancelButton: { backgroundColor: '#f0f0f0' },
cancelButtonText: { color: '#666', fontWeight: '600' },
submitButton: { backgroundColor: '#4A90E2' },
submitButtonText: { color: '#fff', fontWeight: '700' },
});Wrap any external link in this component:
// External links always go through the parental gate
import { Linking } from 'react-native';
import { useState } from 'react';
export const ExternalLinkButton = ({ url, label }: { url: string; label: string }) => {
const [gateVisible, setGateVisible] = useState(false);
return (
<>
<TouchableOpacity onPress={() => setGateVisible(true)}>
<Text>{label}</Text>
</TouchableOpacity>
<ParentalGate
visible={gateVisible}
onSuccess={() => {
setGateVisible(false);
Linking.openURL(url);
}}
onCancel={() => setGateVisible(false)}
/>
</>
);
};The Three Most Common Parental Gate Mistakes
Mistake 1: Number-tap verification only
A modal that says "tap 1-2-3" isn't a parental gate — it's a minor inconvenience a toddler can bypass. Apple will catch this. Use arithmetic or text input instead.
Mistake 2: External links without a gate
"Support page," "Privacy policy," "Terms of service" — all of these need to go through a parental gate in the Kids category. The only exception is links Apple explicitly hosts.
Mistake 3: Your own App Store pages without a gate
"More apps from us" sections also require parental gates. Many developers assume their own App Store listings are safe to link to directly. They're not.
Kids App UI/UX Design Principles
Touch Targets and Error Prevention
Children's fingers are larger and less precise than adults'. Minimum touch target size: 60×60 points (Apple recommends 44×44 for standard apps, but kids apps need more).
const kidsButtonStyle = {
width: 80,
height: 80,
borderRadius: 20, // Larger radius for a friendlier feel
justifyContent: 'center' as const,
alignItems: 'center' as const,
margin: 8, // At least 16pt gap between adjacent buttons
};For destructive actions (delete, reset), always use a confirmation dialog — or better, don't include them at all if they're not essential to the core experience.
Audio, Animation, and Positive Reinforcement
Three things that consistently improve kids app quality:
Positive feedback on success: Sparkle effects and sound on correct answers. Lottie animations work well here and are straightforward to integrate with Rork Max.
Repetition-friendly design: Children enjoy repeating the same content. Having 3–5 variants of a character reaction or dialog line measurably increases session length.
Avoid overstimulation: No flashing or strobe effects (seizure risk). Animations should run 20–30% slower than you'd use for an adult app.
Content and Ad Restrictions
- Social sharing buttons: Prohibited (they lead to external services)
- Review request links: Must go through parental gate
- Banner ads: COPPA-compliant formats only. Interstitials are banned in Kids category
If you want to avoid ads altogether, a paid upfront price or a parent-purchased subscription (via Ask to Buy) are the most practical revenue paths for Kids category apps.
Ask to Buy and Monetization
Children using shared family devices will often have purchase restrictions active. Your app needs to handle the Ask to Buy scenario gracefully.
Ask to Buy: a child initiates a purchase, the request is held pending, and a parent approves it from their own device.
RevenueCat Integration for Ask to Buy
import Purchases, { PURCHASES_ERROR_CODE, PurchasesError } from 'react-native-purchases';
async function handleKidsPurchase(packageToPurchase) {
try {
const { customerInfo } = await Purchases.purchasePackage(packageToPurchase);
unlockPremiumContent(customerInfo);
} catch (error) {
const purchasesError = error as PurchasesError;
// Ask to Buy pending state — common when a child initiates the purchase
if (purchasesError.code === PURCHASES_ERROR_CODE.PAYMENT_PENDING_ERROR) {
showAskToBuyPendingUI();
// Display: "A request has been sent to your parent or guardian."
return;
}
// Cancelled — handle silently
if (purchasesError.code === PURCHASES_ERROR_CODE.PURCHASE_CANCELLED_ERROR) {
return;
}
showPurchaseErrorUI(purchasesError.message);
}
}
// On app launch: handle the case where the parent approved while the app was closed
async function checkPendingPurchases() {
try {
const customerInfo = await Purchases.getCustomerInfo();
if (customerInfo.entitlements.active['premium'] !== undefined) {
unlockPremiumContent(customerInfo);
}
} catch (error) {
// Network failure, etc. — ignore silently
}
}The key UX insight here: when Ask to Buy is pending, tell the child something positive. "We've sent a request to your parent — you'll get access once they approve" is a much better experience than "Purchase failed."
Crafting Rork Max Prompts for Kids Apps
The way you phrase your Rork Max prompts significantly affects the compliance quality of the generated code.
Sample Prompt for a Gated External Link
Generate a React Native (Expo) component with these requirements:
- A "Support Page" button for an App Store Kids category app
- Tapping the button shows a parental gate (two-digit multiplication quiz)
- The external URL only opens after the parent answers correctly
- Three wrong answers close the gate
- TypeScript + React Native (Expo)
- Kid-friendly UI: large touch targets, rounded corners
The math question should be easy for adults but hard for young children
(e.g., 23 × 47). Parent verifies, then the link opens.
Prompt Engineering Tips for Compliance
Adding these phrases to any Kids-related prompt produces significantly better output:
"Comply with App Store Kids category guidelines"
"Minimize personal data collection per COPPA requirements"
"Include a parental gate at appropriate interaction points"
With these additions, Rork Max tends to include parental gate scaffolding automatically when it generates external links or purchase flows.
Common Rejection Reasons and Fixes
Rejection 1: Missing parental gate (most common)
Fix: Audit every external link and purchase path in your app. List them explicitly, then verify each one has a gate. A single missed link is enough to trigger rejection.
Rejection 2: Third-party SDK data collection
Fix: Verify your Privacy Manifest (PrivacyInfo.xcprivacy) declares all Required Reason APIs used by your dependencies. Firebase, Crashlytics, and AdMob all use multiple restricted APIs. Any non-COPPA-compliant SDK must be removed.
Rejection 3: Non-compliant ad formats
Fix: In your AdMob console, verify every ad unit targeting this app is set to G-rating. Interstitial ads should not be used at all in Kids category.
Rejection 4: Content doesn't match the age tier
Fix: Have someone outside your development circle review your app with your declared age tier in mind. Reviewers make this judgment from screenshots — dark colors, scary character expressions, or anything with even mild tension can trigger a flag.
Rejection 5: Push notification permission at the wrong time
Fix: In Kids apps, request push notification permission only from settings screens that a parent is likely to access. Never prompt during gameplay.
Where to Go From Here
The Kids category is genuinely underserved. The higher barrier to entry keeps competition lower, and the parents who do download apps in this category tend to be highly engaged and loyal.
The fastest path to a Kids category submission: start with the parental gate implementation from this guide, work through each external link in your app one by one, and run your AdMob configuration through the checklist above. Most of the compliance work is mechanical once you know what to look for.
Kids apps are one of the few niches where craft and care in the product genuinely translate to business outcomes — parents notice, and they recommend apps to each other. That's worth building toward.
App Store Privacy Nutrition Labels for Kids Apps
Apple requires all apps to provide privacy nutrition labels in App Store Connect. For Kids category apps, this information receives heightened scrutiny from reviewers and parents alike.
The categories that are most often misconfigured in Kids apps:
Identifiers — Device ID: If you're using AdMob even with COPPA mode enabled, you may still be collecting the IDFV (identifier for vendor). This is technically allowed under COPPA when not used for tracking, but you must declare it and describe the usage accurately.
// Checking what identifiers your app collects at runtime
import { getUniqueId } from 'react-native-device-info';
// IDFV — allowed, but must be declared
// Used only for install attribution and fraud prevention
const vendorId = await getUniqueId(); // Returns IDFV on iOS
// What NOT to do in Kids apps:
// import { getAdvertisingId } from 'react-native-device-info';
// const adId = await getAdvertisingId(); // IDFA — prohibited in Kids categoryUsage Data — App interactions: Most analytics SDKs collect this. If you've removed Firebase Analytics and replaced it with device-local tracking, make sure your privacy label reflects the change. I've seen apps rejected because the privacy label still declared data collection that the code had already removed.
A practical workflow: after your final COPPA compliance pass, do one more sweep of the privacy label in App Store Connect and verify every declared data type against your actual code. If your code doesn't collect it, don't declare it. If it does, make sure it's declared with the correct usage reason.
Building a COPPA-Compliant Backend
If your kids app truly needs server-side functionality — shared leaderboards, teacher dashboards, progress sync across devices — you'll need a backend designed from the ground up with COPPA in mind.
The minimal COPPA-compliant backend architecture for a kids app looks like this:
// Supabase (or equivalent) — COPPA-compliant data schema
// Key principle: no direct child identity data without parental consent
// Table: app_sessions (anonymous, device-bound)
const sessionSchema = {
id: 'uuid', // Random UUID generated on install
device_hash: 'text', // Hashed device ID (irreversible)
// NOT stored: email, name, birthdate, IDFA, IP address (consider anonymization)
created_at: 'timestamp',
last_seen: 'timestamp',
};
// Table: game_progress (tied to anonymous session, not identity)
const progressSchema = {
session_id: 'uuid references app_sessions',
level: 'int',
score: 'int',
updated_at: 'timestamp',
// This schema collects NO personal information
};For the rare case where you genuinely need to identify users (a teacher dashboard where a parent wants to track their child's progress), you'll need:
- A verifiable parental consent mechanism (email confirmation to the parent, with unambiguous opt-in)
- A documented data deletion mechanism (parents can request deletion of all data associated with their child)
- A published privacy policy that explicitly addresses children's data
This is significantly more complex to implement and maintain. Unless the feature is core to your app's value proposition, I'd recommend architecting around it entirely.
Accessibility in Kids Apps
Accessibility often gets skipped in kids app development, but Apple's accessibility review is thorough — and accessible design often improves the experience for all children, not just those with specific needs.
VoiceOver Support
For educational apps, VoiceOver support is especially valuable and reviewers notice when it's absent.
// Accessible button implementation
<TouchableOpacity
style={kidsButtonStyle}
onPress={handlePress}
accessible={true}
accessibilityLabel="Next question" // What VoiceOver announces
accessibilityHint="Moves to the next math problem" // Additional context
accessibilityRole="button"
>
<Text>Next</Text>
</TouchableOpacity>
// For images used as decorative elements
<Image
source={require('./star.png')}
accessible={true}
accessibilityLabel="" // Empty string = decorative, VoiceOver will skip it
/>
// For images that convey meaning
<Image
source={require('./correct-answer.png')}
accessible={true}
accessibilityLabel="Correct! Well done" // VoiceOver will read this
/>Dynamic Type Support
// Support Dynamic Type for larger text sizes
import { Text, StyleSheet } from 'react-native';
const styles = StyleSheet.create({
questionText: {
fontSize: 24,
// allowFontScaling is true by default in React Native
// Don't disable it — many children benefit from larger system fonts
},
buttonLabel: {
fontSize: 18,
// If you need to cap scaling to prevent layout breakage:
// maxFontSizeMultiplier: 1.5,
},
});The investment in accessibility pays off in two ways: App Store reviewers check it, and parents of children with disabilities specifically seek out accessible apps. It's a real differentiator in a category where most apps skip it.
Testing Kids Apps Before Submission
The standard Rork Max testing workflow needs a few additions for Kids category submissions.
Setting Up a Child Account for Testing
Before submitting, test with a real child account in Apple's Family Sharing:
- In Settings → [your name] → Family Sharing, create a child account
- Enable Ask to Buy for that account
- Install your TestFlight build on a device logged in with the child account
- Walk through every user flow, paying attention to: external link behaviors, purchase prompts, and any path that tries to open the browser
This will catch issues that adult accounts miss — particularly around Ask to Buy flows and parental gate edge cases.
Automated Testing for COPPA Compliance
// Jest test — verify no external URLs are accessible without parental gate
// This is a simplified structural check, not a runtime check
import { ExternalLinkButton } from '../components/ExternalLinkButton';
import { render, fireEvent } from '@testing-library/react-native';
describe('ParentalGate compliance', () => {
it('shows parental gate before opening external URL', () => {
const { getByText, queryByText } = render(
<ExternalLinkButton url="https://support.example.com" label="Support" />
);
// Tap the link button
fireEvent.press(getByText('Support'));
// Parental gate should be visible before any external navigation
expect(queryByText('Parent or Guardian')).toBeTruthy();
// External URL should not have been opened
// (verify with a Linking mock)
});
it('opens URL only after correct parental gate answer', async () => {
// ... test the full flow with the correct math answer
});
});Manual Pre-Submission Checklist
Run through these before every Kids category submission:
- [ ] Every external link goes through a parental gate — test by tapping each one
- [ ] No interstitial ads are configured (check AdMob dashboard, not just code)
- [ ] AdMob
tagForChildDirectedTreatment: trueis verified in both code and dashboard - [ ] Privacy nutrition labels match what the code actually does
- [ ] App has been tested with a child Apple account (Ask to Buy scenario)
- [ ] No SDK is collecting IDFA or behavioral data
- [ ] Privacy policy explicitly covers children's data handling
- [ ] App icon and screenshots don't contain content that could be age-inappropriate
Long-Term Compliance Maintenance
COPPA compliance isn't a one-time checklist — it requires ongoing attention as your app evolves.
The areas that most commonly introduce compliance issues in updates:
Dependency updates: A React Native library you use might add new analytics or tracking features in a minor version update. Run npm audit regularly and review changelogs before updating dependencies in Kids apps.
New SDK integrations: Adding crash reporting, A/B testing, or any analytics tool requires a fresh COPPA compliance review. Treat any new third-party SDK as potentially non-compliant until proven otherwise.
Feature additions: Any new feature that introduces external links, social interactions, or data collection needs to go through the same compliance review as your initial launch. A "just add this link to the settings screen" change has triggered Kids category rejections.
# Run this before every Kids app release
# Check for known privacy-violating packages
npx @privacyguard/rn-audit --strict-children
# If that tool isn't available, manually check:
# 1. All packages that use device identifiers
# 2. All packages that make network requests
# 3. All packages that access location or cameraThe Kids category is genuinely rewarding to build for. The parents who find a quality app stick with it and recommend it to others in their community. The additional compliance work at the start pays dividends in a category where most developers give up before submitting.
Your first step today: take the parental gate code from this guide, identify every external link in your app, and wrap each one. That single change moves you significantly closer to a passing Kids category submission.