Google Play's 26 August deadline: 3 policy changes anonymous and random chat apps must ship

Summary. Google Play announced three linked policy expansions on 15 July 2026, all with the same compliance date on the Policy Deadlines page: 26 August 2026. Anonymous chat and random chat apps now fall under the Age-Restricted Content and Functionality policy, which forces them to use Play Console tooling to block minors. The Child Safety Standards policy now covers Anonymous Chat, Random Chat, Social and Dating apps, adding five self-certifications. The Families Policy Requirements now say social apps whose main focus is chatting with strangers or chatting anonymously "must not target children." Apple got there first: on 11 February 2026 it updated its App Store Review Guidelines so that random or anonymous chat apps "do not belong on the App Store and may be removed without notice." If you are only starting now, you have under three weeks, and the technical work is age signals, not copy edits. Third-party identity checks that establish an age band start at a published $0.80 per verification, and a separate Play deadline on 30 September 2026 requires every app to be registered in Play Console or risk global removal.

This guide covers exactly which apps are in scope under Google's "core functionality" test, what Restrict Minor Access actually does in Play Console, the five child-safety self-certifications and their wording, how Apple's February rules compare, the US state age-verification laws now feeding age signals into both stores, and a remediation plan sized to the days you have left.

The three changes, and the one date

All three items appear on Google's Policy Deadlines page with the same effective date. That matters operationally: there is no staggered rollout to hide behind.

The announcement gave developers "at least 30 days from July 15, 2026" to comply. Google published the changed policies as preview articles, each carrying an "(effective August 26, 2026)" note, so you can read the exact wording that will replace the live policy before it goes live. The current Age-Restricted Content article and the current Child Endangerment article stay in force until then.

The last two rows are not child-safety items, but they land in the same quarter and on the same engineering backlog. The app-registration deadline in particular is the one that removes apps globally, and we cover it in the Android developer verification September 2026 checklist.

Are you in scope? Google's core-functionality test

The Age-Restricted Content and Functionality preview lists four categories of app that "are required to use the Play Console functionality and tools to block minors":

1. "Apps that facilitate Real Money Gambling, Games, and Contests."

1. "Apps whose core functionality is to facilitate matchmaking or dating. Apps where matchmaking or dating is an incidental feature are not required to block minors, provided they implement appropriate age-gating safeguards to prevent minors from accessing those specific features."

1. "Apps whose core functionality is to facilitate randomly connecting users to spontaneously communicate with people they do not know."

1. "Apps whose core functionality is for users to communicate anonymously where the identity of one or more users is deliberately hidden."

Read categories three and four twice. Dating gets an explicit carve-out for incidental features: if matchmaking is a side feature you can age-gate that feature instead of blocking every minor from the app. Random connection and anonymity get no such carve-out in the text. The test is whether that behaviour is your core functionality, and Google decides what your core functionality is by looking at the product, not at your positioning.

Three product patterns that teams assume are safe and are not obviously safe:

• A community app whose growth loop is a "meet someone new" tab that pairs strangers at random. If that tab is what users open the app for, it is core.

• A support or confessions product where posts are pseudonymous and one side of every conversation is deliberately hidden. That is category four almost verbatim.

• A gaming app with an open voice channel that matches strangers. The matching may be for the game, but if the chat is spontaneous and between people who do not know each other, expect an argument you may lose.

If you genuinely sit on the line, the cheaper move is to restructure the feature before 26 August rather than to argue scope with review after an enforcement action. Apple's precedent is instructive here: its updated guidelines say these apps may be removed "without notice", which removes the appeal window teams normally rely on.

Restrict Minor Access: what you actually configure

"Play Console functionality and tools to block minors" resolves to one named feature on the target-audience page: Restrict Minor Access.

Google's description is specific about the mechanism and its limits:

