Age-assurance for apps in 2026: the Android and iOS compliance build

Summary. Age assurance stopped being optional for app makers in 2026. Apple applied Texas law SB 2420 to new accounts from June 4, 2026, added Utah from May 2026 and Louisiana from July 1, 2026, and now exposes age categories through its Declared Age Range API. Google's Play Age Signals API is live in Brazil, reaches Australia and Canada by mid-August 2026, and targets global coverage by the end of 2026. Both return a coarse age band, not a birth date: under 13, 13-15, 16-17, and 18 or older. These rules apply to every app available to residents of the covered regions, not merely apps aimed at children. Non-compliance is expensive: Australia's regime carries penalties into the tens of millions of dollars, and India's Digital Personal Data Protection Act allows fines up to ₹250 crore. This article explains what each platform requires, the region-by-region deadlines, the engineering that ships it, and how eCorpIT builds age assurance across Android and iOS as one compliance layer rather than two half-solutions.

What changed for apps in 2026

Through 2025 and 2026, a cluster of laws pushed age checks down to the app and the app store. In the United States, the App Store Accountability Acts led the way. Texas SB 2420 had a statutory date of January 1, 2026, and became enforceable after a court lifted an injunction, so Apple applied it to new Texas accounts from June 4, 2026 and Google began returning age signals for Texas accounts created after May 28, 2026. Utah followed in May 2026 and Louisiana on July 1, 2026. The common template asks developers to place their app in one of four audience bands, under 13, 13 to 15, 16 to 17, or 18 and older, and to obtain a parent or guardian's consent before a minor under 18 downloads the app or makes a purchase.

The pattern is not confined to the United States. Australia's under-16 social media rules and its Age-Restricted Material Codes accept methods such as facial age estimation, digital wallets, and photo identification, with penalties that reach tens of millions of dollars. The United Kingdom is moving the same way, tightening protections for under-16s under its Online Safety Act. The important detail for engineering teams: these obligations attach to all apps distributed to residents of the covered regions, even apps that are not directed at teens or children. If your app ships in these markets, the rules find you.

The two platform APIs you must implement

Both Apple and Google settled on the same privacy-preserving idea. Instead of collecting a date of birth, the platform tells your app which age band the user falls into, and you gate behaviour on that signal. The details differ enough that a single-platform implementation will not satisfy the other store.

On Apple platforms, the Declared Age Range API returns an age category set by a parent or guardian, with no birth date exposed to your app. Where a covered law applies, Apple also requires parental consent for downloads, In-App Purchases, and significant app changes. In its June 3, 2026 developer update, Apple stated that "new Apple Accounts in Texas are now subject to the law, which introduced age assurance requirements for app marketplaces and developers." Developers handle significant updates through the Significant Change API under the PermissionKit framework, surface the correct rating through a new age-rating property in StoreKit, and subscribe to an App Store server notification so the app learns when a parent revokes consent. Apple provides a sandbox to validate all of this before release.

On Android, the Google Play Age Signals API returns an age range rather than an exact age, using the default bands of 0-12, 13-15, 16-17, and 18 or older, with custom ranges available. Google is explicit about scope: the signal may support age-appropriate experiences, and it may not be used for advertising, marketing, user profiling, or analytics. The API is live in Brazil, expands to Australia and Canada by mid-August 2026, and is planned to reach additional markets through the end of 2026.

The two guides worth reading alongside this are our Google Play Age Signals API integration guide for the Android specifics and our App Store age-assurance readiness note for the iOS declaration flow.

The engineering work, honestly scoped

Reading a signal is the easy 10%. The compliance layer that actually ships is larger, and it is where teams underestimate the effort. On both platforms you retrieve the age band, then build the gating logic that changes app behaviour for each band: restricting features, adjusting defaults, or blocking a download or purchase until consent exists. On iOS you add the consent flow for under-18 users, wire the Significant Change API so a material update re-triggers consent, set the StoreKit age-rating property, and consume the server notification that tells you consent was revoked so you can downgrade access immediately. On Android you integrate the Play signal and keep it strictly out of any analytics or marketing path, which often means refactoring an existing data pipeline that quietly logged everything.

