When does the new age rating questionnaire become required?

Apple says responses will be required beginning in September 2026 for new apps and app updates submitted to the App Store. The same requirement also applies when submitting apps for notarization for alternative distribution. Apple has not published a single universal calendar date on the referenced announcement, so treat September as the deadline month and complete your review before your planned submission window.

Do comments or community features make an app social media?

Not automatically. The key question is whether your app redistributes, amplifies, or enables interaction with user-generated content through a feed or similar discovery system. Comments, likes, reposts, recommendations, public search, and ranking can support a social media classification when they make content visible to many users. A private workspace may not meet the same definition.

How should an app answer when social features are blocked for children under 13?

Choose the under-13 restriction path only when the restriction is implemented in the product, not merely stated in App Store Connect. The app must check an age range before enabling social features and deliver only age-appropriate user-generated content. Test the blocked path, the allowed path, consent changes, and parent-controlled cases before submission.

Can the new answers change an app's review outcome or existing rating?

They can affect the age rating information Apple generates and whether the app is identified with a Social Media descriptor. They also help determine whether the app appears in the Social Media category for Time Allowances. Do not assume that every answer produces a fixed rating change. Recheck the generated result in App Store Connect and compare it with real app behavior.

What is the right way to test Declared Age Range API behavior?

Enable the Declared Age Range capability and entitlement in Xcode, then use Apple’s age assurance sandbox scenarios on a supported test device. Verify under-13, teen, adult, consent-approved, consent-revoked, and unavailable-response branches. Record returned lower and upper bounds, declaration status, feature access, and server-side handling. The API returns an age range, not a precise birth date.

App Store Age Rating Questionnaire 2026: September Checklist

📌 If you submit or update an Apple platform app from September 2026, do not choose age rating answers from your store category or product name. Inspect how your app distributes, amplifies, and moderates user-generated content. This guide gives you scenario-based decisions, age-gate test cases, cross-platform checks, and a final three-part submission checklist.

Symptom: Your App Store Age Rating Questionnaire 2026 answer does not match what users can actually do in the app.

Fastest fix: inspect real content distribution and interaction paths first, then complete the questionnaire, age-gate code, and submission records before September 2026.

This guide is for independent developers, product owners, App Store operations teams, and mobile engineering teams preparing a new version or update after September 2026. It is especially relevant if your app includes comments, community posts, public feeds, recommendations, parental controls, or user-generated content.

Last updated August 14, 2026. Facts checked against Apple Developer News, App Store Connect Help, age rating definitions, Declared Age Range API documentation, and Apple’s age assurance sandbox guidance.

Start with the feature path, not the app category

The App Store category is not the deciding signal for the new social media question. Apple says the Time Allowances Social Media category is based on social media capabilities, regardless of the category selected in App Store Connect. A productivity app with a public community feed can therefore require a different review from a private productivity tool. Read Apple’s announcement about the new social media questions before assigning ownership internally.

Use this three-path decision:

No social distribution or amplification: If the app is a local utility, one-way reader, private workspace, calculator, editor, or personal dashboard with no public interaction, answer from the actual limited feature set. Still inspect hidden and legacy paths.
Public user-generated content with discovery or interaction: If users can publish content that is redistributed, ranked, recommended, commented on, liked, reposted, searched publicly, or amplified through a feed, treat the social media question as a product behavior decision.
Social features disabled for users under 13: Use this path only if the app enforces the restriction with an age-range check before social features become available. A declaration in metadata is not a substitute for code.

Apple defines social media capability around the redistribution, amplification, or interaction of user-generated content through a social feed or similar discovery method. The definition includes activities such as reposting, liking, commenting, reacting, and making content more visible through feeds, communities, search, or sharing tools. (Apple’s age rating values and definitions)

Do not use the product name, marketing category, or intended audience as your evidence. Use the online behavior that the submitted build actually exposes.

Remove false negatives from tool and content apps

A tool without a visible feed can still contain a social path. Before choosing a “no social media capability” answer, review these areas:

Public comments attached to files, templates, projects, or listings.
User profiles that expose posts, reviews, images, or activity.
Public activity streams or “recently used” content.
Search results that surface content created by other users.
Recommendation, ranking, trending, or discovery modules.
Share links that make user content available to a broad audience.
Likes, reactions, reposts, follows, mentions, or replies.
Third-party community SDKs enabled only for selected accounts.
Feature flags or staged rollouts that differ by region.
Old API routes still reachable from an earlier version.

A private workspace is not automatically social media. The relevant distinction is whether content remains private to an individual or controlled group, or whether the app makes that content discoverable and interactive at broader scale.

