Die Social-Media-Checkbox des App Store und was sie kostet

Zwei boolesche Felder in der App Store Connect API tragen das gesamte Gewicht einer Einreichungspflicht, die im September beginnt: socialMedia und socialMediaAgeRestricted.¹ Das zweite kostet ein Entitlement, die Einbindung einer API und eine Verhaltensverzweigung in Ihrer App.

Angekündigt hat Apple die Pflicht am 8. Juni 2026: „Ab September 2026 müssen Sie angeben, ob Ihre App oder Ihr Spiel Social-Media-Funktionen enthält, um neue Versionen oder Updates im App Store einzureichen oder um sie für den Vertrieb über alternative App-Marktplätze notarisieren zu lassen.”² Am 9. Juli hat Apple die Änderung am Fragebogen ausgeliefert und einen Satz ergänzt, der darüber entscheidet, wie Sie die Spanne bis dahin nutzen sollten: „Sie können diese Fragen ab heute prüfen und beantworten.”³

TL;DR

• Die Angabe ist in App Store Connect bereits verfügbar und wird im September 2026 verpflichtend. Die Spanne zwischen verfügbar und verpflichtend gehört Ihnen – nutzen Sie sie für eine Entscheidung statt für eine Frist.²³
• Apple definiert „Social-Media-Funktionen” durchaus, an vier Stellen, und die Fassungen decken sich nicht. Im Juni ist der Begriff auf Feeds begrenzt, die „Inhalte sichtbar an viele Benutzer verbreiten”; im Juli fällt dieser Zusatz komplett weg.²³⁴
• Die App Store Connect API legt die Antwort als zwei beschreibbare boolesche Werte offen und führt userGeneratedContent und messagingAndChat weiterhin als eigene Fragen mit eigenen Altersuntergrenzen. Social Media ist eine neue Achse, keine Umbenennung.¹⁴
• Wer aus der Social-Media-Kategorie für unter 13-Jährige herausbleiben will, muss drei Bedingungen erfüllen, nicht eine. Apples Newsbeitrag nennt die Declared Age Range API; die Hilfe zu App Store Connect ergänzt, dass unter 13-Jährige überhaupt keinen Zugang erhalten und dass „ausschließlich altersgerechte nutzergenerierte Inhalte ausgeliefert werden”.²⁴
• Die Declared Age Range API gibt es für iOS, iPadOS, Mac Catalyst und macOS – und sonst nirgends.⁵ Eine tvOS-, visionOS- oder watchOS-App beantwortet die Frage im September trotzdem, und der dokumentierte Weg in die Ausnahme existiert auf ihrer Plattform nicht.

Die einzige Änderung dieses Zyklus, die ein Kalender auslöst

Jede andere einschneidende Änderung, über die ich in diesem Zyklus geschrieben habe, wartet darauf, dass Sie sich zuerst bewegen. Die Launch-Screen-Pflicht greift, sobald Sie gegen das SDK von iOS 27.0 bauen. Das @State-Makro greift, sobald Sie das Projekt in Xcode 27 öffnen. Die Abkündigung der On Demand Resources erzeugt eine Compiler-Warnung, die Sie beliebig lange ignorieren können. Lassen Sie Ihre Toolchain in Ruhe, und keine davon erreicht Sie.

Die Social-Media-Angabe erreicht Sie trotzdem, weil Apple sie an einen Monat gebunden hat und an eine Handlung, die Sie ohnehin vorgenommen hätten. Ein einzeiliger Bugfix läuft durch dieselbe Einreichungsstrecke wie ein Feature-Release, und ab September stellt diese Strecke die Frage.

Der Geltungsbereich ist eng und lohnt genaues Lesen. Die Pflicht umfasst „neue Versionen oder Updates im App Store” sowie die „Notarisierung für den Vertrieb über alternative App-Marktplätze”.² Im Juli wiederholt Apple das Paar als „neue Apps oder Updates im App Store” und „Apps zur Notarisierung für alternativen Vertrieb”.³ Keine der beiden Ankündigungen nennt eine SDK-Version, ein Deployment Target oder eine Plattform. Bereits veröffentlichte Apps verkaufen weiter. Die Hürde steht an der Tür der nächsten Einreichung.

