iOS 27 Social Media Feature Declaration: How to Self-Check Your App? (2026)

From September 2026, Apple requires developers to answer social media capability questions when submitting new apps or app updates, with some alternative distribution notarization workflows also covered by the requirement (Apple’s announcement). The right decision is based on what people can actually do in the app—not its App Store category or product name. Check whether user content is shared, surfaced, amplified, or interacted with through a feed or similar discovery path. If the app meets Apple’s definition, declare it; if the feature is disabled for children under 13, verify the age-range check and access restriction in the working app.

This guide is for independent developers whose apps include user posts, feeds, likes, comments, or sharing and who need to review age rating answers.
It also helps small release teams confirm what to check before submitting an update.
If the app serves minors, use the access-control section to test the under-13 restriction.

Last updated October 31, 2026; checked against Apple Developer News, App Store Connect Help, and Apple’s age rating and Declared Age Range API documentation.

Identify the capability from the user journey

Apple’s social media capability definition is the starting point, but an app’s label is not enough to decide how to answer. Follow a realistic user journey: who creates the content, who can see it, how it reaches them, and what actions they can take. Apple’s announcement and its age rating definitions describe the relevant capability and rating concepts.

A user-generated-content feature is not automatically the same as a social media feature. A private note saved for its author has a different reach from a public post in a browsable community feed. Direct messaging also needs to be assessed on its own terms: the presence of a chat screen alone does not establish that content is promoted through a feed or discovery surface. Keep the distinctions clear when answering separate questions in App Store Connect.

For each feature, document four things:

• Creator: Can a user create or upload content, or does the app provide it?
• Audience: Is the content private, limited to invited people, or visible to a broader group?
• Distribution: Can people find it through a feed, recommendation surface, profile, search, or another discovery route?
• Interaction: Can viewers like, comment on, share, repost, or otherwise engage with the content?

The decision should reflect the combined path, not one isolated control. A share button can send a private item to a chosen recipient, or it can help distribute a public post. Those are materially different flows. Likewise, a comment feature may be attached to a public feed or restricted to a small, controlled collaboration space. Record which behavior the shipped version actually permits.

Which app functions count as social media capability? Look for user content that other people can access or interact with, especially when a feed or similar discovery mechanism helps that content travel beyond its creator. Apple lists activities such as browsing, liking, commenting, and sharing as relevant examples. Treat them as clues to investigate, not as a rule that any single button automatically determines the answer.

Compare common feature scenarios before answering

The table is an editorial triage aid, not an Apple scoring system. “Review priority” indicates how closely the feature path should be checked against Apple’s definition. The final answer must still match the complete app and Apple’s current questionnaire.

A high-priority scenario is not an automatic “yes.” It means the team should trace the exact feature path and compare it with Apple’s definition. A low-priority scenario is not an automatic “no” either: another area of the app may expose user content to others. Apple’s age rating questionnaire includes distinct content and capability concepts, so review the official definitions rather than collapsing all user content, chat, and social behavior into one label.

Do comments or sharing alone require a declaration? Not necessarily. Inspect what the control acts on and where the content goes. Comments attached to content shown to a broad audience create a different user journey from feedback visible only to the author. Sharing can likewise be a private handoff or a way to distribute a post. The answer should follow the full interaction path and the applicable App Store Connect question, not the button name.

Decide whether a feed or discovery surface changes the answer

A feed matters because it can make one user’s content visible to people beyond the original conversation. Check the main timeline, community pages, recommended content, public profiles, search results, and any other surface where people can encounter posts they did not receive directly. Apple’s examples of browsing, liking, commenting, and sharing help identify the behaviors to examine, but the actual product design supplies the evidence.

Start with the screen a new or signed-in user sees. Note whether it contains content from other users, how that content was selected, and whether a viewer can reach the creator or continue to related posts. Then test whether the feed is chronological, curated, or recommended. The selection method does not by itself determine the declaration. What matters is whether the app lets users view or engage with content created by others through a social or discovery experience.

Also check what happens outside the main feed. A public profile, searchable post archive, or “related posts” panel can widen the audience even if the home screen does not look like a conventional social network. Conversely, a feature described in marketing copy as a “community” may still be tightly limited to a private group. Use the shipped interface and permission rules, not the wording used to promote the feature.

Keep a short evidence log. For each relevant screen, capture the account state, content visibility, and the actions available. Include any restrictions such as invitation-only access or group membership. This gives the release owner a concrete basis for the answer and makes a later review possible when product behavior changes.

A product name such as “community,” “forum,” or “messaging” is not a reliable classification. Test whether people can discover or interact with other users’ content, and record the actual access path.

Separate UGC, direct messages, and content amplification

What if the app has user content or chat but no social media feature? Answer the questionnaire based on the feature being asked about. An app can allow people to submit content without making that content viewable by other users. It can also provide direct messages without a public feed. Neither fact, by itself, resolves every age rating question.

For user-generated content, examine whether posts are moderated, who can see them, and whether the app republishes them in a shared area. A submission form that sends material to the app operator for support or review is not the same user experience as a public gallery where visitors can browse submissions. The content’s audience and distribution are central to the distinction.

For messaging, test the complete route from opening a conversation to sending, receiving, and forwarding content. Is the conversation one-to-one or group-based? Can a user find other people inside the app? Can messages or attachments be exposed through a public profile or feed? These questions help describe the feature accurately, but do not invent a separate Apple rule from the answers. Use Apple’s actual questionnaire labels and definitions when completing the form.

