App Store social media declarations are mandatory from September 2026: your age-assurance checklist

Summary. Apple turned on the social media questions inside the App Store Connect age rating questionnaire on 9 July 2026. Answering is optional today and required from September 2026 for new apps, for every update, and for notarization for alternative distribution. Those answers drive Time Allowances, the parental control shipping in iOS 27, iPadOS 27 and macOS 27, and they add a Social Media content descriptor to your product page. The questionnaire is the easy part. Behind it sit four Apple APIs that went live when Texas SB 2420 took effect for new Apple Accounts on 4 June 2026, Google's Play Age Signals API which has returned signals for Brazil since 17 March 2026 and for Texas accounts created after 28 May 2026, and India's DPDP Rules, where Rule 10 demands verifiable parental consent for every user under 18 and the Act's Schedule caps penalties for breaching the children's provisions at ₹200 crore. Most teams we see have answered the questionnaire and shipped none of the rest.

What actually changed on 9 July 2026

Apple's developer news post that day is short and specific. The age rating questionnaire in App Store Connect now includes questions about your app's social media capabilities, and Apple gives a definition rather than leaving it to interpretation: a social media capability is "the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method."

Three consequences follow from answering yes.

Your app gets a new Social Media content descriptor on its App Store product page. Your app falls into the Social Media category for Time Allowances, the parental control Apple introduced on 8 June 2026 for iOS 27, iPadOS 27 and macOS 27 or later, which lets parents budget screen time by category rather than by individual app. And that categorisation happens regardless of the App Store category you picked, so a fitness app with a community feed lands in the Social Media bucket alongside the apps everyone thinks of as social.

The timing matters more than the questionnaire. Apple's words: "You can review and answer these questions starting today. As previously shared, beginning in September 2026, responses will be required when submitting new apps or updates to the App Store, or when submitting apps for notarization for alternative distribution."

Read that last clause twice. It covers alternative distribution as well as the App Store, so teams shipping through marketplaces in the EU or Brazil do not get a pass.

The under-13 switch most teams miss

There is one line in Apple's post that changes product decisions, not just paperwork:

"If you indicate that your app or game includes social media capabilities but they are disabled for anyone under 13, it won't be included in the Time Allowance category for Social Media for users under 13."

That is a lever. If your under-13 experience genuinely has no feed, no resharing and no discovery surface, and you can prove it in the build, your app stays outside a category parents will actively ration. If your under-13 experience quietly keeps a comment thread alive, you inherit the category and the descriptor.

The engineering work implied here is not a feature flag on a marketing page. It is a server-authoritative gate keyed to an age signal you receive from the platform, applied before any user-generated content renders, and testable. Teams that already built a proper age-band abstraction for iOS 27 parental controls have somewhere to hang it. Teams that hard-coded a boolean isKid two years ago do not.

The four Apple pieces behind the questionnaire

Apple published the full developer-side toolkit on 4 November 2025 alongside its plan for Texas SB 2420, and confirmed on 3 June 2026 that new Apple Accounts in Texas fell under the law from 4 June 2026 after a court lifted the injunction. Four separate mechanisms, four different jobs.

Two details in Apple's documentation get missed in most implementations.

The age categories Apple returns follow the Texas definition: under 13, 13-15, 16-17, or over 18. That is four bands, not a birthdate, and your product logic should never assume it can derive one from the other.

And Apple treats a change in your app's age rating as a significant change under Texas law, which is why the StoreKit property exists. Apple's guidance is blunt about who owns the judgement call: "It's the developer's responsibility to determine when there's a significant change to their app." There is no Apple-supplied list. If you ship a major feature and do not trigger consent, that is your exposure, not the platform's.

Sandbox testing for the Declared Age Range and Significant Change APIs has been available since the iOS 26.2 and iPadOS 26.2 betas, so there is no excuse for shipping this untested.

Google's path, and the three places it diverges from Apple's

Google's equivalent is the Play Age Signals API (beta). It started rolling out for eligible users in Brazil on 17 March 2026 under the Digital ECA requirements, and began returning signals for eligible Texas users who created accounts after 28 May 2026. Version 0.0.3 covers Texas and Brazil only; version 0.0.2 and higher remains supported for Texas responses.