Was die Antwort kostet, ist die Einordnung in eine Kategorie, die Eltern deckeln können. Time Allowances kommt in diesem Herbst zusammen mit Ask to Browse, Zeitplänen und einer überarbeiteten Bildschirmzeit und gibt Eltern „flexiblere Möglichkeiten, die Zeit zu steuern, die ihre Kinder in Apps verschiedener Kategorien verbringen, darunter Unterhaltung, Spiele und Social Media”, mit altersgerechten Empfehlungen als Ausgangspunkt.¹⁶ Die Einordnung in Unterhaltung und Spiele folgt Ihrer Kategorie in App Store Connect. Die Einordnung in Social Media folgt allein der Antwort im Fragebogen, „unabhängig von der in App Store Connect gewählten Kategorie”.² Ein Puzzlespiel mit Feed landet damit in genau der Kategorie, die Eltern als Erstes drosseln – ganz gleich, was auf der Produktseite steht.

Apple definiert den Begriff, und die Definitionen driften auseinander

Der übliche Fehlermodus bei einer Richtlinienfrage ist das Raten bei einem undefinierten Begriff. Apple hat eine Definition veröffentlicht, was das Raten eingrenzt – und sie viermal mit unterschiedlichen Abgrenzungen veröffentlicht.

Im Juni fasst Apple den Begriff weit: „Dazu gehört die Möglichkeit, nutzergenerierte Inhalte über einen sozialen Feed oder eine vergleichbare Entdeckungsmethode weiterzuverbreiten, zu verstärken oder mit ihnen zu interagieren, sodass Inhalte sichtbar an viele Benutzer verbreitet werden.”²

Im Juli ist die Formulierung definitorisch und kürzer: „Eine Social-Media-Funktion ist definiert als die Möglichkeit, nutzergenerierte Inhalte über einen sozialen Feed oder eine vergleichbare Entdeckungsmethode weiterzuverbreiten, zu verstärken oder mit ihnen zu interagieren.”³ Der Zusatz über die sichtbare Verbreitung an viele Benutzer fehlt.

Die Hilfe zu App Store Connect führt die längste Fassung, behält den Zusatz und ergänzt Beispiele: „Weiterverbreitung, Verstärkung oder Interaktion mit nutzergenerierten Inhalten über einen sozialen Feed oder eine vergleichbare Entdeckungsmethode, die Inhalte sichtbar an viele Benutzer verbreitet. Kann umfassen: Benutzer, die Inhalte erneut posten, liken, kommentieren, darauf reagieren oder nutzergenerierte Inhalte über einen sozialen Feed, eine Community, die Suche oder andere Teilen- und Entdeckungswerkzeuge sichtbarer machen.”⁴

Drei der vier Fassungen verlangen eine breite, sichtbare Verbreitung. Eine nicht, und bei einer App nahe an der Grenze entscheidet dieser Unterschied die Antwort. Ich würde die Hilfeseite als maßgeblich behandeln, weil der Fragebogen auf sie verlinkt und Newsbeiträge veralten; diese Lesart ist meine Schlussfolgerung, keine Anweisung von Apple. Auch das „Kann umfassen” zählt: Apple nennt Beispiele, statt die Menge zu schließen. Eine Funktion, die keinem der fünf genannten Verben ähnelt, kann also trotzdem darunterfallen.

Schärfer wird die Grenze durch die Nachbarschaft, in der der Deskriptor steht. Nutzergenerierte Inhalte definiert Apple getrennt als „die breite Verbreitung von Inhalten, die Benutzer erstellt haben, als Bestandteil der beabsichtigten Benutzererfahrung der App”, und Messaging und Chat noch einmal getrennt als Benutzer, die „innerhalb der App über entsprechende Funktionen direkt miteinander kommunizieren können”.⁴ Die App Store Connect API bildet diese Trennung exakt ab und führt userGeneratedContent, messagingAndChat und socialMedia als drei unabhängige boolesche Werte.¹

Ebenso deutlich gehen die Einstufungen auseinander. Nutzergenerierte Inhalte und Messaging tauchen beide in Apples Definition für 4+ auf. Social Media erscheint erstmals bei 13+.⁴ Eine App kann Benutzerinhalte beherbergen, Nachrichten zwischen Personen erlauben und trotzdem mit 4+ eingestuft werden; ergänzen Sie einen Feed, der genau diese Inhalte gegenüber Fremden verstärkt, und die Untergrenze springt um neun Jahre. Beide Social-Media-Deskriptoren existieren ausschließlich im Einstufungsschema für OS 26 und später, und Apples Tabelle für frühere OS-Versionen führt bei keiner Einstufung einen Social-Media-Eintrag.⁴