Keep an internal evidence packet

Your submission owner should preserve four items:

A feature inventory showing every screen that can display user-generated content.
Product screenshots or screen recordings from the release candidate.
A version note identifying disabled, region-limited, beta, or account-gated features.
A short mapping from each questionnaire answer to a real product behavior.

This packet is useful when product, engineering, and review operations disagree. It also prevents a common failure: the operations team fills in the form from a launch brief while the binary still contains a public comment or recommendation path.

The Apple age rating values and definitions should be your reference for the exact capability wording, not an old internal spreadsheet.

User-generated content and social media capability are related, but they are not identical decisions.

An app may allow a user to create a private note, save a private project, or upload content visible only to a limited workspace. That does not necessarily create a broad discovery system.

The risk increases when the app adds a mechanism that spreads or prioritizes that content:

A public feed.
A community search page.
A “recommended for you” stream.
A ranking algorithm.
User reactions or comments.
Reposting or sharing into other public areas.
A profile or activity page visible to many users.

This distinction matters because selecting social media capability can affect the product’s displayed age information and its treatment in Time Allowances. Apple states that apps with social media capabilities will display a Social Media content descriptor on the App Store product page. Apple also states that an app whose social capabilities are disabled for everyone under 13 will not be included in the Social Media Time Allowance category for those users. (Apple’s Time Allowances announcement)

That is not the same as the app’s primary App Store discovery category. “Social Media” in Time Allowances is a usage-control classification. It should not be confused with selecting a Social Networking category for store discovery.

A common product case

Suppose your app is an educational drawing tool. Users can create drawings privately, but a community tab lets them publish drawings, browse a public feed, like other users’ work, and comment.

The drawing tool is not the deciding feature. The public feed and interaction model are. If the community tab is enabled in the submitted build, your answer must reflect that path even if the app is marketed as Education or Graphics.

If the community tab is disabled for users under 13, you need evidence that the restriction runs before the feed, comments, likes, and public search become available. Hiding one button is not enough if the same API data remains accessible through a deep link or cached screen.

Implement the under-13 path as a real control

Apple’s “Social Media Disabled for Users Under 13” definition requires an age-range check before enabling social media features. The Declared Age Range API is designed to request an age range from the person using the device. It does not give your app a precise birthday by default.

To use it, Apple requires the com.apple.developer.declared-age-range entitlement. You enable the Declared Age Range capability on the target in Xcode, request the person’s age range, and then apply your product rules. Apple notes that the information is based on an age range declared by the user or parent or guardian, and that it may be confirmed through another method. Your team remains responsible for applicable legal and regulatory requirements. (Declared Age Range API documentation)

Implement the control in this order:

Request the age range before loading social capabilities.
Store only the minimum state required for the feature decision.
Block feeds, public profiles, comments, reactions, sharing, and discovery when the returned range is below your threshold.
Prevent cached or deep-linked social content from bypassing the gate.
Handle unavailable, declined, revoked, or incomplete responses safely.
Recheck access when the account, permission, or relevant app state changes.
Log the decision path without recording unnecessary personal information.

The minimum age behavior must be visible in the product, testable by QA, and understandable to App Review. Do not select the restricted path because it sounds safer if the code still allows under-13 users to browse or interact with social content.

Test age ranges and permissions in Sandbox

Apple provides a sandbox procedure for age assurance testing. On a supported test device, enable Developer Mode, open the Sandbox Apple Account settings, and choose age assurance scenarios. Apple’s documentation states that the sandbox returns lower and upper age bounds plus an age-range declaration. It also includes consent and revocation scenarios. (Apple’s age assurance Sandbox testing guide)

Your test record should include at least these branches:

Under 13: Social feed and interaction features are denied.
Ages 13–15: The app follows the intended teen feature policy.
Ages 16–17: The app handles the selected permission result correctly.
Adult, self-declared: The app does not incorrectly request a parental permission flow.
Adult, confirmed: The app accepts the returned state without treating it as a precise date of birth.
Consent revoked: Previously available child access is removed or re-evaluated.
API unavailable: The app fails closed for restricted features or follows a documented safe fallback.
Deep link and cached content: A blocked user cannot reach social content through an old route.

Apple’s sandbox examples include under-13, teen, and adult ranges, as well as cases where PermissionKit returns an unavailable error for adults. Do not hard-code assumptions from a single successful response. Validate both the returned range and declaration status.

Reconcile platforms and distribution channels