"If your app is only suitable or designed for an adult audience, you can enable the Restrict Minor Access feature to restrict minors from your app. Minors are determined based on the age provided in their Google Account or when our systems indicate that a user may be under 18. When this feature is enabled, users determined to be under 18 will not be able to search for, download or purchase the app. Additionally, users who have already installed the app will continue to be able to use it, but will not be able to renew existing subscriptions or make new purchases."

Three consequences fall out of that paragraph, and product managers routinely miss all three.

It is a distribution control, not a runtime control. Existing installs keep working. If your risk model is "no minor should be in this chat pool", Restrict Minor Access does not deliver that on its own; it stops new acquisition from accounts Google believes are under 18. You still need in-app age assurance for the installed base.

It kills your subscription renewals for that cohort. Under-18 users who already have the app cannot renew existing subscriptions or make new purchases. If a meaningful share of your revenue sits in accounts Google reads as minors, that revenue stops on the day you flip the switch, not gradually. Model it before you flip it.

Turning it on costs you the 13-17 audience entirely. The configuration is blunt: "To enable the Restrict Minor Access feature, select 18 and over as your app's only target age group. Then on the same screen, verify and check the box to restrict users that Google has determined to be minors from your app." There is no partial setting.

The setting lives in Play Console under Policy, then App content, then "Target audience and content". The available age groups are 5 and under, 6-8, 9-12, 13-15, 16-17, and 18 and over; Google notes that 9-12 and below are "considered to include children in most locales" and that 13-15 and 16-17 "may be considered to include children in some locales". Review after a target-audience change can take "up to 7 days or longer", which is the real reason the 26 August date is tighter than it looks: submit on the 25th and you may not clear review in time.

One trap in the same document: the neutral age screen must let users enter month, day and year freely, and presetting the field to 13 is called out as an incorrect setup. Teams that "help" users by defaulting the year fail this.

The five Child Safety Standards self-certifications

The Child Safety Standards preview widens scope explicitly: "Google Play requires Anonymous Chat, Random Chat, Social, and Dating apps to comply with our Child Safety Standards policy." Note that Social and Dating are in that list, so this obligation reaches well past the two categories named in the announcement headline.

The enforcement language is not graduated. Google's text: apps that do not prohibit users from creating, uploading or distributing content that facilitates the exploitation or abuse of children "will be subject to immediate removal from Google Play."

Four of the five are self-certifications in Play Console. That wording lulls teams into treating this as a form. It is not. A self-certification is a representation you make to a distribution platform, and the artefacts behind it, the public standards page, the in-app report flow, the takedown runbook and the named contact, are what an enforcement review asks for.

Families: you may no longer target children

The Families Policy Requirements preview adds a line to the Social Apps and Features section:

"Social apps where the main focus of the app is to chat with people they do not know or to chat with people anonymously must not target children. Examples include: chat roulette style apps, dating apps, kids-focused open chat rooms, anonymous user style apps, 'blindfold' apps, etc."

If your Play Console target-audience selection includes any age band under 18 and your app matches that description, that configuration becomes non-compliant on 26 August. The fix is a target-audience change, which triggers the review window described above.

For social apps that legitimately include children, the surrounding requirements still bind and are worth restating because they are frequently under-built. Apps that include children in their target audience "must provide an in-app reminder to be safe online and to be aware of the real world risk of online interaction before allowing child users to exchange freeform media or information", and must "require adult action before allowing child users to exchange personal information". Where social features are optional, you must also give adults a way to manage them, "including, but not limited to, enabling/disabling the social feature or selecting different levels of functionality".

Google defines adult action as "a mechanism to verify that the user is not a child and does not encourage children to falsify their age", listing an adult PIN, password, birthdate, email verification, photo ID, credit card or SSN.

Apple moved in February: the cross-platform picture

Anyone shipping on both stores has already had this conversation once. Apple updated its App Store Review Guidelines on 11 February 2026 to name "random or anonymous chat" explicitly, alongside apps used primarily for pornographic content, bullying and physical threats, with the line that such apps "do not belong on the App Store and may be removed without notice."

