Children’s privacy

Do I need a parental gate, an age screen, or parental consent?

Probably more than one of them, because they are three different mechanisms doing three different jobs and satisfying one does not satisfy the others. A parental gate is an Apple requirement: a Kids Category app must put links out of the app, purchasing opportunities and other distractions behind one, and Apple specifies the gate itself as an adult-level task that must be completed before the user may continue. A neutral age screen is what Google Play and Amazon ask for, and its job is different — it establishes the age signal that lets the identifier, SDK and ads rules be applied to the right users. Verifiable parental consent is what COPPA requires before collecting a child’s personal information, and it is a legal mechanism with recognised methods. Apple says directly that a parental gate is generally not the verifiable parental consent those privacy statutes require.

Three mechanisms, three purposes

Teams building a kids app tend to design one “are you a grown-up?” interaction and hope it discharges everything. It does not, because the three requirements come from three regimes and are aimed at three different problems. Apple’s parental gate is a user-experience barrier: it stops a child taking an action their parent would not want them to take. Google’s and Amazon’s neutral age screen is a classification device: it tells your app which rule set applies to this user. COPPA’s verifiable parental consent is a legal permission: it is what makes collecting a child’s personal information lawful. Build them as one component if the UX allows, but evidence them as three, because a reviewer or a regulator is asking three separate questions.

Apple: where a parental gate is required

A Kids Category app must not put links that leave the app, purchasing opportunities, or other distractions in front of a child. Where the app offers them at all, they belong in a designated area reached only through a parental gate. Apple’s guidance on designing safe and age-appropriate experiences names the two triggers concretely: before an in-app purchase, and before a link out to content outside the app — external websites, social networks, or other apps. The stated purpose is to stop a child doing these things without their parent’s knowledge. Note what this is not about: it is not a data-collection rule, and clearing it says nothing about your privacy posture.

Apple: what a parental gate has to be

The gate carries its own specification, which is why Keel scores it as a separate duty from where a gate is required. Apple defines a parental gate as an adult-level task that must be completed before the user may continue. A confirmation dialog a young child can tap through is a gate in placement but not in mechanism, and does not satisfy it. Apple additionally suggests that apps intended for pre-literate children consider a voiceover prompt so the child understands a parent is needed — Apple writes “consider”, so that is advice rather than a duty, and Keel records it as advice. When you evidence this, evidence the mechanism as well as the placement.

The sentence that matters most: a gate is not consent

Apple states the distinction itself, and it is the single most useful thing on this page: a parental gate as required by the Kids Category is generally not the same thing as the verifiable parental consent that children’s privacy statutes require, so satisfying one does not satisfy the other. Apple makes that point in the context of a broader duty — a privacy policy and compliance with every applicable children’s privacy statute are required both of apps in the Kids Category and of apps that collect, transmit, or merely have the capability to share personal information from a minor. Apple’s examples of that information are broad enough that an in-app chat feature alone brings an app inside the duty: name, address, email, location, photos, videos, drawings, the ability to chat, other personal data, and persistent identifiers used in combination with any of those.

Google Play and Amazon: the neutral age screen and what it is for

Neither Google nor Amazon asks for a parental gate in Apple’s sense. What they ask for is age screening, and the reason is mechanical. Google’s mixed-audience identifier rule bans transmitting the advertising identifier and a list of device identifiers from children or from users whose age is unknown, so without an age signal every user has to be treated as a child. Its mixed-audience SDK rule allows an unapproved SDK only behind a neutral age screen or where it is implemented so that it results in no collection of data from children. Its ads rule requires a mixed-audience app to put age screening measures in place and ensure ads shown to children come exclusively from Families self-certified ads SDK versions. Google’s own example of the measure is a neutral age screen, and because the same screen underpins all three, one implementation is usually the evidence for all three. Amazon takes the same approach for components: where an app is directed at both children and adults, a non-child-suitable SDK may be used only if reasonable measures ensure it collects personal information from adult users alone — with a neutral age screen as Amazon’s example — and the duty is about the outcome, so the evidence is the gating implementation together with a check that the SDK is genuinely inert on the child path.

COPPA: verifiable parental consent, and the exceptions

COPPA requires an operator to obtain verifiable parental consent before any collection, use or disclosure of a child’s personal information, and the Rule sets out the recognised methods that satisfy it rather than leaving it to be asserted. Amazon summarises the same duty in its own policy and gives examples of what verifiable means — a completed consent form, or a check of the parent’s government-issued identification. The Rule also defines a set of exceptions where prior consent is not required, including the narrow persistent-identifier exception for supporting the internal operations of the service. Two things follow for design. Consent is a legal mechanism with defined methods, not a checkbox. And the exceptions are the place to look before building consent flows you may not need — but each carries its own conditions and, in several cases, its own notice duty.

Asking for a birthdate is itself constrained

Apple permits an app to ask for a birthdate and for parental contact information only in order to comply with children’s privacy statutes such as COPPA and the GDPR — not as a general profiling or marketing exercise. And whatever age the person turns out to be, the app must still offer some useful functionality or entertainment value: an age gate that leaves a user with nothing does not satisfy this. That constrains a common pattern, where an age screen doubles as a lead-capture step or dead-ends under-13 users at a blank wall. Design the screen so that both branches lead somewhere.

Deselecting the Kids Category does not undo the obligations

Once customers have come to expect an app to meet the Kids Category requirements, subsequent updates must continue to meet them — and Apple states that this remains true even if the developer later deselects the category. So removing the category is not a route out of the parental-gate duty or the others that travel with it, which matters for any plan to de-scope by unticking the box. Apple separately states that apps intended primarily for kids should not include third-party analytics or third-party advertising whether or not they sit in the Kids Category, which points the same way: the category is a trigger, not the whole scope.

How to evidence all three without building three things

A single well-designed flow can carry all three duties, provided you record which part of it answers which. The adult-level task satisfies Apple’s gate specification and can sit in front of purchases and outbound links. A neutral age screen produces the age signal Google and Amazon need, and should be neutral in the strict sense — not prompting the user toward an answer. Where a child is identified and you intend to collect personal information, a verifiable parental consent step satisfies COPPA, using one of the Rule’s recognised methods. Keep the three pieces of evidence separate in your records even where the code is shared, because they will be assessed separately. This page is a control-mapping aid, not legal advice, and no page can promise a store review outcome.

FAQ