Crosswalk pair
Apple App Store Kids Category and Google Play Families, control by control
7 canonical controls in Keel’s library satisfy clauses of both Apple App Store Kids Category and Google Play Families. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.
The overlap
What the two libraries have in common
Every figure here counts canonical controls in Keel’s library, not clauses of either standard. Each standard’s own authored count is on its framework page.
7
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
8
In Keel’s library for Apple App Store Kids Category
88% of them also map to Google Play Families.
9
In Keel’s library for Google Play Families
78% of them also map to Apple App Store Kids Category.
24
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
Apple App Store Kids Category 88%
7 controls of 8 in Keel’s library for Apple App Store Kids Category also map to Google Play Families.
-
7 controls of 9 in Keel’s library for Google Play Families also map to Apple App Store Kids Category.
The mapping
Controls that satisfy both
Each row is one control in Keel’s library and the clauses it answers on each side. Do the work once; both columns are then evidenced by the same artifacts.
| Canonical control | Apple App Store Kids Category clauses | Google Play Families clauses |
|---|---|---|
| Governance & Risk | ||
| App-store audience declarations & metadata The age and audience declarations made in each app store’s console, and the store-listing metadata, are accurate, kept current when the app changes, and consistent with how the app is actually built and marketed — including the data-safety and content-rating answers the store enforces against. | 2.3.8/for-kids-metadata | families/console/accurate-answers, families/social/rating-disclosure |
| Children’s online privacy programme A documented assessment of whether the service is directed to children under 13 or has a mixed audience, which operators collect through it, and the notice, consent, parental-rights, minimisation, security and retention duties that follow. Where the app ships through an app store, the same assessment carries that store’s audience determination — note Amazon treats under 16 as a child in the EU, Australia and Japan, so the age band recorded must be the widest one that applies. | 1.3/childrens-privacy-law | families/console/target-audience, families/requirements/legal-compliance |
| Data Protection & Privacy | ||
| Child-appropriate experience & parental gates Everything a child can reach in the app is age-appropriate, and links out of the app, purchasing opportunities and other adult-facing paths sit behind a parental gate or an equivalent barrier. Covers the store rules on content suitability, thin webview wrappers, augmented-reality safety warnings, and requirements that persist after a kids category is deselected. | 1.3/parental-gate, 1.3/persisting-requirements | families/requirements/app-content, families/requirements/app-functionality, families/requirements/ar-safety-warning, families/requirements/ar-device |
| Children’s advertising & monetisation controls Ads and monetisation reaching children or users of unknown age come only from sources the store permits, carry no interest-based targeting or remarketing, present age-appropriate creative, and follow the store’s format rules on ad walls, closeability, launch interstitials, multiple placements and virtual currency. Note the stores differ sharply here: Amazon bars its own advertising and affiliate programmes outright and parental consent does not lift that, while Google permits certified SDKs and Apple permits contextual advertising only from vendors with published kids policies including human creative review. | 1.3/third-party-advertising, 5.1.4(a)/no-third-party-analytics-advertising | families/ads/certified-sdk-only, families/ads/no-interest-based-or-remarketing, families/ads/child-appropriate-content, families/ads/legal-and-industry-standards, families/ads-format/no-deceptive-or-inadvertent-clicks, families/ads-format/no-ad-walls, families/ads-format/closeable-after-5-seconds, families/ads-format/no-launch-interstitial, families/ads-format/no-multiple-placements, families/ads-format/distinguishable-from-content, families/ads-format/no-manipulative-tactics, families/ads-format/no-forced-click-through, families/ads-format/virtual-currency-distinction |
| Children’s privacy notice (direct & online) Direct notices to parents for each circumstance that triggers one, and a prominent online children’s privacy notice carrying the operator details, collection, use, disclosure and retention information the rule requires. The same notice work satisfies the app stores’ requirements to publish a privacy policy and to disclose everything collected from children, including through SDKs. | 5.1.1(i), 5.1.4(b) | families/requirements/data-disclosure |
| Minimised collection in children’s activities Games, prize offerings and other activities aimed at children are reviewed so participation is never conditioned on disclosing more personal information than the activity reasonably needs, and the technical identifiers and location signals the app stores prohibit in children’s apps are neither collected nor transmitted. | 1.3/no-third-party-transfer | families/requirements/child-only-identifiers, families/requirements/ad-id-permission, families/requirements/mixed-identifiers, families/requirements/phone-number, families/requirements/child-only-location |
| Third-party Risk | ||
| Third-party SDK & API governance for children’s apps Every third-party SDK and API in a child-directed app is inventoried with what it collects and transmits, checked against terms that permit child-directed use, and either confirmed suitable for children or gated so it collects nothing from them. This is one inventory that answers Apple’s analytics limits, Google’s approved-SDK rules, Amazon’s child-suitability test and COPPA’s diligence duty at once. | 1.3/third-party-analytics | families/requirements/child-only-sdk, families/requirements/mixed-sdk, families/requirements/mixed-sdk-gating |
Beyond the pair
Where else this work counts
A framework is lit when a shared control above also maps to it. Unlit means none of them do — an absence, not a judgment about that standard.
Also reached by these 7 controls
- AI Governance Essentials
- Amazon Appstore Child-Directed Apps
- CIS Critical Security Controls
- COPPA
- ESG Essentials
- EU AI Act
- GDPR
- HIPAA
- ISO 9001
- ISO/IEC 27001
- ISO/IEC 42001
- NIST AI Risk Management Framework
- NIST Cybersecurity Framework
- NIST SP 800-171
- NIST SP 800-53
- PCI DSS
- SOC 2
- SOX (Sarbanes-Oxley) Section 404
- US Employment Law - Federal Baseline
Nearby pairs
- Apple App Store Kids Category and COPPA 6 shared controls
- Google Play Families and Amazon Appstore Child-Directed Apps 5 shared controls
- Google Play Families and COPPA 5 shared controls
- Apple App Store Kids Category and Amazon Appstore Child-Directed Apps 4 shared controls
- Apple App Store Kids Category and GDPR 2 shared controls
- Google Play Families and GDPR 1 shared control
The thesis
Why this is one project, not two
On a crosswalk-native model, Google Play Families mostly lights up controls you already built for Apple App Store Kids Category. You’re not re-uploading the same screenshot for a second audit. You apply the framework and see the genuine delta worth working. That’s the whole idea behind collect once, comply everywhere.
Next step
Add Google Play Families to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.