Symptom: Ihre App enthält Kommentare, einen Feed oder Nutzerprofile, aber niemand kann sicher sagen, ob im neuen Altersfragebogen „Social Media“ angegeben werden muss.

Schnellste Lösung: Entscheiden Sie nicht anhand der App-Kategorie. Prüfen Sie, ob Nutzerinhalte öffentlich verbreitet, hervorgehoben oder interaktiv weiterverarbeitet werden. Falls soziale Funktionen für unter 13-Jährige deaktiviert sind, müssen Sie zusätzlich die Alterslogik technisch umsetzen und testen. Idealerweise sind Fragebogen, Code und Einreichungsnachweis vor dem September-Release 2026 abgeschlossen.

Diese Anleitung richtet sich an unabhängige Entwickler, Produktverantwortliche, App-Store-Operatoren und mobile Entwicklungsteams, die ab September 2026 neue Versionen, Updates oder alternative Vertriebswege vorbereiten. Sie ist besonders relevant für Apps mit UGC, öffentlichen Feeds, Kommentaren, Empfehlungen, Nutzerprofilen oder Altersbeschränkungen.

Letzte Aktualisierung: 14.08.2026. Die Angaben wurden anhand der aktuellen Apple Developer News, der App Store Connect-Hilfe sowie der Dokumentation zur Declared Age Range API geprüft. Apple nennt derzeit „ab September 2026“, aber keinen einheitlichen konkreten Starttag.

1. Prüfen Sie die tatsächliche Funktion statt der App-Kategorie

Der App-Store-Altersfragebogen 2026 sollte nicht mechanisch aus der primären App-Kategorie abgeleitet werden. Eine App aus den Bereichen Bildung, Produktivität oder Dienstprogramme kann soziale Medienfähigkeiten besitzen. Umgekehrt ist ein Login allein noch kein Beleg für eine soziale Funktion.

Entscheidend ist, was Nutzer mit Inhalten anderer Nutzer tun können:

  • Keine soziale Verbreitung: Die App verarbeitet Inhalte lokal, zeigt redaktionelle Inhalte nur einseitig an oder bietet einen privaten Arbeitsbereich ohne öffentliche Entdeckung und Interaktion.
  • Private oder begrenzte Nutzerinhalte: Nutzer können Inhalte erstellen oder speichern, diese bleiben jedoch auf das eigene Konto oder einen klar abgegrenzten privaten Arbeitsbereich beschränkt.
  • Öffentliche Nutzerinhalte: Beiträge können von anderen Personen gefunden, gelesen, kommentiert oder bewertet werden.
  • Verstärkte Inhalte: Ein Feed, eine Empfehlung, eine Rangliste, Likes oder Reaktionen machen bestimmte Beiträge für weitere Nutzer sichtbarer.
  • Soziale Medienfähigkeit: Nutzer können Inhalte öffentlich verbreiten, hervorheben, kommentieren, liken, beantworten oder über einen sozialen Feed entdecken.
  • Altersabhängige Sperre: Die soziale Funktion besteht grundsätzlich, wird aber für eine bestimmte Altersgruppe technisch abgeschaltet.

Apple beschreibt soziale Medienfähigkeiten im Zusammenhang mit der Weiterverbreitung, Verstärkung oder Interaktion mit nutzergenerierten Inhalten über einen sozialen Feed oder eine vergleichbare Entdeckungsfunktion. Die Einordnung für Time Allowances ist deshalb nicht dasselbe wie die primäre Kategorie, unter der Nutzer die App im Store finden. Lesen Sie dazu die offizielle Ankündigung zu den neuen Altersangaben.

Wichtig: „User-Generated Content“ und „Social Media“ sind nicht automatisch gleichbedeutend. Ein privater Upload, ein interner Arbeitsbereich und ein öffentlich empfohlener Beitrag müssen getrennt bewertet werden.

2. Dokumentieren Sie die Grenzen einer privaten oder lokalen App

Bei einer Werkzeug-App liegt das Risiko oft nicht im Hauptfeature. Es steckt in Nebenpfaden, alten Releases und aktivierten Backend-Funktionen.

