How to Declare App Store Social Media Capabilities? 2026 Submission Decision

Apple says that, starting in September 2026, developers must report whether an app has social media capabilities when submitting a new app, an update, or an app for notarization for alternative distribution. The question appears in the age rating questionnaire. This is a reporting requirement; it does not mean that every app answering “yes” automatically receives a particular age rating.

Use Apple’s App Store Connect instructions for setting an app age rating to locate the questionnaire and check the current options. Don’t rely on an old saved answer or an earlier submission to confirm that the current form is complete.

Keep these statuses separate:

• Capability declaration: Your response about whether the app has the defined social media capability.
• Age rating: The rating that results from the complete questionnaire.
• Underage availability: Whether the relevant capability is available to users under the age threshold specified in the questionnaire.
• Build upload and review: Technical submission and Apple’s review of the app.
• Notarization: A separate process for qualifying alternative distribution.

A completed questionnaire does not upload a build, complete review, or guarantee notarization. Apple’s age rating values and definitions explain the rating outcomes and capability terms. Treat each state as its own check.

Stop and verify: If the submission screen does not show the expected question, check Apple’s current instructions and the submission type before proceeding. Don’t assume the question is irrelevant because the app is not marketed as social.

Start from the current, usable product—not the roadmap, App Store category, or a broad label such as “community app.” The question is about behavior. A product described as a utility could still let users discover and interact with other users’ content. A product categorized as social networking may not have the specific discovery or interaction behavior described by Apple.

Write down the relevant features and where users reach them. Review the released interface, feature flags, and product rules. If a feature is available only to some account types or behind a setting, record that condition rather than treating the feature as absent.

Use this preflight list:

• [ ] Can users create or submit content that other users can see?
• [ ] Can users find that content through a feed, recommendations, search, profiles, or a similar discovery surface?
• [ ] Does the app redistribute or amplify user-generated content through ranking, sharing, reposting, recommendations, or another product mechanism?
• [ ] Can users interact with the content or its creator inside the app?
• [ ] Are any of these actions disabled, restricted, or available only to certain users?
• [ ] Does the shipped interface match the behavior you are about to declare?

Save a short feature note beside the release record. For each relevant feature, include a plain-language description and the screen or product rule that supports your answer. A screenshot can help show the interface, but it does not prove how ranking, visibility, or account restrictions work. Keep both the visible evidence and the underlying behavior in view.

How do you judge whether an app has social media capabilities?

Apple’s definition focuses on the ability to redistribute, amplify, or enable interaction with user-generated content through a social media feed or similar discovery mechanism. Review the official age rating definitions alongside the actual user journey.

A content feed that surfaces posts from other users, lets users react or comment, or promotes user content to new viewers is a strong reason to assess the capability question carefully. The same is true if the app uses a discovery surface that performs a similar role without calling itself a feed. The label on a tab is not decisive; the function is.

A private note-taking app that stores only the account holder’s own entries has a different behavior from a product that publishes entries to a shared feed. A static catalog maintained by the developer is also different from a catalog that presents user submissions for discovery and interaction. These examples are a way to structure your review, not a substitute for applying Apple’s definition to your implementation.

Do comments or user posts alone count?

Don’t decide from the presence of a comment box or posting control alone. Check how the content is made visible, discovered, redistributed, and interacted with. A user post shown only to its author differs from a post that appears in a shared feed. A comment feature attached to discoverable user content may be relevant even if the app has no feature named “social feed.”

When behavior sits near the boundary, document the user journey and the product rules that control visibility and interaction. Then compare those facts with Apple’s definition. Don’t turn an uncertain edge case into a universal rule for every app with comments, reviews, or profiles.

Open the age rating questionnaire in App Store Connect and answer using the feature inventory. Apple’s questionnaire instructions are the source for the current workflow; its age-rating declaration API reference provides a separate reference for the declaration fields.

For each answer, ask what a user can do in the version you’re submitting. Avoid these shortcuts:

• “It’s a productivity app, so no.” Categories don’t describe every enabled feature.
• “The team plans to add a feed, so yes.” A roadmap is not the released behavior being assessed.
• “Users can post, so the answer is always yes.” Posting alone does not describe discovery, redistribution, or interaction.
• “The screen looks like a feed, so that settles it.” Review the actual rules for who can see, find, and interact with the content.

If the answer depends on a feature flag, account state, or regional configuration, record which release configuration you’re reviewing. If the feature is disabled in the submitted build, make sure the disabled state is real and can be verified—not merely planned or hidden in the interface.

Does the age rating questionnaire need an answer before an update?

