Apple's new age-rating question is mandatory this month. Answering "no" isn't the end of it.
Since July, App Store Connect asks whether your app has social media capabilities. From September, you can't submit a new app or an update without answering.
Apple posted on 9 July that the age rating questionnaire now includes questions about social media capabilities, and that "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." September ends tomorrow, so if you have a build in flight, this is the week you meet it.
Apple's definition is narrow: the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method. If that is not your app, you answer no and move on. Murror has no feed of other people's content, so ours is a plain no. The part worth understanding is who gets caught by the word "similar." A comments section, a community tab, a public profile page or a shared-collections screen can all be read as a discovery method. Before you tick no, open your own app and look for any place where one user's content reaches another user.
The second thing is that this sits on top of a larger change. Texas SB 2420 was enjoined in December 2025, Apple paused its plans, and on 3 June Apple said the injunction had been lifted and that from 4 June new Apple Accounts in Texas are subject to age assurance and parental consent. Apple's developer pages point to the Declared Age Range API as the way to read a user's age category, and describe further APIs, for re-obtaining parental consent after significant changes and for handling consent revocation, that were still to come when I read them. Check Apple's age assurance Q&A for the current state rather than trusting my summary, because this has already moved twice.
What I'm doing, and what I'd do in any small app: answer the questionnaire from the product as it actually is, not as it was on the day I first filled it in. Write down the answer and the reason, so the next person who adds a sharing feature knows it changes the answer. And treat the age signal as a design question rather than a compliance chore. For an app that handles emotional content, knowing whether a user is a minor is information we would want to have anyway.
The cheap failure here is a rejected submission on release day. The expensive one is shipping a small "share" button in a point release and never revisiting a declaration you made a year ago.
Replies
Writing down why you answered "no" is smart. I can totally see myself forgetting the reasoning six months later.
@grace_gui02 Thanks Grace. That's exactly why I write the reason next to the answer: the "no" is easy to remember, the why is what disappears. A one-line note in the release checklist has saved me more than once.
That "one user's content reaches another user" way of looking at it makes the Apple wording much easier to understand.
@nathan_holdstein36 Glad it helped, Nathan. Apple's wording is broad enough that the only reliable test I've found is to trace it from the user's side: can anything one person writes or uploads ever end up in front of another person? If yes, the answer needs a second look.
The comments example got me. Easy to add something like that and forget it changes the declaration.
@sathesharayu12 Exactly, Sharayu. It's rarely the big feature that trips people, it's the small point release. We now treat any new screen where one user's content can reach another as a checklist item before it ships, not something we notice afterwards.
I hadn't really thought of the age signal as useful product information too, not just an Apple requirement.
@bouzadamanuel0934 That's how I try to see it too, Manuel. For an app that deals with emotional content, knowing whether someone is a minor changes what a responsible product should say and how it should say it. Apple is just forcing the question earlier than we might have asked it ourselves.
The reminder to revisit the ans when the product changes is probabaly the bit I'd actually write down.
@david_murray11 Agreed, David. It's the part that decays fastest, because the questionnaire answer sits in App Store Connect where nobody looks at it again. Putting the reason in the repo or the release checklist, where the next person adding a feature will actually see it, is what keeps it honest.