Prüfen Sie mindestens diese Punkte:

  • Gibt es öffentliche Kommentare, Bewertungen oder Antworten?
  • Können Nutzerbeiträge über eine Suche oder einen öffentlichen Feed entdeckt werden?
  • Werden Beiträge durch Likes, Reaktionen, Ranglisten oder Empfehlungen sichtbarer?
  • Können Inhalte weitergeleitet, erneut veröffentlicht oder in einen anderen Feed übernommen werden?
  • Sind Community-Funktionen nur über ein Feature Flag aktiv?
  • Enthält ein Drittanbieter-SDK einen Chat, Feed oder öffentlichen Profilbereich?
  • Ist eine entfernte Funktion im Backend weiterhin erreichbar?
  • Können Nutzer andere Personen blockieren oder Inhalte melden?
  • Werden Moderationsregeln tatsächlich durchgesetzt oder nur in der Benutzeroberfläche angezeigt?
  • Sind die Funktionen auf iPhone, iPad und Mac identisch?

Eine App ohne öffentliche Inhaltsverbreitung ist leichter zu beurteilen. Das gilt beispielsweise für:

  • einen lokalen Dokumentenscanner;
  • einen privaten Passwort- oder Notizbereich;
  • einen persönlichen Zeitplan;
  • eine Entwickler-App für lokale Tests;
  • einen privaten Arbeitsbereich ohne öffentliche Suche;
  • eine reine Lese-App mit redaktionell verwalteten Inhalten.

Anders sieht es aus, wenn ein zunächst privates Produkt später soziale Bausteine erhält. Ein „Teilen“-Button, öffentliche Profile oder ein Empfehlungsfeed können die Bewertung verändern, auch wenn die App weiterhin als Produktivitätswerkzeug vermarktet wird.

Legen Sie pro Release eine kurze Funktionsakte an:

  1. Liste aller Nutzerinhalte.
  2. Sichtbarkeit je Nutzergruppe.
  3. Mögliche Verbreitungswege.
  4. Interaktionsarten.
  5. Altersabhängige Einschränkungen.
  6. Backend- und Feature-Flag-Status.
  7. App-Version und Build-Nummer.
  8. Zugehörige Screenshots und Release Notes.

Die Apple-Definitionen der Altersfreigabe helfen bei der Zuordnung einzelner Funktionen. Die interne Akte ist trotzdem erforderlich, weil sie dokumentiert, wie Ihr Team zu seiner konkreten Auswahl gekommen ist.

3. Bewerten Sie UGC, Feed und Interaktion als Funktionskette

Bei einer Community-App reicht die Bezeichnung „Forum“, „Lernplattform“ oder „Marktplatz“ nicht aus. Bewerten Sie die komplette Kette:

Erstellen → Veröffentlichen → Entdecken → Verstärken → Interagieren

Je mehr dieser Schritte öffentlich und für viele Nutzer verfügbar sind, desto stärker spricht die Funktion für eine soziale Medienfähigkeit.

Beispiel: reine Nutzerablage

Nutzer laden Dateien hoch. Die Dateien sind nur für das eigene Konto oder ausdrücklich eingeladene Teammitglieder sichtbar. Es gibt keine öffentliche Suche, keinen Empfehlungsmechanismus und keine Reaktionen.

Prüfung: Wahrscheinlich keine soziale Medienfähigkeit allein aufgrund des Uploads. Kontrollieren Sie jedoch Freigabelinks, öffentliche Vorschauen und automatisch erzeugte Aktivitätsfeeds.

Beispiel: Kurs- oder Lernplattform

Nutzer veröffentlichen Kommentare unter einer Lektion. Kommentare können von allen Kursteilnehmern gelesen und beantwortet werden. Es gibt keine globale Suche und keinen öffentlichen Empfehlungsfeed.

Prüfung: Die Reichweite und Interaktion müssen genau dokumentiert werden. Eine gruppenweite Diskussion ist nicht automatisch identisch mit einem offenen sozialen Netzwerk, aber sie darf nicht einfach als private Funktion eingestuft werden.

