The App Store's Social Media Checkbox and What It Costs

Two Boolean fields in the App Store Connect API carry the entire weight of a submission requirement that starts in September: socialMedia and socialMediaAgeRestricted.¹ The second one costs an entitlement, an API adoption, and a behavioral branch in your app.

Apple announced the requirement on June 8, 2026: “Starting September 2026, you’ll be required to indicate whether your app or game includes social media capabilities in order to submit new versions or updates to the App Store, or for notarization for distribution on alternative app marketplaces.”² On July 9 Apple shipped the questionnaire change and added one sentence that decides how you should spend the weeks before then: “You can review and answer these questions starting today.”³

TL;DR

• The declaration is live in App Store Connect right now and becomes mandatory in September 2026, so the gap between available and required is yours to spend on a decision rather than a deadline.²³
• Apple does define “social media capabilities,” in four places, and the three do not match. June scopes it to feeds “that visibly spreads content to many users”; July drops the clause entirely.²³⁴
• The App Store Connect API exposes the answer as two writable Booleans and keeps userGeneratedContent and messagingAndChat as separate questions with separate rating floors. Social media is a new axis, not a rename.¹⁴
• Staying out of the under-13 Social Media bucket takes three conditions, not one. Apple’s news post names the Declared Age Range API; App Store Connect Help adds that under-13 users get no access at all and that “Only age-appropriate UGC is delivered.”²⁴
• The Declared Age Range API ships on iOS, iPadOS, Mac Catalyst, and macOS, and nowhere else.⁵ A tvOS, visionOS, or watchOS app still answers the question in September, and the documented way to qualify for the carve-out does not exist on its platform.

The one change in this cycle that a calendar fires

Every other breaking change I have covered this cycle waits for you to move first. The launch screen requirement triggers on building against the iOS 27.0 SDK. The @State macro triggers on opening the project in Xcode 27. The On Demand Resources deprecation triggers a compiler warning you can ignore indefinitely. Leave your toolchain alone and none of them reaches you.

The social media declaration reaches you anyway, because Apple bound it to a month and to an act you were performing regardless. A one-line bug fix rides the same submission pipeline as a feature release, and in September that pipeline asks the question.

The scope is narrow and worth reading exactly. The requirement covers “new versions or updates to the App Store” and “notarization for distribution on alternative app marketplaces.”² July repeats the pair as “new apps or updates to the App Store” and “apps for notarization for alternative distribution.”³ Neither announcement mentions an SDK version, a deployment target, or a platform. Apps already live keep selling. The gate stands at the door of the next submission.

What the answer costs you is placement in a bucket parents can cap. Time Allowances arrives this fall alongside Ask to Browse, Schedules, and a redesigned Screen Time, giving parents “more flexible ways to manage the time their kids spend in apps across categories, including Entertainment, Games, and Social Media,” with age-tailored guidance as the starting point.¹⁶ Entertainment and Games placement follows your App Store Connect category. Social Media placement follows the questionnaire answer alone, “regardless of the category selected in App Store Connect.”² A puzzle game with a feed lands in the category a parent throttles first, whatever the product page says.

Apple defines the term, and the definitions drift

The usual failure mode with a policy question is guessing at an undefined word. Apple published a definition, which narrows the guessing, and published it four times with different edges.

June frames it inclusively: “This includes the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method that visibly spreads content to many users.”²

July frames it definitionally, and shorter: “A social media capability is defined as the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method.”³ The qualifier about visibly spreading content to many users is gone.

App Store Connect Help carries the longest version, keeps the qualifier, and adds examples: “Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users. May include: users reposting, liking, commenting, reacting, or making user-generated content more visible through a social feed, community, search, or other sharing and discovery tools.”⁴

Three of the four require broad visible spread. One does not, and for an app near the boundary the difference decides the answer. I would treat the Help page as controlling, because the questionnaire links to it and news posts age out; reading it that way is my inference, not Apple’s instruction. “May include” matters too: Apple lists examples rather than closing the set, so a capability resembling none of the five listed verbs can still qualify.