Das Feld lässt sich heute schon ausfüllen

Drei Apple-Dokumente belegen, dass die Änderung am Fragebogen bereits ausgeliefert ist – und das ist der praktische Kern dieses ganzen Beitrags.

Apples Ankündigung vom 9. Juli sagt, der Fragebogen „enthält jetzt Fragen zu den Social-Media-Funktionen Ihrer App”, und lädt dazu ein, sofort zu antworten.³ Die App Store Connect API dokumentiert socialMedia als „booleschen Wert, der angibt, ob die App Social-Media-Funktionen enthält”, und socialMediaAgeRestricted als „booleschen Wert, der angibt, ob die Social-Media-Funktionen der App altersbeschränkt sind”.¹ Apples veröffentlichte OpenAPI-Spezifikation führt beide als beschreibbare, nullable boolesche Werte.¹ Sie stehen neben ageAssurance, das aus Apples früherer Überarbeitung des Fragebogens stammt und in dessen Definition die „Declared Age Range API” als qualifizierender Mechanismus genannt wird.⁴¹⁵ Wer die Ausnahme nutzt, landet damit auch innerhalb dieser Definition – für mich eher eine zweite Frage, die man erneut prüfen sollte, als eine, die man liegen lässt.

Wer Einreichungen automatisiert, sollte die Form jetzt lernen: Die Angabe lesen Sie mit GET /v1/appInfos/{id}/ageRatingDeclaration, schreiben sie mit PATCH /v1/ageRatingDeclarations/{id} und übergeben einen der beiden booleschen Werte an den Parameter fields[ageRatingDeclarations].¹ Eine Pipeline, die Payloads zur Alterseinstufung von Hand zusammenbaut, läuft durch – bis zu dem Tag, an dem sie es nicht mehr tut.

Eine Konsequenz tauchte erst im Juli auf: „Apps mit diesen Funktionen zeigen auf ihrer App-Store-Produktseite einen neuen Inhaltsdeskriptor ‚Social Media’.”³ Ein Ja verändert also Ihren Eintrag, nicht bloß eine Kategorie in der Kindersicherung.

Öffnen Sie den Fragebogen deshalb in dieser Woche und lesen Sie die Einstufung, die App Store Connect berechnet. Das bindet Sie zu nichts, solange Sie nicht einreichen, und verwandelt eine Frist in eine Entscheidung, die Sie bereits getroffen haben.

Die Ausnahme hat drei Bedingungen, nicht eine

Apples Newsbeitrag lässt den Weg für unter 13-Jährige nach einem einzigen API-Aufruf klingen: „Wenn Sie angeben, dass Ihre App oder Ihr Spiel Social-Media-Funktionen enthält, diese aber für alle unter 13 Jahren deaktiviert sind, wird sie für Benutzer unter 13 Jahren nicht in die Time-Allowance-Kategorie Social Media aufgenommen … Außerdem müssen Sie mindestens die Declared Age Range API verwenden, um die Altersspanne der Benutzer zu prüfen.”²

Die Hilfe zu App Store Connect formuliert denselben Deskriptor als drei Anforderungen: „Benutzer unter 13 Jahren haben keinen Zugang zu Social-Media-Funktionen. Mindestens wird die Declared Age Range API aufgerufen, um die Altersspanne der Benutzer zu prüfen, bevor Social-Media-Funktionen aktiviert werden. Es werden ausschließlich altersgerechte nutzergenerierte Inhalte ausgeliefert.”⁴

Den dritten Satz zitiert niemand. „Es werden ausschließlich altersgerechte nutzergenerierte Inhalte ausgeliefert” ist eine Moderationspflicht ohne zugehörige API, ohne veröffentlichten Schwellenwert und ohne Test, den Sie laufen lassen könnten. Apple definiert weder „altersgerecht” noch den Auslieferungsmechanismus. Ein Team, das die Altersschranke einbaut und einer Zwölfjährigen denselben ungefilterten Feed ausliefert, hat nach dem Text der Hilfeseite eine von drei Bedingungen erfüllt.