Then comes the part regulators care about most: data minimisation. You keep the age band only as long as you need it, avoid storing a derived birth date, and log consent events for audit without hoarding personal data. You test across regions, because the same build behaves differently for a Texas account, a Brazil account, and an account with no covered law. For teams shipping one product to both stores, doing this twice in two native codebases is wasteful. A shared cross-platform layer, whether in React Native or Flutter with thin native bridges for the platform APIs, keeps the compliance logic in one place. Our cross-platform app development approach and the broader enterprise mobile app development guide cover how we structure that.

Common mistakes teams make

The first is treating this as a children's-app problem. The laws apply to all apps distributed to residents of covered regions, so a productivity or finance app is in scope too. The second is over-collecting: asking for a birth date to be safe, which creates exactly the sensitive-data liability the platform APIs were designed to avoid. Take the band, gate on the band, store as little as possible. The third is forgetting the update path: on iOS a significant change re-triggers consent, and shipping a major feature without wiring the Significant Change API can put you out of compliance the day you release it. The fourth is leaking the age signal into analytics or ad SDKs, which Google's terms prohibit outright and which invites a privacy finding.

India and DPDP considerations

For Indian app makers and the global teams building here, two things matter. Products shipped to the United States, Australia, or the United Kingdom must meet each region's age rules regardless of where the code is written, so a Gurugram or Bengaluru team ships the same compliance layer a San Francisco team would. Closer to home, India's Digital Personal Data Protection Act, 2023 requires verifiable parental consent before processing the personal data of a child, which the Act defines as anyone under 18, and it emphasises data minimisation. Penalties under the Act reach up to ₹250 crore, which makes a disciplined, low-retention age-assurance design a commercial safeguard as much as a legal one. We build these flows aligned with DPDP requirements; our DPDP-ready app development service covers the consent and data-handling architecture in depth.

How eCorpIT builds age assurance

eCorpIT is a Gurugram-based technology organisation founded in 2021, assessed at CMMI Level 5, MSME certified, and ISO 27001:2022 certified, with partner relationships across AWS, Microsoft, and Google. Our senior-led mobile teams build for iOS with Swift, Android with Kotlin, and cross-platform with React Native and Flutter, which lets us implement the Declared Age Range API and the Play Age Signals API as one coherent compliance layer instead of two disconnected efforts. A typical engagement starts with a short assessment: which regions you ship to, which laws apply, and where your current data pipeline mishandles age or consent. From there we implement the platform APIs, the gating and consent flows, the data-minimisation and logging, and a region-aware test plan, then validate in each platform's sandbox before release. We design these systems aligned with DPDP and the applicable regional requirements rather than claiming certification against them.

FAQ

How eCorpIT can help

If your app ships to the United States, Australia, the United Kingdom, or India, age assurance is now part of shipping, and the platform deadlines are already live. eCorpIT's senior mobile teams build the Android and iOS compliance layer as one system: the Declared Age Range and Play Age Signals integrations, the consent and gating flows, and a data-minimisation design aligned with DPDP and each region's rules. We start with a short scoping assessment and give you a clear implementation plan. Talk to us through our contact page.

References

1. Update for apps distributed in Texas - Apple Developer news, June 3, 2026.

1. Age requirements for apps distributed in Brazil, Australia, Singapore, Utah, and Louisiana - Apple Developer news, 2026.

1. Declared Age Range API documentation - Apple Developer.

1. Age assurance frameworks Q&A - Apple Developer.

1. Play Age Signals overview - Android Developers.

1. Use Play Age Signals API (beta) - Android Developers.

1. Delivering safer, age-appropriate experiences on Google Play - Android Developers Blog, July 2026.

1. Google expands Play Age Signals API globally - Mobile Marketing Reads, 2026.

1. Apple updates Declared Age Range API for national and state-level age assurance laws - Biometric Update, February 2026.

1. State App Store Accountability Acts introduce new obligations for app developers - Wiley, 2026.

1. Children's privacy in 2026: Australia's under-16 ban and the US shift - Sidley Data Matters, February 2026.

1. Texas app age verification law allowed to go into effect - Route Fifty, May 2026.

1. DPDP Act compliance: parental consent and penalties in India - MyITManager, 2026.

_Last updated: August 1, 2026._