The strategic read: Apple treats the design pattern as inherently unsafe, Google treats it as an adults-only product. A cross-platform app cannot satisfy both by shipping one change. If your iOS build survived February by narrowing the feature, the same narrowing usually solves the Play problem too, and it is the cheaper path.

The regulatory backdrop is real rather than theoretical. Both stores removed the anonymous video chat service OmeTV in Australia after action by the national regulator. Julie Inman Grant, Australia's eSafety Commissioner, said OmeTV "was a deeply risky app that paired adults and children together randomly for live video chat, and led to grooming and sexual exploitation of Australian children, as well as others globally, so it was appropriate for Apple and Google to take action under the codes and standards." Her second line explains why the category is being treated structurally rather than case by case: "We know that this service is popular with children and for this reason it's also popular with adults seeking to sexually prey on them."

The age-signal stack you now need

Blocking minors requires knowing who is a minor, and in 2026 that answer increasingly arrives from the operating system rather than from your own form.

Google's Play Age Signals API is in beta and returns age signals for eligible Texas users who created accounts after 28 May 2026, with default ranges of 0-12, 13-15, 16-17 and 18+, supported on Android 6.0 (API 23) and above. We walk through the integration in our Play Age Signals API integration guide.

Apple's equivalent came with its Texas compliance work: from 8 October 2025 Texas users creating a new Apple Account must confirm they are 18 or over, under-18 accounts must join Family Sharing, and parental consent is required for downloads, app purchases and in-app purchases. Developers read the age band through the Declared Age Range API, with additional APIs to trigger re-consent on a significant change and to let parents revoke consent.

The state laws driving those APIs are on staggered timelines, and several moved this year:

Across these acts the recurring developer obligations are consistent: ingest the age-category data the store provides, verify parental consent before download and in-app purchase, notify the store to refresh consent on a "significant change" such as adding an in-app purchase or advertising, assign statutory age ratings, and in Texas delete age and consent data immediately after use.

That last Texas clause deserves a line in your data-retention policy. An age signal you cached "for analytics" is a compliance problem in one state and a data-minimisation problem everywhere else.

What compliance costs

Blocking minors through Play Console is free. Knowing whether the installed base contains minors is not.

Published per-check prices for identity verification sit between $0.80 for Veriff's self-serve tier and $1.85 at Sumsub, with Onfido and Jumio quote-based, according to a May 2026 pricing breakdown compiled from vendor pricing pages and marketplace listings. Negotiated volume rates fall from there: the same breakdown models roughly $0.55 per check at Veriff and $1.20 at Sumsub once you are at 100,000 checks a year.

The headline price is not the cost. Sanctions screening is often an add-on at $0.10 to $0.30 per screen and address verification at $0.15 to $0.50. Manual review, which fires when automation cannot reach a confident decision, runs $2 to $5 per case at most providers. And at the 15 to 20 percent resubmission rate that is common on mobile capture, providers who bill resubmissions add 15 to 20 percent to the effective per-check cost. The same analysis puts the all-in figure "typically 30-50% higher than the headline per-check price."

Run that against your own funnel before you choose a tier. At 100,000 age checks a year, a $0.80 headline becomes roughly $1.04 to $1.20 all-in, which is $104,000 to $120,000 rather than the $80,000 on the pricing page. Design the funnel so a document check is the fallback, not the front door: the cheapest age-assurance architecture is the one where the operating-system signal answers most of your traffic and the paid check only handles what it cannot. The real cost of age assurance is the fallback rate, not the headline price.

A remediation plan for the days you have left

1. Decide scope in writing. Document, with screenshots, whether random connection or deliberate anonymity is your core functionality. If it is, you are in all three policies. Keep the memo; it is what you will send to review.

1. Book the Play Console review window now. Target-audience changes can take up to 7 days or longer. Working backwards from 26 August, changes submitted after roughly 18 August are a gamble.

1. Model the revenue hit of Restrict Minor Access. Pull the share of active subscriptions on accounts Google is likely to read as under 18. Those renewals stop.

