Skip to content
Blog

Your App Might Be Social Media Now — Apple's New Declaration

Since September 2026, App Store Connect requires every submission to answer Apple's social media questions. What the definition catches, and what yes costs.

Jorge Valbuena7 min read

A developer this year hit an unexplained HTTP 409 on an automated App Store Connect release and traced it to a field that didn’t exist a few months earlier: the social media section of the age rating questionnaire. It isn’t a warning banner you can dismiss during a hotfix — it’s a hard failure on a required answer, and the answer has consequences that outlive the submission.

What changed, and when

On July 9, 2026, Apple added social media questions to the age rating questionnaire in App Store Connect. Apple’s developer news post is the primary source.

Beginning in September 2026, answering those questions became mandatory — for new apps, for updates to existing apps, and for notarization submissions for alternative distribution in the EU. Note the wording: Apple published a month, not a day. A third-party guide has circulated a September 7 cutover date, but I could not find an Apple source for a day-precise deadline, so treat any specific date you see as unsourced.

The answers feed something concrete. iOS 27, iPadOS 27 and macOS 27 shipped on September 14, 2026 with a Social Media category in Time Allowances — the screen time controls a parent or guardian sets for an under-18 account. Your questionnaire response is what puts your app in that bucket.

This is the reversal worth internalising: the age rating questionnaire used to be a labelling exercise that affected a badge on your product page. It now configures how the operating system limits your app on a minor’s device.

Apple’s definition sweeps wider than the word does

Apple’s criterion covers apps that let users redistribute, amplify, or interact with user-generated content through a feed or similar discovery method. The phrase that does the damage is Apple’s own: this applies regardless of the app category.

Read that against your actual feature set rather than your positioning. A fitness app with a shared activity feed qualifies on its face. A recipe app with a comment thread under each recipe involves users interacting with user-generated content. A B2B tool with a community tab, a marketplace with public seller reviews surfaced in a browse view, a learning app with a discussion board — all of these have the shape Apple describes, and none of them are marketed as social networks.

The test is structural, not cultural. Is there user-generated content? Can other users find it through a feed or comparable discovery surface? Can they respond to it, boost it, or pass it along? Three yeses and your category name doesn’t protect you.

One structural hint in the other direction: the App Store Connect API exposes messagingAndChat as an attribute separate from socialMedia. That suggests Apple doesn’t treat private messaging as automatically social — which matters for marketplace and services apps where buyers and sellers talk one-to-one. It’s decent evidence, not proof, and I’d want Apple’s own field descriptions before betting a release on it.

It fails closed, in your pipeline

The reported failure mode is an HTTP 409 from App Store Connect on an automated submission, with nothing in the response that names the missing questionnaire answer. If your release process is a CI job triggered by a tag, that is a red build at the worst possible moment, debugged by whoever is on call.

So answer the questions deliberately, now, on a calm afternoon — not at 11pm during an incident hotfix. Log into App Store Connect, walk the questionnaire for each app in your portfolio, and make a decision you can defend.

More importantly, write the decision down somewhere your team will find it. “We answered no to the feed question because the activity list is visible only to accounts the user follows back” is the kind of reasoning that has to survive the person who made it leaving the company. The answer will be re-asked on every future submission and re-examined every time you ship a feature that touches user content.

What answering yes actually costs

Three things follow from a yes, and they are different in kind.

First, a rating floor. An app declared as social media carries a minimum age rating of 13+. If your current rating is lower and your growth model assumes younger users, that is a product decision, not a compliance checkbox.

Second, a Social Media content descriptor on your App Store product page. Visible to every prospective user and to every parent evaluating the app.

Third, and most consequential, your app lands in the Social Media Time Allowance bucket in iOS 27. When a guardian sets a limit on that category for an under-18 account, your app is spending from the same budget as every other app in the bucket. You are no longer competing for attention only against your category; you’re sharing a pool with whatever else got declared.

I’m deliberately not printing a default number of minutes for that allowance. I could not find a published figure from Apple or from reporting, and a founder should not plan a roadmap around a number somebody guessed. If this matters to your model, read it off a configured device running iOS 27, screenshot it, and date-stamp where it came from.

The under-13 exemption buys less than it looks like

Apple provides an escape hatch: if your app is age-restricted so that users under 13 cannot access it, the Social Media category treatment doesn’t apply to those users.

Read that sentence slowly. On my reading, it exempts you from the Social Media category for users under 13 — it does not appear to lift the 13+ rating floor, and it does not appear to change how 13-to-17-year-olds are treated. If that reading is right, the engineering work of building hard age gating buys you very little, because the teenagers are the cohort Time Allowances are mostly aimed at.

I’m flagging this as interpretation rather than fact. Before anyone funds an age-gating project on the strength of it, re-read Apple’s full bullet on the exemption and confirm the scope. This is the single most expensive thing to get wrong in the whole change.

Related and still open: Apple announced Time Allowances work in June 2026, and there is a Declared Age Range mechanism in the picture. Whether Apple requires Declared Age Range support to benefit from the exemption or merely recommends it is a meaningful difference — an entitlement request plus a shipped release on one hand, versus a database field you probably already have on the other. I don’t have the full text of that notice, so I won’t characterise it.

Deciding whether the feature earns the bucket

Once the cost is legible, the question stops being legal and starts being product. For each feature that pulls you into the social media declaration, ask what it returns.

A community tab that three percent of users open once a month is not worth a 13+ floor, a content descriptor, and a share of a throttled time budget. A comment thread that drives your retention curve probably is. The point of doing the audit deliberately is that you get to make that trade instead of inheriting it from a feature someone shipped in 2023.

There is a middle path worth costing: changing the discovery surface rather than removing the feature. Apple’s definition leans on “a feed or similar discovery method.” Content that exists but is reachable only through a direct link, a search the user initiates, or a one-to-one thread is a different structure from content pushed into a browsable feed. I won’t tell you that redesign gets you to a clean no — that’s a judgement call on your specific UI, and the questionnaire answer is yours to defend. But it’s a cheaper option than deletion and it should be on the table.

Whatever you conclude, document the reasoning alongside the answer. The declaration is now a recurring obligation attached to every submission, and the cheapest version of it is the one where nobody has to reconstruct the argument from scratch.

What I’d verify before acting

Three things in this post are verified against Apple’s own pages: the July 9, 2026 questionnaire change, the definition including the “regardless of the app category” clause, and the 13+ minimum with the Social Media descriptor. The iOS 27 ship date of September 14, 2026 is confirmed across MacRumors, 9to5Mac and AppleInsider.

Four things are not, and you should check them yourself before they become line items in a plan: the full text of Apple’s June 2026 Time Allowances notice and whether Declared Age Range is required or recommended; Apple’s own descriptions of the socialMedia and messagingAndChat API attributes; the shape of the Declared Age Range response type; and the default minutes on the Social Media allowance.

I’ve also seen the July 9 item described as having been restated on Apple’s developer news feed in mid-September 2026. What I actually found was the original July item still sitting on page one of the RSS feed. There may have been no September restatement at all.

The practical next step is small and takes an afternoon: open the questionnaire for each app you ship, answer it on purpose, and make sure your release pipeline never discovers this field for you.