Beispiel: Community mit Empfehlungssystem

Nutzer veröffentlichen Beiträge. Ein Algorithmus sortiert diese nach Popularität, andere Nutzer können reagieren und der Feed empfiehlt Inhalte an weitere Konten.

Prüfung: Mehrere typische Merkmale sozialer Medien sind vorhanden. Dazu gehören öffentliche Verbreitung, Verstärkung durch Empfehlungen und sichtbare Interaktion.

Vorteile einer präzisen Funktionsprüfung

  • Sie vermeiden eine zu niedrige Einstufung.
  • Sie verhindern Entscheidungen allein nach dem Produktnamen.
  • Sie können die Antwort bei späteren Releases nachvollziehbar aktualisieren.
  • Sie erkennen fehlende Melde-, Blockier- oder Moderationsfunktionen früh.
  • Sie trennen App-Store-Altersfreigaben von zusätzlichen regionalen Pflichten.

Typische Fehler bei Community-Apps

  • Ein öffentlicher Feed wird als „nur Kommentare“ bezeichnet.
  • Ein Empfehlungssystem wird bei der Inhaltsverbreitung vergessen.
  • Nur der iPhone-Build wird geprüft.
  • Testkonten sehen weniger Funktionen als Produktionskonten.
  • Das Marketing verspricht Community-Austausch, während die Metadaten soziale Funktionen nicht widerspiegeln.
  • Die Antwort wird von der Betriebs- oder Marketingseite allein festgelegt.

Die Altersfreigabe wird auf App-Ebene verwaltet und kann globale sowie regionale Ergebnisse berücksichtigen. Prüfen Sie deshalb die sichtbare Einstufung nach dem Speichern Ihrer Antworten, statt nur die einzelnen Auswahlfelder zu archivieren. Weitere Hinweise enthält die Apple-Hilfe zum Festlegen einer App-Altersfreigabe.

4. Setzen Sie Altersbarrieren technisch um

Die Auswahl „soziale Funktionen für unter 13-Jährige deaktiviert“ ist keine reine Metadatenentscheidung. Wenn Ihre App diese Option nutzt, muss sie die Altersgruppe erkennen und die betreffenden Funktionen tatsächlich beschränken.

Dafür ist die Declared Age Range API vorgesehen. Sie liefert keine frei auslesbare Geburtstagangabe. Stattdessen stellt das System eine deklarierte Altersgruppe bereit. Je nach Situation kann diese Erklärung von der betroffenen Person oder von einem Elternteil beziehungsweise Erziehungsberechtigten stammen.

Die Anwendung sollte aus dieser Information eine klare Berechtigungsentscheidung ableiten:

  • Unter 13: Kein öffentlicher Feed, keine öffentlichen Kommentare, keine Empfehlungen und keine soziale Weitergabe.
  • 13 bis 15: Nur die Funktionen aktivieren, die Ihre Produktregeln und die jeweils erforderlichen Einschränkungen erlauben.
  • 16 bis 17: Prüfen, ob zusätzliche Produkt- oder Einwilligungsregeln gelten.
  • Erwachsene: Die normale soziale Funktion aktivieren, sofern keine andere Sperre greift.
  • Keine verwertbare Altersangabe oder Widerruf: Auf einen sicheren Zustand zurückfallen und die geschützte Funktion nicht freischalten.

Apple beschreibt die API und die Anforderungen an die Fähigkeit in der Dokumentation zur Declared Age Range API. Für die technische Umsetzung sind insbesondere Entitlements, Signierung, Berechtigungslogik und der Umgang mit fehlenden Rückgabewerten relevant.

Vermeiden Sie unnötige personenbezogene Speicherung. Für die Freigabe eines Feeds benötigen Sie in vielen Fällen nicht das Geburtsdatum, sondern nur eine belastbare Entscheidung wie „Funktion erlaubt“ oder „Funktion gesperrt“. Die konkrete Datenverarbeitung muss trotzdem zu Ihrer Datenschutz- und Sicherheitsarchitektur passen.