The two platforms look similar from a distance and behave differently where it counts.

That middle row is the one to design around. On iOS the platform enforces. On Android you are the enforcement point, and if you ignore the revoked-approval status your app keeps serving a child whose parent said no.

Google is also explicit that none of this is a Play mandate: "Google Play doesn't mandate the use of these features... It is your responsibility to determine how these laws apply to your app, and whether and how to use these features to meet your obligations." That sentence is a liability transfer, and it is worth showing to whoever signs off your release process.

One more constraint that catches analytics teams. The Play Age Signals terms of service say you may use the data only to provide age-appropriate content and experiences in compliance with laws, and "may not use the Play Age Signals API for any other purpose including, but not limited to, advertising, marketing, user profiling, or analytics." Misuse can end in "termination of your API access and suspension or takedown of your apps from Google Play." Do not pipe age bands into your product analytics warehouse because it was convenient.

For teams already working through the Google Play July 2026 policy update on AI and user data, this is the same review cycle and the same owners.

Why every app is in scope, not just social apps

The reflex is to assume age assurance is a problem for social networks and games. Google's own guidance to developers does not read that way. Play Console Help says the Texas law and similar laws coming into effect in other US states "impose significant new requirements on many apps that may need to provide age appropriate experiences to users in these states," and tells developers it is their responsibility to review the laws and understand their obligations. Apple's commentary on the Texas law is more pointed still: Apple wrote that laws like SB 2420 "could undermine the privacy of all users by requiring the collection of sensitive personal information just to download an app – even those that simply provide weather forecasts or sports scores."

The cost argument was made early. Jeffrey Westling, writing for the American Action Forum where he was Director of Technology and Innovation Policy, put it this way in a 7 May 2025 analysis of the federal bill: "Forcing app stores to implement age verification, and to work with apps to provide additional information about those apps to consumers, increases the costs for the application stores. This, in turn, could raise costs for the app stores and applications, which will mean fewer apps and more fees for consumers."

Whatever you think of the policy, the engineering bill lands on your team.

The questionnaire has a history of hard deadlines

Apple has run this play before, and the pattern tells you how seriously to take September 2026. On 24 July 2025 Apple added the 13+, 16+ and 18+ ratings and told developers to answer the updated questions "by January 31, 2026, to avoid an interruption when submitting your app updates in App Store Connect." Apps that did not answer could not ship updates.

Other dated obligations are stacking up in the same queue:

The medical device one is worth a separate look if it applies to you: Apple's guidance says that if you have not declared your app's status by early 2027, you will no longer be able to submit app updates.

India-specific considerations: DPDP Rule 10 is stricter than either store

Indian product teams have a harder problem than their US counterparts, because the Indian threshold is 18, not 13.

Section 9(1) of the Digital Personal Data Protection Act, 2023 requires verifiable consent from a parent or lawful guardian before processing any personal data of a child, and the Act treats anyone under 18 as a child. Rule 10 of the DPDP Rules, 2025 spells out the diligence: a Data Fiduciary "shall adopt appropriate technical and organisational measures to ensure that verifiable consent of the parent is obtained," and must check that the person claiming to be the parent is an identifiable adult, either from reliable identity and age details it already holds, or from details provided voluntarily by the individual, or "through a virtual token mapped to such details, which is issued by an authorised entity." Rule 10 names Digital Locker service providers as one route.

The rule then walks through four illustrations covering whether the parent is already a registered user and whether the child or the parent initiates the account. Those four cases map almost directly onto four code paths, which is the most useful thing in the text for an engineering team.

The penalty side is set out in the Schedule to the Act, read with Section 33(1). Breach of the additional obligations in relation to children under Section 9 may extend to ₹200 crore. A failure of reasonable security safeguards under Section 8(5) may extend to ₹250 crore. These are ceilings the Data Protection Board can work within, not automatic fines, but they are large enough that the board-level conversation is different from the one about App Store paperwork.

What this means in practice: a platform age signal from Apple or Google tells you a user is 16-17, and that user is still a child under Indian law. The store signal is an input to your DPDP flow, not a substitute for it. Teams building this properly are keeping one internal age-and-consent state machine, fed by store signals in the US and Brazil and by a Rule 10 verifiable-consent flow in India, rather than two parallel implementations that disagree. The DPDP engineering playbook for Indian startups covers the consent-record side of that state machine in detail.