Age rating is app-level information in App Store Connect and applies across platforms. Apple’s App information reference identifies the rating as an app-level property applied across all platforms. That does not mean every platform build has identical behavior. It means your declared information must account for the app record as a whole. (Apple’s App information reference)

Review each platform separately:

iOS: Check the production feed, sharing, comments, and age gate.
iPadOS: Check split-screen, cached content, and platform-specific navigation.
macOS: Check whether desktop features expose the same social APIs or public content.
Other Apple platforms: Check whether the platform build removes or adds interaction paths.
Alternative distribution: Check the iOS build and the metadata used for notarization.

If iOS enables public comments while macOS only displays private documents, do not let the least capable platform define the answer automatically. Record the difference and confirm the proper App Store Connect submission treatment using Apple’s current rules.

The September requirement also matters for alternative distribution. Apple says responses will be required when submitting an app for notarization for alternative distribution. The notarization workflow has its own review type in App Store Connect, so teams distributing outside the App Store should include that path in release planning. (Apple’s developer announcement)

Complete the three-part release acceptance

Use this checklist with both the product owner and code owner. Operations should not sign it alone.

App Store Connect record

[ ] The new age rating questions are answered in the correct app record.
[ ] The answers were saved and reviewed by the Account Holder, Admin, or App Manager responsible for submission.
[ ] The selected social capability matches the release candidate, not only the product roadmap.
[ ] The generated rating and descriptors were rechecked after saving.
[ ] The same decision is documented for every platform attached to the app record.
[ ] The team has reviewed the alternative distribution and notarization path if applicable.

Product behavior

[ ] Public feeds, comments, reactions, profiles, search, and sharing were inventoried.
[ ] Feature flags, third-party components, and legacy API routes were checked.
[ ] The under-13 experience blocks every social entry point when that path is selected.
[ ] User-generated content is filtered or restricted according to the product’s documented policy.
[ ] Metadata, screenshots, review notes, and the binary describe the same feature set.

Code and test evidence

[ ] The Declared Age Range capability and entitlement are configured where required.
[ ] Under-13, teen, adult, unavailable, and consent-revoked branches were tested.
[ ] Deep links, cached screens, push notifications, and background refresh cannot bypass restrictions.
[ ] Test results include device, OS, build, account scenario, returned range, and final feature state.
[ ] The product owner and code owner have both approved the evidence packet.
[ ] The final test record is stored with the release candidate and submission date.

Use an isolated Mac when the main machine is the risk

A compliance check can expose a different operational problem: the main development Mac may be tied to production certificates, an older Xcode toolchain, or an unstable beta system. Changing that machine just to complete age-gate testing can create a larger release risk.

Compare the options honestly:

Local dedicated Mac: Best when you need permanent hardware access, physical device workflows, or long-running builds. The downside is hardware cost, setup time, and maintenance.
Isolated cloud Mac: Best when you need a separate Xcode and system environment for a defined project window. It keeps experimental SDKs, test accounts, and compliance records away from the production workstation. The downside is network dependency and the need to validate device access before committing.
Existing shared Mac: Lowest setup effort, but the weakest audit boundary. Shared certificates, accounts, caches, and system changes can make test evidence difficult to reproduce.

If your main Mac is not suitable for switching Xcode, testing accounts, or system versions, review MACCOME’s cloud Mac options before changing the production environment. For a short compliance cycle, you can also compare a Mac mini Silicon Valley environment with a local dedicated device. Choose based on the test window, access requirements, and record-keeping needs rather than on the questionnaire alone.

Make the September deadline a team handoff

The safest workflow is not “operations fills out the form.” It is a signed handoff:

Product confirms what users can publish, discover, amplify, and interact with.
Engineering confirms the age-range and permission behavior.
QA records Sandbox and release-candidate results.
Operations confirms the App Store Connect answers and submission path.
The release owner signs only after all four records agree.

Apple currently says the new responses will be required beginning in September 2026, but the cited announcement does not provide one universal date for every submission type. Treat August 2026 as the verification month. Recheck the live App Store Connect wording before submitting, because Apple may update the questionnaire or supporting documentation.

The main failure mode is not choosing the wrong store category. It is submitting metadata that describes a simpler app than the binary actually delivers.

For a temporary compliance environment, MACCOME can be a reasonable alternative to changing your production Mac when you need isolated Xcode, system, account, and test records for a defined release cycle. It is less suitable for teams that require permanent heavy workloads, physical peripherals, or uninterrupted local device access. Use the environment that makes your evidence reproducible, then submit only after the questionnaire, code, and test record tell the same story.