5. Führen Sie die Altersprüfung in fünf Schritten durch

Schritt 1: Erstellen Sie eine Funktionsmatrix

Definieren Sie für jede Altersgruppe:

  • sichtbare Bildschirme;
  • erlaubte API-Aufrufe;
  • Feed-Endpunkte;
  • Kommentarfunktionen;
  • Reaktionen und Empfehlungen;
  • Teilen und Weiterleiten;
  • Cache-Verhalten;
  • Backend-Berechtigungen.

Schreiben Sie nicht nur „Social Media aus“. Benennen Sie jede Funktion, die unter 13 blockiert werden muss.

Schritt 2: Prüfen Sie Xcode und Entitlements

Aktivieren Sie die erforderliche Fähigkeit in Xcode. Kontrollieren Sie anschließend:

  • Bundle Identifier;
  • Entitlements-Datei;
  • Provisioning Profile;
  • Signatur;
  • Zielplattform;
  • Mindestbetriebssystem;
  • verwendete Build-Konfiguration.

Ein lokaler Debug-Build ohne korrekte Signierung ist kein ausreichender Nachweis für den späteren Einreichungsbuild.

Schritt 3: Richten Sie Sandbox-Szenarien ein

Verwenden Sie offizielle Sandbox-Szenarien anstelle selbst konstruierter Geburtsdaten. Apple dokumentiert dort verschiedene Altersbereiche und Zustände, darunter unter 13, 13 bis 15, 16 bis 17 und Erwachsene. Auch ein Widerruf der App-Einwilligung kann simuliert werden. Die vollständigen Abläufe stehen in der Apple-Dokumentation zum Age-Assurance-Test in der Sandbox.

Schritt 4: Testen Sie die Übergänge

Prüfen Sie jede Altersgruppe separat. Achten Sie nicht nur auf die Benutzeroberfläche. Ein Feed kann zwar ausgeblendet sein, aber weiterhin über einen direkten Deep Link, eine Cache-Datei oder einen API-Endpunkt erreichbar bleiben.

Testen Sie außerdem:

  • Ab- und erneute Anmeldung;
  • Gerätewechsel;
  • Offline-Modus;
  • Cache-Löschung;
  • Änderung der Altersfreigabe;
  • Widerruf einer Einwilligung;
  • regionale Einstellungen;
  • iPhone-, iPad- und Mac-Build.

Schritt 5: Speichern Sie den Nachweis

Halten Sie Build-Nummer, Betriebssystem, Xcode-Version, Sandbox-Szenario, erwartetes Verhalten und tatsächliches Verhalten fest. Ergänzen Sie Screenshots oder Protokolle nur dort, wo sie für die Entscheidung erforderlich sind.

Ihre Abnahmeliste:

  • [ ] Die Funktionsakte des aktuellen Releases ist gespeichert.
  • [ ] Die Antwort in App Store Connect wurde gespeichert.
  • [ ] Produktbeschreibung und Online-Funktion stimmen überein.
  • [ ] Öffentliche Feeds wurden einzeln geprüft.
  • [ ] Kommentare, Reaktionen und Empfehlungen wurden geprüft.
  • [ ] Unter-13-Szenario sperrt soziale Funktionen vollständig.
  • [ ] Das Verhalten für 13 bis 15 ist dokumentiert.
  • [ ] Erwachsene erhalten nur die vorgesehenen Funktionen.
  • [ ] Fehlende Altersdaten führen nicht zur versehentlichen Freischaltung.
  • [ ] Einwilligungswiderruf wurde getestet.
  • [ ] Alle unterstützten Plattformen wurden geprüft.
  • [ ] Build, App-Store-Eintrag und Testprotokoll gehören zusammen.
  • [ ] Produkt- und Technikverantwortliche haben gemeinsam freigegeben.

Für größere Teams kann zusätzlich die Apple-Dokumentation zur App-Store-Connect-API für Altersfreigaben relevant sein. Eine automatisierte Übertragung der Antworten ersetzt jedoch keine fachliche Prüfung der Produktfunktionen.