A practical sequence for the next eight weeks

The questionnaire deadline is September 2026. The work that makes your answer honest takes longer, so run it in this order.

1. Inventory every surface in your app where one user's content can reach another user. Comments, profiles, shared boards, activity feeds, leaderboards with free-text, direct messages, referral loops. Write the list down; the answer to Apple's question falls out of it.

1. Decide the under-13 question deliberately. If you can disable social capabilities for under-13s without gutting the product, do it and stay out of that Time Allowance category. If you cannot, answer yes and plan for the descriptor.

1. Implement the Declared Age Range API and read the age band at launch and at account creation, not deep inside a settings screen.

1. Write down what a significant change means for your app, get it approved by whoever carries legal risk, and wire the StoreKit age rating property to the Significant Change API.

1. Handle the App Store server notification for consent revocation server-side, and decide what your backend does with an account whose consent was withdrawn. Retention, not just access, is a decision here.

1. On Android, integrate Play Age Signals, take the revoked-approval status seriously because Play will not enforce it for you, and add age ratings to in-app products if you sell to Texas users.

1. Test both in sandbox. Apple's age assurance sandbox has been available since the iOS 26.2 betas; Play ships a fake manager for testing.

1. For India, build the Rule 10 verifiable-consent path against the four illustrations, and keep the consent artefacts where an audit can find them.

1. Answer the App Store Connect questionnaire, and re-answer it whenever the feature set moves.

Teams that already run a disciplined release process, of the kind needed for Android 17 target SDK migration, can absorb this inside two release trains. Teams shipping ad hoc will discover the deadline in an App Store Connect error message.

The real cost here is rarely the API integration. It is the product argument about which features under-18s keep.

FAQ

How eCorpIT can help

eCorp Information Technologies Private Limited is a Gurugram-based, CMMI Level 5 assessed technology consultancy founded in 2021, and our senior-led mobile teams build iOS, Android and cross-platform products for regulated categories where age, consent and data handling are part of the specification rather than an afterthought. We design applications aligned with DPDP Act requirements and with the age-assurance obligations Apple and Google have published, which in practice means one age-and-consent state machine, platform signals wired in properly on both stores, and consent artefacts your auditors can actually retrieve. If you are staring at a September 2026 questionnaire and are not sure your under-13 experience matches the answer you plan to give, that gap is a scoped piece of work, not a rewrite. Talk to us through /contact-us/ and we will start with an audit of your user-generated content surfaces and your current age handling, on iOS and Android together. Our iOS and Swift app development team and Android and Kotlin team work the same backlog.

References

1. Apple Developer, Age rating questionnaire now includes social media questions, 9 July 2026.

1. Apple Developer, Introducing Time Allowances, 8 June 2026.

1. Apple Developer, Update for Apps Distributed in Texas, 3 June 2026.

1. Apple Developer, Next steps for apps distributed in Texas, 4 November 2025.

1. Apple Developer, Declared Age Range API documentation.

1. Apple Developer, Significant Change API under PermissionKit.

1. Apple Developer, Age rating property type in StoreKit.

1. Apple Developer, App Store server notification types.

1. Apple Developer, Testing age assurance in sandbox.

1. Apple Developer, Upcoming SDK minimum requirements, 3 February 2026.

1. Apple Developer, Updated age ratings in App Store Connect, 24 July 2025.

1. Apple Developer, Upcoming changes to age ratings in Australia and Vietnam, 21 May 2026.

1. Apple Developer, Declaring regulated medical device status, 26 March 2026.

1. Google Play Console Help, Changes to Google Play for upcoming app store bills for users in applicable US states.

1. Android Developers, Play Age Signals overview.

1. DPDPA.com, Rule 10 of DPDP Rules 2025: Verifiable consent for processing of personal data of child.

1. DPDPA.com, The Schedule to the Digital Personal Data Protection Act, 2023.

1. Jeffrey Westling, American Action Forum, The App Store Accountability Act and Age-verification Mandates, 7 May 2025.

Last updated: 23 July 2026.