Datenschutz zuerst, dann die Technik: Genau in dieser Reihenfolge betrifft iOS 27 jedes Team, das App-Daten von Minderjährigen verarbeitet. Apple, und ein wachsender Katalog regionaler Gesetze, bekommen mit iOS 27 einen formalen Weg, Ihrer App das Alter eines Nutzers mitzuteilen, bevor Sie überhaupt Daten erheben. Erhebt Ihre App irgendetwas von Minderjährigen, und die meisten Consumer-Apps tun das, ohne es so zu benennen, müssen sich Einwilligungsprozess und Dokumentation ändern. Nicht irgendwann. Für eine wachsende Zahl von Regionen: jetzt.
Da dies ein Compliance-Thema ist, vorab ein Hinweis: Dieser Beitrag ist eine praktische Einordnung für Marketing- und Produktteams, keine Rechtsberatung. Ihre konkreten Pflichten hängen davon ab, wo Ihre Nutzer sitzen und was Ihre App tut — die Details muss ein Anwalt absegnen. Dieser Leitfaden ordnet ein, was iOS 27 einführt, was das für Ihr Tracking und Ihre Segmentierung bedeutet, und liefert eine Checkliste, bevor sich das App-Store-Gate weiter verschärft. Pushwoosh ist eine Customer-Engagement-Plattform, und wo Einwilligung und Datenerhebung Ihre Pushwoosh-Konfiguration berühren, weisen wir konkret darauf hin.
Was iOS 27 tatsächlich einführt
Zwei APIs stehen im Zentrum, und sie greifen ineinander.
Die Declared Age Range API lässt Ihre App eine Altersspanne eines Nutzers abfragen, zum Beispiel 13+, 16+ oder 18+, ohne jemals ein Geburtsdatum abzufragen oder zu speichern. Apple liefert die Spanne; Sie erhalten ein Signal, kein Datum. Das Framework existiert seit iOS 26, mit iOS 27 verschärfen sich die begleitenden Anforderungen und die Durchsetzung.
PermissionKit übernimmt die Seite der elterlichen Einwilligung. Nimmt Ihre App eine wesentliche Änderung vor, die betrifft, wie ein minderjähriger Nutzer sie verwendet, ist PermissionKit der Flow, der die Nutzerin informiert und, in regulierten Regionen, vor Fortsetzung die Zustimmung eines Erziehungsberechtigten einholt.
Der entscheidende Designpunkt: Das System sagt Ihnen, wann das gilt. Über Signale wie isEligibleForAgeFeatures und requiredRegulatoryFeatures zeigt das Betriebssystem an, ob Alterspflichten für einen bestimmten Nutzer greifen und ob Sie die Altersspanne oder die elterliche Einwilligung abfragen müssen. Sie raten nicht pro Nutzer — die Plattform liefert die Anwendbarkeit mit.
Was die Schlagzeile „Pflicht ab September” falsch wiedergibt
An dieser Stelle lohnt sich Präzision, denn die Pflicht ist kein einzelner globaler Schalter, und „Pflicht ab September” ist keine Formulierung, die Apple selbst so verwendet. Es laufen zwei getrennte Dinge, die die Berichterstattung gerne auf einen Stichtag zusammenzieht.
Das Erste ist das App-Store-Review-Gate. Apple verschärft schrittweise, was Ihre Datenschutzdokumentation und Ihr Alters-Handling zeigen müssen, und Apps mit Social- oder User-Generated-Content-Funktionen sollen ein nutzerseitiges Altersgate implementieren, gestützt auf die Declared Age Range API. Das zieht sich über den gesamten iOS-27-Zyklus, statt an einem einzigen Datum umzuschalten — hat Ihre App Social-Funktionen, behandeln Sie es als Aufgabe für das nächste Release, nicht für später.
Das Zweite, mit harten Stichtagen, ist regionales Recht, und es gilt bereits vielerorts. Apple selbst bindet die Declared-Age-Range-Pflichten an konkrete Jurisdiktionen: Altersklassen werden für neue Apple Accounts in Utah seit 6. Mai 2026 und in Louisiana seit 1. Juli 2026 übermittelt, und Apple hat das Blockieren von 18+-Downloads in Australien, Brasilien und Singapur am 24. Februar 2026 begonnen. Weitere Gesetze folgen eigenen Zeitplänen, manche bereits in Kraft, manche verschoben. Die regulatorischen Signale des Systems existieren genau deshalb, weil die Antwort auf „muss ich das für diesen Nutzer tun” von seiner Region und dem aktuellen Stand des dortigen Rechts abhängt.
Praktisch gelesen: Haben Sie Social- oder UGC-Funktionen, oder erheben Sie Daten von Minderjährigen in einer regulierten Region, ist das laufende Arbeit, kein zukünftiges Vorhaben. Trifft beides noch nicht auf Sie zu, wird trotzdem erwartet, dass Ihre Datenschutzdokumentation aktuell bleibt — und die regionale Landkarte wächst, also ist der Aufbau der Fähigkeit jetzt günstiger als das Nachrüsten unter Termindruck später.
Warum das bei Marketing landet, nicht nur bei Legal
Altersverifikation wirkt wie eine Legal-und-Engineering-Aufgabe, bis man verfolgt, was sie berührt. Dann landet sie punktgenau bei Ihrem Tracking und Ihrer Segmentierung.
Erheben Sie Werbe-IDs, feuern Sie automatische Verhaltens-Events oder bauen Sie Segmente auf In-App-Aktivität auf: Ein Alterssignal verändert, was Sie erheben dürfen und über wen. Ein Nutzer in einer geschützten Altersspanne ist niemand, den Sie stillschweigend im selben Behavioral-Tracking und derselben Werbe-ID-Erhebung führen wie einen Erwachsenen. Sobald das Betriebssystem Ihnen mitteilt, dass ein Nutzer in einer regulierten Region minderjährig ist, hört „wir tracken alle gleich” auf, ein vertretbarer Standard zu sein.
Das ist auch der Moment, eine Lücke zu schließen, die viele Apps mitschleppen: unklares oder undokumentiertes Handling von Werbe-IDs (IDFA auf iOS, GAID auf Android). Steht in Ihrer Datendokumentation nicht klar, welche Werbe-IDs Sie erheben und warum, war diese Lücke schon vorher ein Risiko. Mit dem sich verschärfenden Review-Gate über den iOS-27-Zyklus wird sie zum Ablehnungsrisiko. Alters-Erhebung und Werbe-ID-Dokumentation im selben Zug zu fixen ist der effizientere Weg, da beide in denselben Datenschutzhinweisen stehen.
Ihre Compliance-Checkliste
Arbeiten Sie das mit Ihren Legal- und Engineering-Partnern durch:
- Kartieren Sie, wo Ihre Minderjährigen sind. Identifizieren Sie, in welchen Regionen Sie aktiv sind, die bereits Age-Assurance-Gesetze haben, und ob Ihre App Social- oder UGC-Funktionen hat, die das App-Store-Gate regionsunabhängig auslösen.
- Übernehmen Sie die Anwendbarkeits-Signale. Nutzen Sie die OS-Signale, die anzeigen, ob Alterspflichten für einen Nutzer gelten, statt eigene Vermutungen zu bauen. Lassen Sie die Plattform sagen, wann Sie Altersspanne oder Einwilligung abfragen müssen.
- Fragen Sie die Altersspanne ab, nicht das Geburtsdatum. Wo Sie ein Alterssignal brauchen, nutzen Sie die Declared Age Range API, damit Sie eine Spanne erhalten und nie ein Geburtsdatum erheben oder speichern müssen, das Sie anschließend schützen müssten.
- Verdrahten Sie die elterliche Einwilligung für wesentliche Änderungen. Nutzen Minderjährige Ihre App, stellen Sie sicher, dass der Significant-Change-Einwilligungsflow für die Regionen steht, die ihn verlangen.
- Segmentieren Sie Tracking nach Altersspanne. Stellen Sie sicher, dass Nutzer in geschützten Altersspannen von Werbe-ID-Erhebung und Behavioral Tracking ausgeschlossen sind, das für Minderjährige nicht zulässig ist. Das ist eine Datenerhebungs- und Einwilligungs-Konfiguration, keine manuelle Prüfung pro Nutzer.
- Aktualisieren Sie Ihre Datenschutzdokumentation. Bringen Sie Ihre App-Store-Datenschutzhinweise auf den aktuellen Stand, und schließen Sie dabei gleich die Werbe-ID-Dokumentationslücke, damit IDFA- und GAID-Handling klar benannt sind. Das prüft das Review-Gate zuerst.
- Prüfen Sie Ihre Einwilligungstexte. Stellen Sie sicher, dass der Einwilligungstext, den ein Minderjähriger oder Erziehungsberechtigter sieht, dem entspricht, was Sie tatsächlich erheben — im gleichen Geist wie Ihre DSGVO-konforme E-Mail-Praxis.
Altersbewusste Datenerhebung sauber umsetzen mit Pushwoosh
Pushwoosh gibt Ihnen Einwilligungsmanagement und Datenerhebungs-Kontrollen, um Tracking nach Altersspanne zu segmentieren, geschützte Nutzer aus Erhebungen auszuschließen, in denen sie nicht sein dürfen, und Ihr Werbe-ID-Handling dokumentiert und sauber zu halten. Pushwoosh ist DSGVO-konform, SOC 2 Type I und ISO 27001:2022 zertifiziert und betreibt Rechenzentren in der EU und den USA — Compliance-Arbeit ist nie null Aufwand, aber die Datenseite davon sollte nicht der schwierige Teil sein.