What sharpens the boundary is the company the descriptor keeps. Apple defines User-Generated Content separately, as “the broad distribution of content created by users as a component of the app’s intended user experience,” and Messaging and Chat separately again, as users who “can directly communicate with one another through features within the app.”⁴ The App Store Connect API preserves the split exactly, carrying userGeneratedContent, messagingAndChat, and socialMedia as three independent Booleans.¹

Ratings diverge just as sharply. User-generated content and messaging both appear in Apple’s 4+ definition. Social media appears first at 13+.⁴ An app can host user content, let people message each other, and still rate 4+; add a feed that amplifies that same content to strangers and the floor jumps nine years. Both social media descriptors live only in the rating scheme for OS 26 and later, and Apple’s table for earlier OS versions carries no social media entry at any rating.⁴

The field is answerable today

Three Apple artifacts confirm the questionnaire change already shipped, which is the practical point of the whole post.

Apple’s July 9 announcement says the questionnaire “now includes questions about your app’s social media capabilities” and invites you to answer immediately.³ The App Store Connect API documents socialMedia as “A Boolean value that indicates whether the app includes social media features” and socialMediaAgeRestricted as “A Boolean value that indicates whether the app’s social media features are age restricted.”¹ Apple’s published OpenAPI specification carries both as writable, nullable Booleans.¹ They sit next to ageAssurance, added by Apple’s earlier questionnaire overhaul, whose definition names “declared age range API” as a qualifying mechanism.⁴¹⁵ Adopting the carve-out therefore lands you inside that definition too, which reads to me as a second question to revisit rather than one to leave alone.

Anyone automating submissions should learn the shape now: read the declaration at GET /v1/appInfos/{id}/ageRatingDeclaration, write it at PATCH /v1/ageRatingDeclarations/{id}, and pass either Boolean to the fields[ageRatingDeclarations] parameter.¹ A pipeline that builds age rating payloads by hand keeps passing until the day it does not.

One consequence surfaced only in July: “Apps with these capabilities will display a new Social Media content descriptor on their App Store product page.”³ Answering yes changes your listing, not only a parental-controls bucket.

So open the questionnaire this week and read the rating App Store Connect computes. Doing so commits nothing until you submit, and converts a deadline into a decision you have already made.

The carve-out has three conditions, not one

Apple’s news post makes the under-13 path sound like a single API call: “If you indicate that your app or game includes social media capabilities but they are disabled for anyone under 13, it won’t be included in the Time Allowance category for Social Media for users under 13… You’ll also need to use the Declared Age Range API (at a minimum) to check users’ age ranges.”²

App Store Connect Help states the same descriptor as three requirements: “Users under 13 don’t have access to social media capabilities. At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features. Only age-appropriate UGC is delivered.”⁴

The third sentence is the one nobody quotes. “Only age-appropriate UGC is delivered” is a moderation obligation with no API attached, no threshold published, and no test you can run. Apple defines neither age-appropriate nor the delivery mechanism. A team that adopts the age gate and ships the same unfiltered feed to a 12-year-old has met one condition of three by the Help page’s own text.

Note also what the carve-out does not buy. Apple’s own sentence continues that such an app “will remain in the Social Media category for users 13 and above.”² The exemption covers under-13 users only, so a 14-year-old still meets whatever cap a parent set on Social Media.

The rating tables carry a tension I could not resolve. Apple’s news post says the restricted option leaves your “overall responses in the age rating questionnaire” to determine the rating, which “may result in a rating lower than 13+.”² Yet Apple’s global table lists both “Social media” and “Social media disabled for users under 13” under Capabilities at 13+, and the regional tables place both together at 16+ in Australia, A16 in Brazil, 15+ in Korea, and 16+ in Vietnam.⁴ Read the way every other row reads, where a descriptor sets a floor, the restricted option looks like a 13+ floor too. Apple reconciles nothing, and I am not guessing which document the calculator implements. Select the option in the live questionnaire, read the computed rating, and trust the calculator over both.

Following the checkbox down into the app