Beachten Sie außerdem, was die Ausnahme nicht bringt. Apples eigener Satz geht weiter: Eine solche App „bleibt für Benutzer ab 13 Jahren in der Kategorie Social Media”.² Die Ausnahme deckt also nur unter 13-Jährige ab; eine Vierzehnjährige unterliegt weiterhin jedem Limit, das Eltern für Social Media gesetzt haben.

In den Einstufungstabellen steckt ein Widerspruch, den ich nicht auflösen konnte. Apples Newsbeitrag sagt, bei der eingeschränkten Option bestimmten Ihre „Gesamtantworten im Fragebogen zur Alterseinstufung” die Einstufung, was „zu einer Einstufung unterhalb von 13+ führen kann”.² Apples globale Tabelle führt jedoch sowohl „Social Media” als auch „Social Media für Benutzer unter 13 Jahren deaktiviert” unter Funktionen bei 13+, und die regionalen Tabellen setzen beide gemeinsam auf 16+ in Australien, A16 in Brasilien, 15+ in Korea und 16+ in Vietnam.⁴ Liest man das so wie jede andere Zeile, in der ein Deskriptor eine Untergrenze setzt, sieht auch die eingeschränkte Option nach einer Untergrenze von 13+ aus. Apple löst den Widerspruch nicht auf, und ich rate nicht, welches Dokument der Rechner umsetzt. Wählen Sie die Option im aktiven Fragebogen, lesen Sie die berechnete Einstufung und vertrauen Sie dem Rechner mehr als beiden Dokumenten.

Der Checkbox hinterher, hinein in die App

Nehmen wir an, Sie nutzen die Ausnahme. Sie aktivieren die Capability „Declared Age Range” für das Target in Xcode, wodurch das Entitlement com.apple.developer.declared-age-range hinzukommt: „Ein boolescher Wert, der angibt, ob Ihre App die Altersspanne einer Person abfragen darf.”⁶ Danach rufen Sie die API mit den Schwellen auf, die für Sie zählen – in SwiftUI in Form einer Environment-Action:⁵

Apple knüpft eine Platzierungsregel an diese Action: Verwenden Sie sie „als Reaktion auf Benutzerinteraktionen”, und Apples eigenes Beispiel hängt den Aufruf hinter einen Button.⁵ Die Anfrage kann ein System-Sheet einblenden; feuern Sie sie aus .task oder onAppear, wirft Ihre App jemandem eine Berechtigungsabfrage entgegen, der noch gar nichts verlangt hat. Hängen Sie sie stattdessen an den Tap, der die geschützte Oberfläche betritt.

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
    }
}

Vier Details in diesem Codebeispiel entscheiden darüber, ob die Schranke hält.

Sie bekommen höchstens drei Altersschwellen. Beide Überladungen enden bei drei Schwellenwerten: Die SwiftUI-Action lautet callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil), und die UIKit-Methode ergänzt lediglich den Präsentationsanker.⁷ Vier Altersgruppen sind die Obergrenze. Brauchen Sie 13 für Apples Regel und 16 für das australische Gesetz, haben Sie drei von vier verbraucht, bevor Sie überhaupt etwas entworfen haben.

Eine untere Grenze von nil ist die Antwort, kein Fehler. AgeRange.lowerBound und upperBound sind beide Int?, und Apple benennt den nil-Fall klar: „Wenn dieser Wert nil ist, liegt die Altersspanne der Person unterhalb Ihrer niedrigsten angegebenen Altersgrenze, das heißt, sie erfüllt Ihre Mindestaltersanforderung nicht.”⁸ Code, der das Optional optimistisch entpackt, kehrt die Schranke ausgerechnet bei der Gruppe um, zu deren Schutz sie existiert.

