How do I make my app compliant with childrens privacy laws?

Children's privacy law is one of the areas where getting it wrong is expensive in a very specific way. The cost of non-compliance tends to run at nearly three times the cost of building things correctly from the start, according to Globalscape's Data Protection Regulations Study. But beyond the financial exposure, the damage to a brand that handles children's data carelessly is much harder to recover from than a regulatory fine. Parents remember. App stores remember. And the rules are only getting stricter.

Children's privacy is a design problem first and a legal problem second.

The question developers ask us most often is not "what are the laws", that information is publicly available, but "what does compliance actually require us to build differently?" That is a design question as much as a legal one, and the answer touches authentication flows, data retention policies, feature architecture, and the way a product communicates with its users before they are even inside the app.

The thing that catches teams out is the assumption that you can write a privacy policy after the fact and call it done. You cannot. Privacy for children has to be built in at the product level, and several of the decisions that matter most are ones you make before a single line of code is written.

What follows is a practical account of how to think through those decisions, drawn from the work we have done on products where child safety was a central concern rather than an afterthought.

Which laws apply to your app, and when they apply to you

The short answer is that multiple laws apply depending on where your users are, not where you are registered. A UK-based team building a wellness app that reaches American children falls under COPPA. The same app reaching European children falls under GDPR-K, which is the child-specific reading of the General Data Protection Regulation. If that app is marketed in the UK, the Age Appropriate Design Code, commonly called the Children's Code, also applies. These frameworks overlap but do not align neatly, and the strictest requirement in any overlapping area tends to be the one you design to.

The frameworks you are most likely to encounter

The trigger for most of these frameworks is whether your app is "directed to children" or "likely to be accessed by children." This is not purely a question of intent. A product aimed at adults can still be found to target children if its design, content, or marketing appeals to them. That determination is made by regulators looking at the product, not by reading your terms of service.

How do you know if your app is considered to target children?

Regulators use a cluster of signals to assess whether a product is directed at children, and your stated audience is only one of them. They look at the subject matter, the visual language, the characters, celebrities, or music featured, whether the language is simplified, and whether the advertising or marketing for the product runs in contexts children occupy. A fitness app with cartoon characters and a simplified interface will be treated as child-directed even if the terms of service state it is for adults only.

What raises the risk level

• Bright colours, simplified typography, or illustrated mascots associated with youth audiences
• Subject matter that has strong child appeal, such as gaming, crafts, or school-related content
• Advertising placed on platforms or media with significant child audiences
• Features that allow peer interaction, chat, or social connection
• Music, characters, or influencers whose primary following is under 16

We worked on a gifting product where the interface needed to serve parents creating wishlists for their children, and the content was entirely child-focused, but the product itself was not used by children. That distinction mattered legally, and it had to be sustained in every design and marketing decision throughout the product. The moment the interface started feeling like something a child would use directly, the legal exposure changed.

The safest position, if you are unsure, is to assume your product may be accessed by children and design accordingly. Regulators tend to find in favour of that assumption when the signals are ambiguous, and designing to the higher standard costs far less than a retrospective rebuild.

What data you are and are not permitted to collect from children

Under most frameworks, the category of data you are permitted to collect from children is narrow and the justification for collecting it must be clear. COPPA lists the types of information that require parental consent before collection, including full name, home address, email address, phone number, geolocation, photographs, audio recordings, and persistent identifiers such as device IDs used for behavioural tracking. The UK Children's Code adds that you should not collect more data than the minimum needed for the product to function, and that you should not use that data in ways children would not reasonably expect.

Collecting only what the product genuinely needs to function is good ethics and, simultaneously, the legal baseline.

Behavioural profiling of children for advertising purposes is prohibited under the UK Children's Code regardless of consent. Geolocation data requires specific justification and, where it is necessary, must be protected by design. On a fitness social app we worked on, we found that showing real-time user locations on a map created a genuine safety risk once we understood the demographic using the product. We redesigned the feature to show randomised location offsets rather than precise coordinates. Users could see a rough area and choose to share their exact location through an opt-in step after reviewing another user's profile. The core value of the feature, enough proximity information to know whether meeting up was feasible, remained intact.