1. Publish the CSAE standards page. A public URL in your terms of service or community guidelines, live before you self-certify.

1. Ship in-app reporting. Not a mailto link, an in-product flow that files a report and returns a reference to the user.

1. Write the CSAM takedown runbook and name the contact. One person, with authority, who can speak to your enforcement and review procedures, plus the reporting path to NCMEC or your regional authority.

1. Wire the age signals. Play Age Signals API on Android, Declared Age Range API on iOS, and a fallback age-assurance vendor for markets and accounts the OS does not cover.

1. Fix the neutral age screen. Free entry of month, day and year, with nothing prefilled.

1. Re-check the adjacent deadlines. App registration by 30 September 2026 and the READ_CALL_LOG change by 27 January 2027 sit in the same backlog; see our Play read call log verification migration guide and the wider July 2026 Play policy update breakdown.

Teams running the same review on the Apple side should read this next to our note on iOS 27 child-safety and screen-time features, and the broader delivery model sits in our enterprise mobile app development guide.

India-specific considerations

Play policies are global. An Indian studio publishing a chat product for users in Jakarta or São Paulo is bound by the 26 August date exactly like a US publisher, and the Restrict Minor Access setting is a store-wide configuration rather than a per-market one.

Two practical notes for Indian teams. First, the "relevant regional authority" clause in the CSAM reporting requirement is not self-executing: Google names NCMEC as an example and leaves the regional path to you, so identify and document your reporting route before you tick the self-certification box rather than after an incident. Second, Indian teams already building verifiable parental consent flows for the Digital Personal Data Protection Act 2023 will find substantial overlap with Google's "adult action" mechanisms, and it is worth building one consent service rather than two. Our DPDP Act engineering playbook for Indian startups covers that architecture, and if your fallback identity check leans on SMS OTP, the passkeys versus SMS OTP migration guide is the adjacent decision.

The blunt commercial read for Indian consumer apps: anonymous and random-pairing mechanics were cheap growth loops, and both major stores have now priced that growth at the cost of an adults-only rating plus a moderation function. If the loop only works with under-18 users in it, the loop is over.

FAQ

How eCorpIT can help

eCorpIT builds and remediates Android and iOS products for consumer platforms in India and abroad, and store-policy deadlines are a recurring part of that work. Our senior engineering teams run the scope assessment, wire the Play Age Signals and Declared Age Range integrations, build the in-app reporting and moderation flows the Child Safety Standards ask for, and produce the artefacts a policy review actually requests. As an ISO 27001:2022 certified, CMMI Level 5 organisation we design applications aligned with DPDP Act and child-safety requirements rather than bolting them on. If your chat product needs to clear 26 August, start at /contact-us/.

References

1. Google, Policy announcement: July 15, 2026, Play Console Help, retrieved 6 August 2026.

1. Google, Policy Deadlines, Play Console Help, retrieved 6 August 2026.

1. Google, Preview: Age-Restricted Content and Functionality, Play Console Help, effective 26 August 2026.

1. Google, Preview: Child Endangerment (Child Safety Standards), Play Console Help, effective 26 August 2026.

1. Google, Preview: Google Play Families Policies, Play Console Help, effective 26 August 2026.

1. Google, Manage target audience and app content settings, Play Console Help, retrieved 6 August 2026.

1. Google, Play Age Signals API overview, Android Developers, retrieved 6 August 2026.

1. Apple, Age assurance and parental consent requirements for Texas, Apple Developer News, 8 October 2025.

1. Wiley, Key Developments With State App Store Accountability Acts as Texas Act Takes Effect, retrieved 6 August 2026.

1. Rohit Singh, Apple Updates App Store Guidelines For Anonymous Chat Apps, MediaNama, 11 February 2026.

1. eSafety Commissioner, eSafety secures removal of video chat service used for child grooming, retrieved 6 August 2026.

1. Deep Identity Inc., KYC cost in 2026: real pricing breakdown per user, 27 May 2026.

_Last updated: 6 August 2026._