Die Ablehnung ist ein echter Zweig, und Apple sagt nicht, was damit zu tun ist. AgeRangeService.Response trägt .sharing(range:) und .declinedSharing.⁹ In manchen regulierten Regionen „stellt das System die Altersspanne der Person automatisch bereit”, und Personen „können das Teilen nicht ablehnen”; in nicht regulierten Regionen gilt: „Lehnt die Person ab, erhalten Sie eine declinedSharing-Antwort.”¹⁰ Eine Ablehnung ist nicht von einer erwachsenen Person zu unterscheiden, der ihre Privatsphäre wichtig ist: Behandeln Sie sie als unter 13, sperren Sie Erwachsene aus; behandeln Sie sie als erwachsen, öffnen Sie genau die Schranke, deren Schließung Sie zugesagt haben. Apple überlässt Ihnen die Voreinstellung. Ich würde im Zweifel sperren und das in der Oberfläche auch offenlegen.

Ihre Altersschwellen sind nur Vorschläge. Das System „kann Altersspannen zurückgeben, die Ihre angegebenen Altersschwellen überschreiben, abhängig vom Standort der Person und den geltenden Vorschriften”, und wenn lokale Vorschriften bestimmte Schwellen verlangen, „spiegelt die zurückgegebene Altersspanne die regulatorischen Anforderungen wider und nicht die Grenzen Ihrer Altersschwellen”.⁷ Code, der davon ausgeht, dass die zurückgegebenen Grenzen der Anfrage entsprechen, versagt zuerst in den strengsten Rechtsräumen.

Ein weiteres Verhalten gehört ins Design, und ich erwarte dazu Support-Tickets. Apple cacht die Antwort: „Wenn das Alter einer Person in eine neue Spanne wechselt (etwa mit dem 13. Geburtstag), gibt die API weiterhin die vorherige Spanne zurück, bis sich die ursprüngliche Angabe jährt.”¹⁰ Ein Kind, das am Montag 13 wird, kann noch monatelang als unter 13 gelesen werden. Abhilfe schafft nur ein Weg durch die Einstellungen, den die Person selbst geht: unter dem eigenen Namen, dann „Persönliche Daten”, dann „Altersbereich für Apps”.¹⁰ Jede App, die bei 13 eine Schranke setzt, braucht diese Anleitung in der eigenen Oberfläche, denn sonst findet sie niemand.

Zwei kleinere Details zählen schon beim Entwurf. isEligibleForAgeFeatures meldet, ob die Person in einer Region lebt, die eine Altersprüfung verlangt, und liefert unter macOS „false, weil das System für die Person oder das Gerät keine Altersprüfung verlangt” – eine Mac-App ruft also direkt requestAgeRange auf.¹¹ Und AgeRangeDeclaration, das meldet, wie das Alter festgestellt wurde, hat sich bereits verändert: sechs feingliedrige Fälle in 26.2, die Zahlungsmethode, amtlichen Ausweis und weitere Verfahren für Person und Erziehungsberechtigte benennen, zusammengefasst zu einem einzigen confirmed-Fall in 26.5.¹² Fragen Sie, welche Methode einen Benutzer verifiziert hat, sagt es die aktuelle API nicht mehr.

Bleibt die Plattform-Untergrenze, die nur die Verfügbarkeits-Metadaten nennen und keine einzige Prosaquelle. Declared Age Range führt iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 und macOS 26.0 – und sonst nichts: keine tvOS-Zeile, keine visionOS-Zeile, keine watchOS-Zeile.⁵ Time Allowances erscheint für dieselben Plattformfamilien, „iOS 27, iPadOS 27 und macOS 27 oder neuer”, während die Angabepflicht überhaupt keine Plattformeinschränkung trägt.²³ Eine tvOS- oder visionOS-App mit sozialem Feed antwortet also im September und kann die dokumentierte Mindestbedingung der Ausnahme nicht erfüllen, weil es die dort genannte API auf ihrer Plattform nicht gibt. Dass ich diese Diskrepanz als Lücke lese und nicht als beabsichtigte Befreiung, ist meine Schlussfolgerung; Apple hat sich in keine Richtung geäußert.

Was acht meiner eigenen Apps angeben

Bevor ich über fremden Code schreibe, habe ich die Erhebung im eigenen gemacht: acht Xcode-Projekte, 491 Swift-Dateien.¹³ Keine einzige enthält CKShare, UICloudSharingController, eine geteilte oder öffentliche CloudKit-Datenbank, GameKit oder irgendein Declared-Age-Range-Symbol. Keine App aus dieser Auswahl bewegt überhaupt Inhalte von einer Person zu einer anderen. Vier Projekte enthalten gar keine auffällige Oberfläche. Die anderen vier enthalten Oberflächen, bei denen man mit gutem Grund zögern könnte, und sie fallen in drei Arten, die es sich laut durchzudenken lohnt.