The practical discipline here is to audit every data collection point in your product and ask what you actually do with each piece of data. If you cannot articulate a clear product function that requires it, you should not be collecting it from children.

Map every data collection point in your product before you start legal review. If you cannot state the specific product function that each piece of data serves, remove it before a regulator asks you to.

Parental consent: what it requires and how to build it properly

Under COPPA, parental consent must be verifiable, which means you cannot simply present a checkbox that says "I am a parent and I consent." The FTC requires a reasonable effort to ensure the person giving consent is actually the parent, and acceptable methods include signed consent forms submitted via email or post, credit card verification (as a proxy for adult status), video conferencing, and government ID checks. What does not qualify is an age gate that asks a child to enter a birth year, or a consent checkbox that any user could tick.

Building the consent flow correctly

1. Collect only the parent's contact information at the point of registration, before any child data is stored
2. Send a detailed notice explaining exactly what data will be collected and how it will be used
3. Give the parent a meaningful choice and wait for active confirmation before proceeding
4. Store a record of that consent with a timestamp and the method used
5. Give parents an ongoing route to review, update, or withdraw consent at any time

The design of the consent flow matters as much as the legal content. Parents are more likely to complete a consent process that is clear and honest about what data the product needs and why, and less likely to complete one that feels like it is hiding something.

On the gifting product we worked on, we found that contributors, such as grandparents arriving at the app via a family member's message, needed the onboarding to do much more than show them how to complete a transaction. They needed to be educated about what the product was, why it was safe, and how their family member's data was being handled. That kind of trust-building had to be built into the flow, not appended to it in a separate policy page.

Age verification and authentication: doing it without blocking legitimate users

Age verification is one of the hardest UX problems in child privacy compliance because any mechanism that genuinely works also creates friction for legitimate users. A simple self-reported birth year gate stops nobody, a determined ten-year-old will enter a false date without hesitation. A government ID check that actually confirms age is robust but will cause a significant proportion of legitimate adult users to abandon the flow entirely.

The answer for most products is a tiered model that matches the depth of verification to the level of risk in the action being taken. On the auction game product we worked on, we implemented exactly this approach. Watching or favouriting an auction required only a basic account, with a name and email address or phone number. Actually playing and winning real money required elevated verification, including age confirmation and a payment method on file.

We only asked for additional data at the exact moment the product functionality required it, never upfront as a blanket requirement. The user who was browsing owed us nothing until they decided to participate at a level where the legal obligation to verify them became real.

Design your verification tiers around the specific action that creates legal exposure, not around the moment of first registration. Asking for more than the current action requires will cost you users before you have demonstrated any value to them.

We always advise considering passive login mechanisms as part of this architecture, asking for a phone number or email address and sending a one-time code, rather than creating a password-based account. This removes password reset flows, reduces credential risk, and keeps authentication internal rather than routing user data through a third-party social login platform. For products that may be used by children, keeping authentication internal is particularly important because social login creates a data-sharing relationship with a third party that child privacy laws heavily scrutinise.

Privacy by default: what it means in practice at the feature level

Privacy by default is a specific legal requirement under the UK Children's Code. It means that the most privacy-protective settings must be the default settings, and that any move to a less private configuration requires an active choice by the user or their parent. This sounds straightforward until you apply it to specific features and realise how many products ship with defaults that serve the business rather than the user.

What privacy by default rules out

• Public profiles set to visible by default, requiring users to opt out of sharing
• Location services enabled unless the user explicitly opts in
• Personalised advertising switched on by default
• Social features like friend finding or activity feeds visible before the user chooses to turn them on
• Push notifications granted automatically on install