Yes. Apple’s announced requirement covers updates as well as new app submissions. Check the questionnaire as part of update preparation, and confirm that the declaration reflects the version being submitted. Apple’s September 2026 announcement describes the start date and applicable submission types.

The social media capability answer is one part of the questionnaire. It is not a separate approval, and it does not replace other age rating answers. Don’t infer that changing this response automatically changes the app’s final rating in a predictable direction. Review the full questionnaire and the rating definitions instead.

If your app has the relevant capability, also verify the questionnaire’s question about whether that capability is available to users under 13. This is a separate product-state check. Don’t treat the capability declaration as the answer to the underage-availability question.

Trace how access works in the submitted product. Check account creation, age gates, feature restrictions, and any settings that control access. If the restriction depends on an account’s age or another condition, verify that the condition actually blocks the relevant capability in the app. A policy statement or design note is not enough if the release configuration still exposes the feature.

Apple’s age rating definitions describe the relationship between the capability and the Social Media Time Allowance classification. Use the exact current wording in the questionnaire when assessing your product. Do not describe this classification as an automatic age-rating downgrade, an exemption from other questions, or a guarantee of a particular rating.

Keep the questions distinct: “Does the app have the capability?” and “Is it available to users under 13?” are separate checks. Record evidence for each answer instead of reusing one response as a shortcut.

Use the submission route you are actually taking. For App Store distribution, confirm the age-rating information in App Store Connect, then handle the build, review, and release steps separately. Apple’s build upload documentation covers uploading a build; completing that technical task does not establish that the questionnaire or review is complete.

For alternative distribution, check whether your app is being submitted for notarization and whether the reporting requirement applies to that submission. Apple’s guide to distributing an app on an alternative marketplace explains that distribution route. Don’t assume the App Store submission path and alternative distribution notarization are interchangeable.

Use this decision branch before you proceed:

• If you’re submitting a new app or update for App Store distribution: review the current questionnaire in App Store Connect, complete the capability and other relevant answers, then confirm build upload and review status separately.
• If you’re preparing alternative distribution that requires notarization: verify the notarization route and its current requirements, then complete the applicable declaration checks before treating the submission as ready.
• If the product has no user-content discovery or interaction behavior: answer based on that implementation, but keep the feature inventory that supports your decision.
• If you can’t tell whether a feature redistributes, amplifies, or enables interaction with user-generated content: pause the release decision, trace the real user journey, and resolve the classification against Apple’s definition before submitting.

This avoids a common release mistake: seeing a successful upload and assuming every separate declaration and review state is complete. Check the questionnaire, build status, review status, and notarization status independently.

Keep a record of the questionnaire response, the app version, and the product behavior used to make the decision. Include links to internal feature notes or screenshots where your team stores release evidence. The purpose is not to create paperwork for its own sake. It is to let the next person understand why the answer matched the shipped behavior.

Reassess when you add or change a feed, recommendations, user profiles, comments, sharing, reposting, or another route for finding and interacting with user-generated content. Also revisit the answer if you change age restrictions or enable a previously disabled feature. A minor interface change can alter discoverability or access even when the feature name stays the same.

Before you close the release task:

• [ ] The questionnaire reflects the version and configuration you’re submitting.
• [ ] Each answer has a corresponding product behavior or restriction you can verify.
• [ ] Under-13 availability was checked separately where applicable.
• [ ] Build upload, review, and notarization are tracked as separate states.
• [ ] The evidence is saved where the release owner can find it.
• [ ] App Store Connect’s current page still allows you to continue through the intended submission path.

The last check matters because Apple can change questionnaire wording or submission screens. When the page differs from your internal instructions, use Apple’s current help pages and update the team’s runbook rather than forcing the old sequence.

Use this table to keep the declaration separate from the outcome. It is a classification aid, not a replacement for Apple’s current questionnaire.

Then use this route table to confirm which work remains:

If you need to check the cost of a Mac environment for the build-and-upload work, review CALMVPS Mac rental plans. A rented Mac can provide a macOS environment for tasks such as working with Xcode and handling release builds, but it cannot determine your questionnaire answers or guarantee review or notarization. If your current setup relies on a Windows or Linux machine, a hosted Mac can avoid buying a Mac solely for macOS release tasks, but it adds a recurring rental cost and a remote-access dependency. If you need a machine permanently, require local physical connections, or run heavy workloads continuously, compare rental against buying and maintaining a local Mac before choosing.

Complete the feature review and questionnaire first. If macOS build or upload work is the remaining bottleneck, compare your needs with CALMVPS’s available Mac options and choose a remote environment only if it fits the release workflow you actually have.