Get Bananas hat eine geteilte Einkaufsliste, und „geteilt” ist enger, als es klingt. Die App schreibt ein JSON-Dokument in einen iCloud-Ubiquity-Container und liest es auf iPhone, Apple Watch und Mac wieder aus, mit com.apple.developer.icloud-services auf CloudDocuments und ohne CloudKit-Sharing irgendwo im Projekt.¹³ Die Liste wird über die Geräte einer Person hinweg geteilt, nicht zwischen Personen; es wird also nichts weiterverbreitet, und es gibt keinen zweiten Benutzer, zu dem sich etwas verbreiten könnte. Die Antwort kippt an dem Tag, an dem ich CKShare für die Zusammenarbeit im Haushalt ergänze – und selbst dann kippt sie zu nutzergenerierten Inhalten, nicht zu Social Media, denn eine Einkaufsliste für zwei Personen hat weder Feed noch Entdeckungsoberfläche. Die Linie, die man im Auge behalten muss, liegt weiter draußen: geteilte Listen plus öffentliche Vorlagengalerie plus Likes ergeben einen Feed mit Zwischenschritten.

Drei Apps zeigen ein Share Sheet, und ein Share Sheet ist keine soziale Funktion. Get Bananas, Water und die iOS-App von ResumeGeni kapseln jeweils UIActivityViewController, um die eigenen Inhalte der Person an die App zu übergeben, die sie auswählt.¹³ Die Inhalte wandern zu Nachrichten oder Mail und kehren nie auf eine Oberfläche zurück, die meine App kontrolliert; Apples Definition hängt aber an der Weiterverbreitung „über einen sozialen Feed oder eine vergleichbare Entdeckungsmethode”, und ein System-Share-Sheet ist beides nicht.⁴ Diese Begründung deckt einen großen Teil des App Store ab: Exportieren ist kein Veröffentlichen.

Watch Connectivity sieht nach Messaging aus, ist es aber nicht. Get Bananas und Reps verwenden beide WCSession, das Daten zwischen einem Telefon und einer damit gekoppelten Uhr derselben Person bewegt, während Apples Deskriptor für Messaging und Chat verlangt, dass „Benutzer direkt miteinander kommunizieren können”.⁴¹³ An beiden Enden sitzt derselbe Benutzer.

Das Nullergebnis lässt sich verallgemeinern, und genau das ist der übertragbare Teil. Jede App aus dieser Auswahl speichert Inhalte für die Person, die sie erstellt hat, und zeigt sie derselben Person wieder an. Der Fragebogen fragt etwas ganz anderes: Nimmt Ihre App die Inhalte einer Person und stellt sie anderen über einen Mechanismus vor Augen, der verbreitet? Tracker, Timer und Lernwerkzeuge antworten schon aus Architekturgründen mit Nein, nicht aufgrund einer Richtlinienauslegung. Nachdenken müssen die Apps mit einer Oberfläche, auf der Benutzer die Arbeit anderer sehen.

Die zweite Zahl, die zuerst zu prüfen ist, sind die Deployment Targets. Sechs der sieben Projekte mit iOS-Target liegen bei iOS 26.0 oder höher; Ace Citizenship gibt bei einigen Targets weiterhin 17.0 und 17.5 an.¹³ Alles unterhalb von 26.0 kann die API gar nicht aufrufen, womit die Ausnahme entfällt und nur die schlichte Angabe als korrekte Antwort bleibt.

Die Plattformlücke zeigt sich in derselben Erhebung, und zwar breiter als die Versionslücke. Vier der acht Projekte deklarieren xros xrsimulator in SUPPORTED_PLATFORMS: Reps, Return, Water und Yawara. Reps ergänzt appletvos appletvsimulator und liefert ein eigenes watchos watchsimulator-Target; Return und Banana List führen ebenfalls watchOS-Targets.¹³ Declared Age Range veröffentlicht Verfügbarkeit für iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 und macOS 26.0 und keine Zeile für tvOS, visionOS oder watchOS.⁵ Jedes dieser Targets schuldet im September die Angabe, und auf jedem davon rückt ein Ja die Ausnahme außer Reichweite, weil die API, auf der sie beruht, dort nicht ausgeliefert wird.