Applying this at the feature level means auditing each component of your product and asking which setting protects the user more, then making that the default. For social features, this usually means profiles are private until made public. For messaging, it means strangers cannot contact a user until that user opens the channel. For location, it means precise location is never shared without an explicit, per-session consent from the user.

The anonymous messaging app we worked on is a useful example here. The product's entire value proposition was built around anonymity, so privacy protection was structurally embedded in how the product worked. But we still had to build the back-end infrastructure to tie messages to authenticated accounts, even though users never saw that link. That back-end accountability, invisible to the user, was what made the product legally safe, because if a message constituted harassment, we could trace it.

When legal obligations conflict with each other

GDPR gives users the right to have their data deleted on request. Criminal investigation law in many jurisdictions requires that platforms retain data long enough for law enforcement to access it if needed. These two obligations pull in opposite directions, and a product that serves one perfectly will fail the other. This tension becomes most acute on products where children or vulnerable users may generate content, and where that content may later be the subject of a safeguarding investigation.

On the anonymous messaging app we worked on, we identified this conflict directly and resolved it by implementing a data retention window of around six months. This meant that even if a user deleted their account immediately after sending harassing or abusive messages, the data would not be wiped. If law enforcement needed to open an investigation during that window, the data would be available. After six months, the data would be removed in line with our GDPR obligations. The six-month window was not arbitrary, it reflected a considered judgement about how long a realistic investigation would take to be initiated.

The lesson here is that these conflicts rarely have clean solutions, but they do have defensible ones. A documented policy that explains the competing obligations and the reasoning behind the chosen approach is far better positioned with a regulator than one that simply ignores one framework in favour of the other. Get your legal and product teams in the same room early, and build the data architecture before you build the features it needs to support.

Designing data retention for child safety, not just compliance

Data retention policy is usually treated as a compliance document that sits in the privacy policy and is never looked at again. For products that children use, it deserves to be treated as an active product decision that shapes what you can and cannot do with your data infrastructure. How long you retain data affects what you can investigate, what you must delete, and what risk you carry if you experience a breach.

The general principle under most frameworks is that you retain data only for as long as necessary for the purpose it was collected. For a children's product, this means setting specific retention periods for each category of data and building automated deletion into the product rather than relying on manual processes. Account data, behavioural data, location history, and message logs each have different risk profiles and may warrant different retention periods.

Build automated data deletion into your product architecture from the start. A retention policy that depends on manual processes will drift, and drift creates regulatory exposure that a clean automated system does not.

The design challenge is that shorter retention windows reduce risk but also reduce your ability to investigate abuse. Products where safety is a concern need to hold that tension deliberately. On the messaging product, we held messages for six months specifically because the abuse risk was real and the investigation window needed to be meaningful. A photo-sharing product for children might reach a different conclusion, with a shorter retention window and no message content to preserve.

Location, messaging, and social features: where child privacy risk concentrates

Three feature categories carry the highest concentration of child privacy risk, and each requires a distinct design response. Location data, direct messaging, and social discovery features are the areas where harm to children is most likely to occur and where regulators focus their scrutiny most closely.

How risk clusters across feature types

Location presents the risk of physical harm when a child's precise whereabouts can be accessed by strangers. The solution is almost always to move from precise to approximate, to require explicit opt-in for any location sharing, and to avoid persistent location storage. On the fitness social app we worked on, we moved from a real-time map view to randomised location offsets, letting users indicate roughly where they were without exposing their exact address. Users could then review each other's profiles and choose to share their precise location only once they had decided the other person was trustworthy.

Direct messaging between children, or between children and adults, requires robust safeguarding controls. This means moderation infrastructure, keyword filtering, the ability to report and block, and a process for escalating serious concerns. A product that enables children to message strangers without any of this infrastructure in place is legally and ethically indefensible regardless of how the terms of service are worded.

Social discovery features, friend finders, nearby users, suggested connections, are particularly risky because they are designed to surface strangers to children. Under the UK Children's Code, geolocation-based social discovery is effectively prohibited for children. Any feature that surfaces unknown users to a child needs careful justification and robust safeguarding controls before it can be considered compliant.