Say you take the carve-out. You enable the Declared Age Range capability on the target in Xcode, which adds the com.apple.developer.declared-age-range entitlement: “A Boolean value indicating whether your app may request a person’s age range.”⁶ Then you call the API with the thresholds you care about, which in SwiftUI arrives as an environment action:⁵

Apple attaches a placement rule to that action: use it “in response to user interactions,” and Apple’s own sample puts the call behind a button.⁵ The request can present a system sheet, so firing it from .task or onAppear throws a permission prompt at someone who has not asked for anything yet. Hang it on the tap that enters the gated surface instead.

import SwiftUI
import DeclaredAgeRange

@available(iOS 26.0, *)
struct SocialFeedGate: View {
    @Environment(\.requestAgeRange) private var requestAgeRange
    @State private var feedEnabled = false
    @State private var checking = false

    var body: some View {
        if feedEnabled {
            FeedView()
        } else {
            Button("Open community feed") {
                checking = true
                Task {
                    feedEnabled = await resolveGate()
                    checking = false
                }
            }
            .disabled(checking)
        }
    }

    private func resolveGate() async -> Bool {
        guard let response = try? await requestAgeRange(ageGates: 13) else {
            return false          // AgeRangeService.Error: your default, not Apple's
        }
        guard case let .sharing(ageRange) = response else {
            return false          // .declinedSharing
        }
        guard let lowerBound = ageRange.lowerBound else {
            return false          // nil lower bound means below your lowest gate
        }
        return lowerBound >= 13
    }
}

Four details in that listing decide whether the gate holds.

You get at most three gates. Both overloads stop at three thresholds: the SwiftUI action is callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil), and the UIKit method adds only the presentation anchor.⁷ Four buckets is the ceiling. Need 13 for Apple’s rule and 16 for Australian law, and you have spent three of four before designing anything.

A nil lower bound is the answer, not an error. AgeRange.lowerBound and upperBound are both Int?, and Apple states the nil case plainly: “When this value is nil, the person’s age range is below your lowest specified age, indicating they are under your minimum age requirement.”⁸ Code that unwraps optimistically inverts the gate on exactly the population it exists to protect.

Declining is a real branch, and Apple does not say what to do with it. AgeRangeService.Response carries .sharing(range:) and .declinedSharing.⁹ In some regulated regions “the system automatically provides the person’s age range” and people “can’t decline sharing”; in nonregulated regions “If the person declines, you receive a declinedSharing response.”¹⁰ A decline is indistinguishable from an adult who values privacy: treat it as under-13 and you block grown-ups, treat it as adult and you open the gate you promised to close. Apple leaves the default to you. I would fail closed and say so in the interface.

Your gates are advisory. The system “may return age ranges that override the age gates you specify based on the person’s location and applicable regulations,” and when local regulations require specific gates, “the returned age range reflects regulatory requirements rather than the bounds of your age gates.”⁷ Code assuming the returned bounds match the request misbehaves first in the strictest jurisdictions.

One more behavior belongs in the design, and I expect it to generate support tickets. Apple caches the answer: “When a person’s age crosses into a new range (for example, when they turn 13), the API continues returning the previous range until the anniversary of their original declaration.”¹⁰ A child who turns 13 on Monday can keep reading as under-13 for months. The remedy is a Settings path the user walks alone, under their name, then Personal Information, then Age Range for Apps.¹⁰ Any app gating on 13 needs that instruction in its own UI, because nobody finds it otherwise.

Two smaller details matter at design time. isEligibleForAgeFeatures reports whether the person sits in a region requiring age assurance, and on macOS it “returns false because the system doesn’t require Age Assurance for the person or device,” so a Mac app calls requestAgeRange directly instead.¹¹ And AgeRangeDeclaration, which reports how the age was set, has already churned: six granular cases at 26.2 naming payment, government ID, and other methods for person and guardian, collapsed into a single confirmed case at 26.5.¹² Ask which method verified a user and the current API no longer says.