Eine Warnung zur Methode, weil ich es im ersten Durchgang falsch gemacht habe: XROS_DEPLOYMENT_TARGET taucht auch in Projekten auf, die überhaupt kein visionOS-Ziel haben, weil Xcode die Einstellung ungefragt in die Konfigurationen schreibt. ResumeGeni führt XROS_DEPLOYMENT_TARGET = 26.2 und baut ausschließlich iphoneos iphonesimulator.¹³ Lesen Sie SUPPORTED_PLATFORMS und nicht die Deployment-Target-Schlüssel, sonst zählen Sie Plattformen mit, die Ihre App nicht ausliefert.

Wo die Antwort aufhört, technisch zu sein

An die Dokumentation zu Declared Age Range hängt Apple einen Hinweis, den man zweimal lesen sollte: Die Daten „beruhen auf Angaben eines Endbenutzers oder seiner Eltern beziehungsweise Erziehungsberechtigten”, und „Sie allein sind dafür verantwortlich, die Einhaltung der für Ihre App möglicherweise geltenden Gesetze und Vorschriften sicherzustellen”.¹⁴

Dieser Satz zieht die Linie, an der dieser Beitrag endet. Apples Fragebogen erzeugt eine Einstufung und eine Time-Allowance-Kategorie, aber keinerlei Rechtskonformität. In Australien müssen bestimmte Social-Media-Plattformen seit dem 10. Dezember 2025 verhindern, dass Personen unter 16 Jahren ein Konto führen, und Apples Leitfaden zu diesem Gesetz nennt die Declared Age Range API als eines von fünf Werkzeugen.¹⁵ Fragebogen und Gesetz überschneiden sich, ohne deckungsgleich zu sein: Das eine fragt nach 13, das andere nach 16, und Sie haben drei Schwellen für beides.

Ob Ihre App nach einem bestimmten Gesetz eine Social-Media-Plattform ist, beantwortet eine Anwältin oder ein Anwalt im jeweiligen Rechtsraum. Ob sie nach Apples Fragebogen Social-Media-Funktionen enthält, beantworten Sie – heute, anhand von Apples veröffentlichter Definition.

FAQ

Ist die Social-Media-Frage in App Store Connect schon aktiv?

Ja. Apples Ankündigung vom 9. Juli 2026 sagt, der Fragebogen „enthält jetzt Fragen zu den Social-Media-Funktionen Ihrer App” und „Sie können diese Fragen ab heute prüfen und beantworten”.³ Die App Store Connect API bestätigt das unabhängig davon und dokumentiert socialMedia und socialMediaAgeRestricted als Attribute der Ressource AgeRatingDeclaration, beide beschreibbar über PATCH /v1/ageRatingDeclarations/{id}.¹ Jetzt zu antworten bindet Sie zu nichts: Die Antworten werden mit der Einreichung verbindlich, und ab September 2026 funktioniert das Einreichen ohne sie nicht mehr.²

Definiert Apple „Social-Media-Funktionen”?

Ja, an vier Stellen und mit zwei verschiedenen Reichweiten. Die Hilfe zu App Store Connect liefert die vollständigste Fassung und verlangt „Weiterverbreitung, Verstärkung oder Interaktion mit nutzergenerierten Inhalten über einen sozialen Feed oder eine vergleichbare Entdeckungsmethode, die Inhalte sichtbar an viele Benutzer verbreitet”; als Beispiele nennt sie erneutes Posten, Liken, Kommentieren, Reagieren und das Sichtbarmachen von Inhalten.⁴ Der Juni-Text trägt denselben einschränkenden Zusatz, der Juli-Text lässt ihn weg.²³ Weil die Beispiele illustrativ und nicht abschließend sind, ordnen Sie Ihre App weiterhin selbst ein – und ich würde sie an der Hilfeseite messen.

Meine App enthält nutzergenerierte Inhalte. Ist das automatisch Social Media?

