Building an app for children changes the rules more than teams expect, and the changes are not primarily about content. They are about data: what you may collect, from whom, with whose permission, and which third-party code you are allowed to include. Getting the category right at the start is much cheaper than discovering it at review.
Short answer
Both stores operate a separate track for apps aimed at children, with stricter requirements than the general catalogue. Apple's App Review Guidelines set out the Kids Category rules, and Google's Families policy does the same on the other platform. Underneath both sits actual law: in the United States, the Children's Online Privacy Protection Rule governs collection of personal information from children under 13. The store rules are stricter than the law in places, and compliance with one does not establish compliance with the other.
Who counts as a child, which is not one answer
The first source of confusion is that the age boundary depends on which rule you are looking at.
COPPA in the United States applies to children under 13. That is the boundary that drives the parental consent requirement for collecting personal information.
Store age bands do not match that exactly. Both platforms use age ranges for their children's programmes that are structured around content suitability and product design, and an app can sit in a children's programme while serving an audience that spans several of those bands.
Other jurisdictions draw the line differently, with several European countries setting the age of digital consent above 13, which means an app operating internationally has more than one boundary to respect.
The practical consequence is that "our app is for kids" is not a specification. The question to answer is which ages, in which countries, and what that implies for the strictest applicable rule, because you will generally have to build to the strictest one.
What actually changes when you enter the children's track
Advertising. Behavioural or interest-based advertising is prohibited or heavily restricted, and contextual advertising is what remains. This is frequently the change that breaks a business model, and it is better discovered during planning than after launch.
Analytics and tracking. Third-party analytics that build profiles are generally not permitted, and tracking identifiers are restricted. Apple's user privacy and data use guidance and Google's user data policy both apply, with additional constraints in the children's programmes.
Third-party SDKs. Every SDK in the build has to be permitted in a children's context, which means auditing your dependency list rather than only your own code. An SDK that collects an advertising identifier is a problem regardless of whether you use that data.
External links and purchases. Links out of the app, particularly to commerce or social features, are restricted, and purchase flows generally require a parental gate.
Data collection generally. Collecting personal information from a child requires verifiable parental consent under COPPA, and the store rules add their own requirements on top.
Social features. User-generated content, messaging and profile visibility carry additional obligations, and several products solve this by not having them in the children's version.
The mistake that causes most rejections
Declaring the app as not directed at children while the store disagrees.
Both stores form their own view from the app's content, presentation, and marketing rather than from your declaration alone. A colourful app with cartoon characters and simple mechanics will be assessed as appealing to children whether or not the developer intended that, and a mismatch between your declaration and their assessment produces a rejection that reads as confusing until you understand where it came from.
The related mistake is a mixed audience app that never decides. An app used by both children and adults has to handle the child case somehow: separate experiences, age gating that actually changes behaviour, or a single experience built to the stricter standard. Choosing none of those is the most common state and the least defensible one.
Age gating deserves specific care because it is easy to implement in a way that achieves nothing. A gate that asks for a birth year and then behaves identically regardless of the answer is not a control, and it does not change what rules apply to the data you collect afterwards.
Building it correctly from the start
Audit dependencies before writing features. The SDK list determines whether the children's track is even possible, and removing an analytics SDK after building on top of it is expensive.
Decide the data model early. An app that never collects personal information from children has a dramatically simpler compliance position than one that collects and then tries to obtain consent, and for many products the collection was never necessary.
Build the parental consent flow as a real flow, if you need one. Verifiable parental consent has specific requirements under COPPA, and a checkbox saying a parent agreed is not among the accepted methods.
Separate the child experience from the adult one in code, not only in the interface. If the same analytics call runs in both, the separation is cosmetic and a reviewer or a regulator will see the network traffic rather than the design intent.
Write down which rules you are building to. Teams routinely conflate a store programme with a legal obligation, and the document that distinguishes them is what makes the next decision consistent.
Checking the build rather than the intent
The gap between a compliant design and a compliant binary is where these programmes go wrong, because SDKs behave the way they are configured rather than the way they were meant to be.
Inspect the shipped artifact for what it contains and what it contacts. Advertising identifiers being read, analytics SDKs initialising before any consent step, permissions that a children's app has no reason to request, and network calls to endpoints that were supposed to be disabled in this build variant.
An automated pass over the artifact such as PTKD.com surfaces the inventory side of that: which SDKs are present, what permissions are declared, and whether the transport and storage configuration matches what you described. It will not judge whether your audience is children, which remains a product question, and it does answer the mechanical question of what the build actually does.
Then run the app with network inspection during a first launch, since the calls made before any user interaction are the ones that most often contradict a compliance declaration.
Google's developer content policy is the umbrella document on that platform, and the families programme requirements sit within it.
Mixed audience apps, which are the hard case
Most products that end up in this discussion are not children's apps. They are general-audience apps with some child users, and that is the situation with the least clear guidance.
The three workable designs are worth stating explicitly, because teams often drift between them without choosing.
Build everything to the stricter standard. One experience, no behavioural advertising, no profiling analytics, minimal data collection for everyone. This is simplest to operate and reason about, and it costs you whatever the restricted practices were earning.
Split the experience by verified age. Two paths, genuinely separated in code, with the child path constrained. This preserves the adult business model and doubles the surface you have to test, since every feature now has two behaviours.
Exclude children from the product. Age gating at signup, terms that state the minimum age, and enforcement that actually prevents use rather than displaying a notice. This is defensible when the product genuinely has no child audience, and it fails when the app's own presentation contradicts it.
What does not work is a general-audience app that collects and profiles freely while assuming its child users are somebody else's problem. Both stores and several regulators have moved against exactly that position.
Documenting the decision
Whichever path you choose, write down the reasoning, the age boundaries you settled on, and the jurisdictions you considered.
This matters more here than in most engineering decisions because the question recurs. A new SDK, a new market, a new feature with social elements: each of those reopens the analysis, and a team without a written baseline redoes it from scratch and reaches a different answer.
It also matters because these questions arrive from outside. A store review, a customer's procurement team or a regulator asking what your position is will get a much better answer from a document written calmly than from an engineer reconstructing it under pressure.
Keep it short. A page covering audience, age boundaries, what you collect, which SDKs are permitted and why, and what the child path does differently is enough, and it is the artifact that makes the next decision consistent with the last one.
The specific things to check before submitting
Five checks that catch most children's-track rejections, each of which takes minutes.
Confirm no advertising SDK in the build serves behavioural advertising, at its actual configuration rather than at its documented capability.
Confirm nothing reads an advertising identifier, including transitively through a dependency.
Confirm the first launch makes no analytics call before whatever consent or age step you built.
Confirm external links, especially to commerce or social platforms, are either removed or behind a parental gate.
Confirm your store privacy disclosure matches the network traffic a reviewer would see, since that is the comparison being made.
Where this intersects with the rest of your privacy work
The children's requirements are strict, and they are mostly a stricter version of practices that are worth having anyway.
Knowing every SDK in your build and what each one sends is required here and useful everywhere. Most teams cannot produce that list on request, and the exercise of producing it tends to find things nobody expected regardless of audience.
Making analytics conditional on a consent state rather than initialising at launch is required for children and is increasingly expected generally, particularly under European rules. Building it once for the child path and then reusing it is cheaper than building it twice.
Keeping crash reports and logs free of personal data matters more when the people involved are children, and the MASVS privacy category applies the same requirements to both cases.
Treating your store privacy disclosure as a description of observed behaviour rather than intended behaviour is the habit that prevents the mismatch that gets apps rejected, and it costs one network inspection per release.
So the work is rarely wasted even if the product later moves out of the children's track, which is worth saying to a team that sees the requirements as a tax.
What to take away
Children's programmes change your data practices and your dependency list far more than your content, which is the opposite of what most teams expect when they first look at the requirements.
Age boundaries differ between COPPA, the store programmes and other jurisdictions, so the specification is which ages in which countries rather than "for kids".
Both stores form their own view of whether your app appeals to children, drawn from content, presentation and marketing, and a declaration that contradicts their assessment produces a rejection that reads as arbitrary until you know where it came from.
Audit SDKs before building, because the dependency list determines whether the track is available at all, and because removing an analytics library after features depend on it is far more expensive than not adding it.
Decide explicitly between building everything to the stricter standard, splitting the experience by verified age, or genuinely excluding children, since drifting between those three is the least defensible position available.
And verify the built artifact rather than the design, since a disabled analytics SDK that still initialises on launch is what a reviewer or regulator will actually observe.
Most of this work also survives a change of audience. Knowing your SDK inventory, gating analytics on consent and keeping diagnostic data free of personal information are good practices generally, which makes the children's track a stricter application of things worth doing anyway rather than a separate compliance project.