How should an app with no social media capability answer the age rating question? Select the answer that accurately reflects the absence of the capability, then answer other age rating items independently. “No social media capability” does not mean “no user-generated content,” “no messaging,” or “no other age-related features.” The App Store Connect guide explains the process for setting an app age rating; use the questionnaire’s own definitions for each item.

A useful internal record has three parts: the feature description, the evidence from the app, and the reason the selected answer matches the questionnaire wording. Avoid writing only “not a social app.” That statement describes a product category, not the user behavior that the declaration is meant to capture.

Apply the under-13 restriction to the real app

A declaration that social media features are disabled for users under 13 should describe functioning behavior, not a policy statement or a design intention. The team needs to know how the app determines the relevant age range and how that result controls access to the features. Apple’s Declared Age Range API documentation and its guidance on requesting a person’s age range explain the API path for obtaining an age range, rather than relying on the app to collect a full date of birth.

The operative threshold in this declaration is under 13, as reflected in Apple’s social media guidance and age assurance materials. Do not treat a user’s self-declared birthday, a parental notice, or wording in the privacy policy as proof that the feature is unavailable. Test the app’s actual response when an age range indicates a user is below the threshold.

What must be checked after disabling the feature for under-13 users? Verify both the age-range determination and the block itself. Test the relevant entry points: feed access, post creation, comments, sharing, messaging, and any deep link that could open a restricted screen. Confirm that cached sessions, account changes, and navigation paths do not leave an alternate route into the feature. The scope of this testing is an implementation check, not a claim that Apple has approved a particular app.

Apple documents the API’s intended use and provides an age assurance FAQ. Review Apple’s API request guidance alongside its age assurance materials before choosing an implementation. If the app integrates the API, test its response path using Apple’s Age Assurance Sandbox instructions. A sandbox test verifies the integration path; it does not establish the app’s final age rating or guarantee a review outcome.

The age rating still depends on the other answers in the questionnaire. Apple’s available rating bands include 4+, 9+, 13+, 16+, and 18+; the presence of social media capability or an under-13 restriction does not, on its own, determine one fixed rating. Use Apple’s age rating definitions to assess the complete set of content and capability answers.

Use conditional checks to choose the declaration

Apply these conditions to the current version of the app. If product behavior changes, repeat the assessment.

• If users can view or discover other users’ content through a feed or similar surface, compare that complete experience with Apple’s social media capability definition and declare the capability when it meets the definition. Keep screenshots and access-path notes as the basis for the answer.
• If the app has likes, comments, or sharing, but no obvious feed, trace what content each action affects and who can see the result. If the action amplifies or exposes other users’ content, review the feature as a possible social media capability rather than deciding from the control alone.
• If user content is private or only visible to the app operator, do not infer social media capability merely from the existence of a submission form. Answer the separate UGC and other questionnaire items according to their own definitions.
• If social media features are intended to be unavailable to users under 13, choose that option only after verifying the age-range check and testing every route to the restricted feature. If that control is not implemented or cannot be verified, do not represent the feature as disabled for that age group.
• If none of the app’s user journeys meet the definition, answer no to the social media capability item, then complete the rest of the age rating questionnaire independently. Retain a brief rationale so the answer can be revisited after a feature change.

This is a decision aid, not a substitute for Apple’s wording. If a behavior falls near a boundary, preserve the evidence and avoid claiming that a particular answer guarantees a specific review result.

Complete the submission review before sending a build

Use the following release process to catch mismatches between the questionnaire and the submitted app:

1. Inventory user-facing features. List feeds, profiles, comments, reactions, messaging, sharing, search, and user submissions. Include features that appear only after login or membership.
2. Trace representative journeys. Use test accounts to follow content from creation to viewing and interaction. Record the audience and any path that broadens distribution.
3. Review each age rating item separately. In App Store Connect, compare the app’s behavior with Apple’s current questionnaire definitions. Do not let a “no social media” answer substitute for other answers.
4. Test age-based restrictions. Where the app declares that social media features are disabled for under-13 users, verify the age-range determination, the block, and all alternate entry points. Use Apple’s Sandbox documentation when testing a Declared Age Range integration.
5. Check the selected answer against the release build. Confirm that the version being submitted has the same feed visibility, interaction controls, and age gates as the version reviewed by the team.
6. Revisit the questionnaire after feature changes. A new public profile, recommendation feed, repost action, or changed age gate can alter the basis for an earlier answer. Recheck the App Store Connect status before the next submission.

Apple says the declaration requirement applies from September 2026 to app submissions and updates, with certain alternative distribution notarization processes also addressed in its announcement. Check the current App Store Connect status for each app; do not assume an earlier answer covers a later feature change. Apple’s App Review Guidelines also instruct developers to provide accurate answers about app content and functionality. An answer should match the app under review, not a planned future state.

The actual implementation work may require a Mac if the team needs to modify an iOS project, build it with Xcode, sign it, and verify the release artifact. That does not make a rented Mac necessary for deciding the questionnaire. A developer with a suitable local Mac can use it; a team with an existing reliable build pipeline may already have the needed environment. If the current setup relies on a personal machine, it may be unavailable to teammates, while a general-purpose CI setup can add configuration and signing-maintenance work. For a temporary release or a repeatable remote build, compare those constraints with the Mac options comparison.

First settle the declaration from the app’s real content paths and confirm any under-13 restriction in a testable build. If a release still needs a Mac for code changes, signing, or submission checks—and buying hardware is not justified for an occasional workload—renting a Mac from BookaMac can provide a temporary build environment without making the compliance decision depend on the rental. Review the workflow and access requirements in the remote Mac documentation, then choose the environment only if it fits the team’s build and verification needs.