Nein. Apple führt beides als getrennte Fragen mit getrennten Definitionen und getrennten Folgen für die Einstufung. Nutzergenerierte Inhalte umfassen „die breite Verbreitung von Inhalten, die Benutzer erstellt haben, als Bestandteil der beabsichtigten Benutzererfahrung der App”, und tauchen in Apples Definition für 4+ auf.⁴ Social Media verlangt Weiterverbreitung, Verstärkung oder Interaktion über einen Feed oder eine vergleichbare Entdeckungsoberfläche und erscheint erstmals bei 13+.⁴ Die API bildet die Trennung mit unabhängigen booleschen Werten userGeneratedContent und socialMedia ab.¹ Eine App, in der Menschen Inhalte erstellen, die nur sie selbst sehen, ist keines von beidem.

Was muss ich für die Option „unter 13” tatsächlich bauen?

Drei Dinge, und nur das zweite ist eine API. Die Hilfe zu App Store Connect verlangt, dass unter 13-Jährige keinen Zugang zu Social-Media-Funktionen haben, dass „mindestens die Declared Age Range API aufgerufen wird, um die Altersspanne der Benutzer zu prüfen, bevor Social-Media-Funktionen aktiviert werden”, und dass „ausschließlich altersgerechte nutzergenerierte Inhalte ausgeliefert werden”.⁴ Sie ergänzen also das Entitlement com.apple.developer.declared-age-range, rufen requestAgeRange mit 13 unter Ihren Schwellen auf, bevor irgendeine soziale Oberfläche erscheint, verzweigen über die Antwort einschließlich des Ablehnungsfalls, den Apple undefiniert lässt, und halten davon unabhängig die Inhalte altersgerecht, die Sie Minderjährigen ausliefern.⁵⁶ Die API deckelt Sie bei drei Schwellen und cacht die Altersspanne einer Person bis zum Jahrestag ihrer Angabe – wer 13 wird, gilt also weiterhin als jünger, bis er oder sie die Einstellungen anpasst.⁷¹⁰

Die wichtigsten Erkenntnisse

Für iOS-Entwickler: - Beantworten Sie den Fragebogen jetzt und nicht im September. Das Feld ist aktiv, die Antworten binden erst mit der Einreichung, und die berechnete Einstufung klärt die 13+-Frage, die keine der beiden Ankündigungen sauber auflöst.³⁴ - Wenn Sie die Ausnahme für unter 13-Jährige nutzen, kalkulieren Sie drei Bedingungen ein statt eines API-Aufrufs, und schreiben Sie den Ablehnungszweig bewusst. .declinedSharing ist von einer datenschutzbewussten erwachsenen Person nicht zu unterscheiden, und Apple gibt keinerlei Hinweis, ob man im Zweifel sperren oder öffnen soll.⁴⁹

Für Teams auf tvOS, visionOS oder watchOS: - Prüfen Sie die Verfügbarkeit, bevor Sie planen. Declared Age Range führt Zeilen für iOS, iPadOS, Mac Catalyst und macOS und sonst nichts; die dokumentierte Mindestbedingung der Ausnahme ist auf Ihrer Plattform also nicht erreichbar, während die September-Angabe für Ihre Einreichung weiterhin gilt.²⁵ - Dieselbe Lücke trifft aus anderem Grund jedes Target unterhalb von iOS 26.0: keine API, keine Ausnahme, und nur die schlichte Angabe als korrekte Antwort.⁵

Für Release-Manager: - Behandeln Sie das Datum als Auslöser – anders als beim Rest dieses Zyklus. Der Launch-Screen-Schlüssel und das @State-Makro feuern über ein SDK und eine Toolchain, die Sie kontrollieren; der September feuert über eine Einreichung, die Sie ohnehin vorgenommen hätten.² - Leiten Sie die Antwort an die Person weiter, die für die Produktseite verantwortlich ist. Wer Social-Media-Funktionen angibt, bekommt einen Inhaltsdeskriptor „Social Media” in seinem App-Store-Eintrag – eine Folge, die Apple erst im Juli offengelegt hat.³

Der 27er-Zyklus sortiert seine Änderungen weiterhin danach, was sie auslöst: eine Build-Einstellung, eine Toolchain, eine Compiler-Warnung – und jetzt ein Kalender. Zur Abkündigung desselben Zyklus mit den schwächsten Zähnen und der größten Migration dahinter siehe On Demand Resources und was Background Assets kostet. Die vollständige Übersicht der Reihe ist die Apple-Ecosystem-Serie.

Quellen