Then there is the platform floor, which the availability metadata states and no prose source does. Declared Age Range publishes iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, and macOS 26.0, and nothing else: no tvOS row, no visionOS row, no watchOS row.⁵ Time Allowances lands on the same families, “iOS 27, iPadOS 27, and macOS 27, or later,” while the declaration requirement carries no platform qualifier at all.²³ A tvOS or visionOS app with a social feed therefore answers in September and cannot meet the documented minimum of the carve-out, because the API it names does not exist there. Reading the mismatch as a gap rather than an intentional exemption is my inference; Apple has published nothing either way.

What eight of my own apps declare

I ran the survey before writing about anyone else’s code: eight Xcode projects, 491 Swift files.¹³ Zero contain CKShare, UICloudSharingController, a shared or public CloudKit database, GameKit, or any Declared Age Range symbol. No app in the set moves content from one person to another at all. Four projects hold no flagged surface whatsoever. The other four hold surfaces a careful person could hesitate over, and they come in three kinds worth reasoning through out loud.

Get Bananas has a shared shopping list, and “shared” is narrower than it sounds. The app writes a JSON document into an iCloud ubiquity container and reads it back on iPhone, Apple Watch, and Mac, with com.apple.developer.icloud-services set to CloudDocuments and no CloudKit sharing anywhere in the project.¹³ The list is shared across one person’s devices, not between people, so nothing redistributes and there is no second user to spread to. The answer flips the day I add CKShare for household collaboration, and even then it flips to user-generated content rather than social media, because a two-person grocery list has no feed and no discovery surface. The line worth watching sits further out: shared lists plus a public template gallery plus likes is a feed with extra steps.

Three apps present a share sheet, and a share sheet is not a social feature. Get Bananas, Water, and ResumeGeni’s iOS app each wrap UIActivityViewController to hand the user’s own content to whatever app they pick.¹³ The content leaves for Messages or Mail and never returns to a surface my app controls, and Apple’s definition turns on redistribution “through a social feed or similar discovery method,” which a system share sheet is not.⁴ The reasoning covers a large slice of the App Store: exporting is not publishing.

Watch Connectivity looks like messaging and is not. Get Bananas and Reps both use WCSession, which moves data between a phone and a watch paired to the same person, while Apple’s Messaging and Chat descriptor requires that “Users can directly communicate with one another.”⁴¹³ One user sits on both ends.

The null result generalizes, which is the part worth borrowing. Every app in the set stores content for the person who made it and shows it back to that same person. The questionnaire asks something else entirely: does your app take one person’s content and put it in front of others through something that spreads. Trackers, timers, and study tools answer no by architecture rather than by policy reading. The apps that have to think are the ones with any surface where users see each other’s work.

Deployment targets are the other number to check first. Six of the seven projects with an iOS target sit at iOS 26.0 or later; Ace Citizenship still declares 17.0 and 17.5 on some of its targets.¹³ Anything below 26.0 cannot call the API at all, which removes the carve-out and leaves the plain declaration as the only accurate answer.

The platform gap shows up in the same survey, and more widely than the version one. Four of the eight projects declare xros xrsimulator in SUPPORTED_PLATFORMS: Reps, Return, Water, and Yawara. Reps adds appletvos appletvsimulator and ships a separate watchos watchsimulator target; Return and Banana List carry watchOS targets too.¹³ Declared Age Range publishes availability for iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, and macOS 26.0, and no row for tvOS, visionOS, or watchOS.⁵ Every one of those targets owes the September declaration, and on any of them an answer of yes puts the carve-out out of reach, because the API the carve-out depends on does not ship there.

A caution on method, since I got this wrong on the first pass. XROS_DEPLOYMENT_TARGET appears in projects that have no visionOS destination at all, because Xcode writes the setting into configurations regardless. ResumeGeni carries XROS_DEPLOYMENT_TARGET = 26.2 and builds iphoneos iphonesimulator only.¹³ Read SUPPORTED_PLATFORMS, not the deployment-target keys, or you will count platforms your app does not ship.

Where the answer stops being technical

Apple attaches a disclaimer to the Declared Age Range documentation worth reading twice: the data “is based on information declared by an end user, or their parent or guardian,” and “You are solely responsible for ensuring compliance with associated laws or regulations that may apply to your app.”¹⁴