6. Beziehen Sie mehrere Plattformen und alternative Verteilung ein

Die Altersfreigabe darf nicht nur anhand der iPhone-Version beurteilt werden. Prüfen Sie jede Plattform, die unter derselben App-Zuordnung veröffentlicht wird:

  • iPhone;
  • iPad;
  • macOS;
  • gegebenenfalls weitere unterstützte Apple-Plattformen.

Achten Sie auf unterschiedliche Feature Flags, Backend-Berechtigungen und Benutzeroberflächen. Wenn die iPad-Version einen öffentlichen Feed besitzt, die Mac-Version aber nur private Inhalte zeigt, dokumentieren Sie diese Abweichung. Verwenden Sie nicht automatisch die Plattform mit den geringsten Funktionen als Stellvertreter für alle Versionen.

Apple hat außerdem bestätigt, dass die neuen Angaben ab September 2026 bei der Notarisierung von Apps für alternative Vertriebswege relevant sind. Das bedeutet nicht, dass der Altersfragebogen jede regionale Rechtsfrage ersetzt. Datenschutz, Jugendschutz, Einwilligungen und regionale Vertriebsregeln bleiben eigenständige Prüfungen.

Behandeln Sie den Fragebogen daher als Teil eines Release-Gates:

  1. Produktfunktion geprüft.
  2. Alterslogik geprüft.
  3. Metadaten gespeichert.
  4. Plattformen verglichen.
  5. Einreichungs- oder Notarisierungsprozess kontrolliert.

7. Wählen Sie die passende Testumgebung

Ein eigener Mac ist sinnvoll, wenn Sie dauerhaft hohe Build-Last erzeugen, physische Geräte anschließen oder langfristig dieselbe Entwicklungsumgebung benötigen. Er bietet direkte Kontrolle über Schlüsselbund, Debugging-Geräte und lokale Daten.

Eine getrennte Mac-Umgebung ist interessant, wenn Sie:

  • einen Beta-Systemstand testen müssen;
  • Xcode nicht auf dem Produktionsgerät installieren wollen;
  • einen zweiten Sandbox- oder Signierungskontext benötigen;
  • mehrere Entwickler mit einem reproduzierbaren Setup versorgen;
  • einen Testaufbau nach dem Release wieder entfernen möchten.

Die aktuelle Lösung hat dabei typische Schwächen. Ein gemeinsam genutztes Hauptgerät verändert häufig die lokale Toolchain. Ein zweiter physischer Mac bindet Kapital und braucht eigene Pflege. Ein beliebiger Cloud-Desktop kann bei Netzwerkunterbrechungen, fehlendem Gerätezugriff oder unklaren Kontoberechtigungen die Abnahme erschweren.

Für eine kurzfristige Altersprüfung kann eine getrennte Umgebung dennoch sinnvoller sein als ein Eingriff in das Produktionsgerät. Prüfen Sie vorab Xcode-Version, Systemversion, Apple-ID- und Teamrechte, Schlüsselverwaltung, Datenschutzanforderungen sowie die Möglichkeit, Testprotokolle eindeutig dem Build zuzuordnen.

Eine getrennte Mac-Umgebung für App-Entwicklung kann dabei als technische Option dienen. Wenn Ihr Team in einer bestimmten Region arbeitet, können Sie zusätzlich die MACCOME-Optionen für Silicon Valley prüfen. Für langfristige, schwere Builds oder direkte Hardwaretests bleibt ein eigener Mac oft die bessere Wahl.

Wenn Ihr Hauptgerät nicht ohne Risiko auf die erforderliche Xcode- oder Systemumgebung wechseln kann, beginnen Sie mit einer isolierten Prüfung. Entscheiden Sie danach, ob Sie ein eigenes Gerät benötigen oder nur für den Projektzeitraum eine getrennte Mac-Umgebung aktivieren. Lassen Sie die Antworten in App Store Connect niemals nur von der Betriebsseite eintragen: Produktverantwortliche und technische Verantwortliche sollten die drei Punkte gemeinsam bestätigen — Fragebogen, Code und Einreichungsnachweis.