How upfront registration and app store presence interact when you cannot collect data inside the app

When a product requires upfront registration before any product value is delivered, the App Store listing has to do work that the product itself cannot do. Users arrive at the registration screen with no prior experience of what the product offers, and the only material they have seen is the App Store page. If that page has not communicated the product's value clearly, you will lose a large proportion of users before they complete registration, and you will have no way to recover them inside the product.

On the anonymous messaging app we worked on, authentication had to go right at the front of the experience because the legal requirement to tie messages to authenticated accounts meant we could not allow users inside the product before we knew who they were. This was not a product preference, it was driven entirely by legal and safety requirements. The consequence was that we had to invest heavily in the App Store presence, treating the listing, screenshots, and preview content as the first act of onboarding rather than as marketing copy.

Every piece of value the product would normally drip-feed to a user during their first few sessions had to be communicated before they even opened the app. The screenshots could not just show the interface, they had to tell the story of what the product was for, why it was safe, and what a user would get from it. According to Pye Tait Consulting's 2023 App Developer Survey, only 16% of app developers are aware of the UK Government's Code of Practice for app store operators and developers, which means the majority of developers are not even thinking about the App Store as a compliance environment, let alone as an onboarding surface.

The discipline is to audit your App Store presence as if it were the first screen of your product, because for users who arrive at registration with no prior context, it is.

What you cannot fix with a policy update after launch

A privacy policy update can change what you say about your data practices. It cannot change your data architecture, your authentication model, your retention infrastructure, or the features you have already shipped. The decisions that are hardest to undo after launch are the ones that matter most for child privacy compliance, and they are all made before the first user opens the product.

Decisions that require rebuilding, not editing

• Whether authentication is required before data collection begins
• Whether location data is stored as precise coordinates or approximate offsets
• Whether direct messaging exists between users who have not verified their identity
• Whether behavioural data is being passed to third-party analytics or advertising platforms
• Whether social discovery features surface strangers to users without safeguarding controls

The performance coaching survey app we worked on is a useful illustration of how much infrastructure is required to make data collection legally robust. We built a multi-layered security model to prevent fraudulent responses without using a traditional API. Authenticated coach accounts were the only ones that could create surveys. Each QR code contained a unique key granting read access to only that specific survey. When a respondent accessed the URL, we used a cookie and device fingerprinting to restrict write access to one submission per device per survey. This prevented duplicate responses and ensured respondents could not read other participants' answers. None of that could have been bolted on after launch. It was the architecture.

The teams that find themselves doing expensive retrofits are almost always the ones who treated compliance as a documentation task rather than a design constraint. Building to the constraint from the start is significantly less expensive and produces a better product, not because it is easier, but because it forces clarity about what the product actually needs from its users and why.

Conclusion

Child privacy compliance is not a separate workstream that runs alongside product development. It shapes what you can build, how you authenticate users, what data you store and for how long, which features you ship and which you redesign before launch. The teams that treat it as a documentation task tend to discover, expensively, that the things regulators care about most are not things you can fix with a revised policy.

What we have found across the products we have worked on is that building to child privacy standards from the start produces cleaner architecture generally. The discipline of collecting only what you genuinely need, retaining it only for as long as you can justify, and building safeguarding into features rather than around them, makes a better product for all users, not just children.

The legal frameworks are complex and they do not always agree with each other. But the underlying principle is consistent across all of them. A product that treats children's data with care, that gives users and their parents genuine control, and that does not use design techniques to pressure children into sharing more than they intend to, is one that will hold up to scrutiny. A product that relies on opaque defaults, minimal consent, and a privacy policy nobody reads will not.

If you are building a product where children may be among your users, the right time to work through these decisions is before your first design sprint, not before your App Store submission. Let's talk about your product's compliance architecture before the decisions that are hardest to undo get made.

Frequently Asked Questions