That sentence draws the line the post stops at. Apple’s questionnaire produces a rating and a Time Allowance bucket, and compliance with nothing. Australian law has required certain social media platforms to prevent people under 16 from holding an account since December 10, 2025, and Apple’s guidance on that law names the Declared Age Range API as one tool among five.¹⁵ Questionnaire and statute overlap without lining up: one asks about 13, the other about 16, and you have three gates to cover both.

Whether your app is a social media platform under a given law is a question for a lawyer in that jurisdiction. Whether it has social media capabilities under Apple’s questionnaire is yours, answerable today against Apple’s published definition.

FAQ

Is the social media question live in App Store Connect right now?

Yes. Apple’s July 9, 2026 announcement states that the questionnaire “now includes questions about your app’s social media capabilities” and that “You can review and answer these questions starting today.”³ The App Store Connect API confirms it independently, documenting socialMedia and socialMediaAgeRestricted as attributes of the AgeRatingDeclaration resource, both writable through PATCH /v1/ageRatingDeclarations/{id}.¹ Answering now commits nothing: responses bind when you submit, and September 2026 is when submitting without them stops working.²

Does Apple define “social media capabilities”?

Yes, in four places, with two different scopes. App Store Connect Help gives the fullest version, requiring “Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users,” then lists reposting, liking, commenting, reacting, and boosting visibility as examples.⁴ June carries the same scoping clause; July drops it.²³ Because the examples are illustrative rather than exhaustive, you still classify your own app, and I would classify it against the Help page.

My app has user-generated content. Is that automatically social media?

No. Apple keeps them as separate questions with separate definitions and separate rating consequences. User-Generated Content covers “the broad distribution of content created by users as a component of the app’s intended user experience,” and appears in Apple’s 4+ definition.⁴ Social media requires redistribution, amplification, or interaction through a feed or comparable discovery surface, and appears first at 13+.⁴ The API mirrors the split with independent userGeneratedContent and socialMedia Booleans.¹ An app where people create content only they see is neither.

What does the under-13 option actually require me to build?

Three things, and only the second is an API. App Store Connect Help requires that under-13 users have no access to social media capabilities, that “At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features,” and that “Only age-appropriate UGC is delivered.”⁴ So you add the com.apple.developer.declared-age-range entitlement, call requestAgeRange with 13 among your gates before any social surface appears, branch on the response including the decline case Apple leaves undefined, and separately keep the content you deliver to minors age appropriate.⁵⁶ The API caps you at three gates and caches a person’s range until the anniversary of their declaration, so a user who turns 13 keeps reading as younger until they update Settings.⁷¹⁰

Key Takeaways

For iOS developers: - Answer the questionnaire this week rather than in September. The field is live, the responses bind only at submission, and reading the computed rating settles the 13+ question that neither announcement resolves cleanly.³⁴ - If you take the under-13 carve-out, budget for three conditions rather than one API call, and write the decline branch deliberately. .declinedSharing looks identical to a privacy-minded adult, and Apple publishes no guidance on which way to fail.⁴⁹

For teams on tvOS, visionOS, or watchOS: - Check availability before you plan. Declared Age Range publishes iOS, iPadOS, Mac Catalyst, and macOS rows and nothing else, so the carve-out’s documented minimum is unavailable on your platform while the September declaration still applies to your submission.²⁵ - The same gap catches any target below iOS 26.0 for a different reason: no API, no carve-out, and the plain declaration as the only accurate answer.⁵

For release managers: - Treat the date as the trigger, unlike the rest of this cycle. The launch screen key and the @State macro fire on an SDK and a toolchain you control; September fires on a submission you were making anyway.² - Route the answer past whoever owns the product page. Declaring social media capabilities adds a Social Media content descriptor to your App Store listing, a consequence Apple disclosed only in July.³

The 27 cycle keeps sorting its changes by what sets them off: a build setting, a toolchain, a compiler warning, and now a calendar. For the deprecation in the same cycle with the weakest teeth and the largest migration behind it, see On Demand Resources and what Background Assets costs. The full series hub is the Apple Ecosystem Series.

References