iOS 27.2 ATT-Hinweise in der EU prüfen: Checkliste 2026

iOS 27.2 ATT-Hinweise in der EU prüfen, ohne Tracking-Regeln zu verwechseln

Der entscheidende Prüfpunkt ist nicht, ob eine App in der EU verfügbar ist, sondern ob sie nach Apples Definition um Erlaubnis zum Tracking bitten muss. Apples neue EU-Darstellung ändert diese fachliche Vorprüfung nicht automatisch. Apple beschreibt Tracking als Verknüpfung von Nutzerdaten aus einer App mit Daten aus Apps, Websites oder Offline-Eigenschaften anderer Unternehmen, wenn dies für gezielte Werbung oder Werbemessung geschieht; auch eine Weitergabe an einen Datenhändler kann relevant sein. Prüfen Sie deshalb tatsächliche Datenflüsse und SDK-Konfigurationen, nicht nur die Formulierung im Marketingtext. Maßgeblich ist Apples Erläuterung zu Datenschutz und Datennutzung.

Die Unterscheidung verhindert zwei gegensätzliche Fehler: Eine App ohne ATT-relevantes Tracking zeigt keinen Berechtigungsdialog allein deshalb, weil sie im EU-Raum angeboten wird. Umgekehrt wird ein tatsächlich erforderlicher ATT-Ablauf nicht dadurch entbehrlich, dass eine App eine eigene Erklärung vor den Systemdialog setzt oder die neue Systemdarstellung verwendet. Die Dokumentation des AppTrackingTransparency-Frameworks beschreibt den Systemrahmen; Apples Definition der Tracking-Aktivität bestimmt, ob der Anwendungsfall überhaupt in diesen Ablauf fällt.

Prüfen Sie dafür den Datenweg vom Gerät bis zu den Empfängern: Welche Identifikatoren erhebt die App? Werden sie mit Daten anderer Unternehmen verknüpft? Wer erhält sie, zu welchem Zweck und über welche eingebundenen SDKs? Eine Erklärung wie „Wir verwenden Daten zur Verbesserung des Angebots“ beantwortet diese Fragen nicht ausreichend, wenn tatsächlich eine Verknüpfung für Werbezwecke stattfindet.

Zuständigkeit nach Teamrolle festlegen

Die Abnahme wird genauer, wenn sie nicht als allgemeiner „EU-Popup-Test“ organisiert wird. Produktverantwortliche klären den Anwendungsfall, iOS-Entwickler prüfen Aufruf und Rückgabestatus, Datenschutzverantwortliche kontrollieren die Erklärung und Lokalisierung, und Testverantwortliche halten Gebiet sowie Gerätezustand fest. Bei einer kleinen App kann eine Person mehrere Aufgaben übernehmen; die Prüfergebnisse sollten dennoch getrennt erfasst werden.

Für die Vorprüfung eignet sich eine kurze Zuordnung:

• Produkt und Datenverantwortung: Dokumentieren, ob und wie Daten appübergreifend verknüpft oder an andere Unternehmen weitergegeben werden.
• iOS-Implementierung: Den vorhandenen ATT-Aufruf, den Nutzungshinweis und die Verarbeitung des zurückgegebenen Status prüfen.
• Datenschutz und Lokalisierung: Sicherstellen, dass System- und Zusatztexte den tatsächlichen Datenfluss verständlich beschreiben.
• Test und Release: Systemversion, Testgebiet, Gerätestatus und sichtbare Oberfläche so festhalten, dass ein späterer Regressionstest vergleichbar ist.

Die Prüfung sollte nicht mit einer angenommenen Länderzugehörigkeit beginnen. Apple unterscheidet zwischen der Verfügbarkeit einer optionalen alternativen Darstellung in der EU und Ländern, in denen diese alternative Version als einzige anwendbare Systemdarstellung genannt wird. Daraus folgt nicht, dass ein beliebiger Test mit geänderter Gerätesprache oder einem angenommenen Standort die Berechtigung zur Darstellung nachweist. Die konkrete Bedingung ist anhand der aktuellen Apple-Seite zu User Privacy and Data Use zu verifizieren.

Vertriebsgebiet und Systemdarstellung getrennt abnehmen

Apples Datenschutzinformationen nennen Frankreich, Deutschland, Italien, Polen und Rumänien als Länder, in denen die alternative ATT-Darstellung die anwendbare einzige Systemdarstellung ist. Für andere Gebiete innerhalb der EU beschreibt Apple sie als auswählbare Alternative. Die Ländernennung ist eine Aussage über die von Apple dokumentierte Systemdarstellung, keine Rechtsauskunft und kein Ersatz für die Prüfung, ob das eigene Produkt ATT benötigt.

Für jeden Testfall sollten mindestens Gebiet, Systemversion, App-Build, Sprach- und Regionseinstellung sowie Ergebnis festgehalten werden. Die genauen Kriterien, anhand derer Apple eine Nutzer- oder Gebietssituation behandelt, sind nicht durch einen frei gewählten Simulatorstandort beliebig nachstellbar. Deshalb muss das Testprotokoll klar zwischen „im Test beobachtet“ und „für alle Nutzer bestätigt“ unterscheiden.

ATT-Aufruf, Erklärung und Nutzerstatus voneinander abgrenzen

Für Apps, die ATT verwenden, sind mindestens drei Dinge auseinanderzuhalten: die von Apple geforderte Beschreibung des Tracking-Zwecks, der Aufruf der Systemberechtigungsanfrage und ein möglicher ergänzender Erklärungsschritt in der EU-Darstellung. Die Schlüssel NSUserTrackingUsageDescription und NSUserTrackingMarkdownUsageDescription sind nicht austauschbar. Apple dokumentiert NSUserTrackingUsageDescription als Erklärung, die mit der ATT-Anfrage verbunden ist; prüfen Sie den Wert in der Dokumentation zum Information-Property-List-Schlüssel.

Die zusätzliche Markdown-Erklärung ist nicht als allgemeine Pflicht für jede App zu behandeln. Sie kommt nur für den dafür unterstützten ergänzenden Informationsablauf in Betracht. Kontrollieren Sie anhand der aktuellen Apple-Dokumentation, ob die App den erweiterten Systemdialog verwendet, ob der Schlüssel korrekt eingebunden ist und welche Formatierung unterstützt wird. Ein selbst gestalteter Bildschirm vor der Systemanfrage kann Nutzern Kontext geben, ist aber nicht selbst die ATT-Systemberechtigung.

Auch der Text sollte dem wirklichen Datenfluss entsprechen. Eine Aussage, dass Daten ausschließlich lokal bleiben, wäre irreführend, wenn ein Werbe-SDK Kennungen an ein anderes Unternehmen überträgt. Ein Zusatztext sollte den Zweck konkret erklären und darf keine Zustimmung als Voraussetzung für eine nicht tatsächlich gesperrte Grundfunktion darstellen. Prüfen Sie Übersetzungen außerdem auf denselben Sinn wie den Ausgangstext; eine gut klingende Lokalisierung darf den Zweck weder verschleiern noch erweitern.

Der Rückgabestatus ist dabei aussagekräftiger als die reine Beobachtung, ob ein Dialog erschien. Apple unterscheidet Zustände wie noch nicht entschieden, autorisiert, abgelehnt oder eingeschränkt. Erfassen Sie den Status über den vorgesehenen API-Weg und protokollieren Sie ihn ohne unnötige personenbezogene Daten. Wenn eine Anfrage nicht angezeigt wird, muss zuerst geklärt werden, ob bereits eine Entscheidung vorliegt, ob eine Geräteeinschränkung wirkt oder ob die App den erwarteten Ablauf überhaupt erreicht hat.

Rückfragen und erneute Anfragen gezielt testen

Die 27.2-Beta dokumentiert für EU-Nutzer eine jährliche Möglichkeit zur erneuten ATT-Anfrage. Das ist als Beta-Aussage mit der jeweils aktuellen Apple-Beschreibung in den Release Notes abzugleichen, nicht als unveränderliche Zusage für jede künftige iOS-Version. Leiten Sie daraus keine eigene Wiederholungslogik ab, die unabhängig von Apples Systemverhalten beliebig häufig einen Dialog aufruft.

Testen Sie mindestens die folgenden Ausgangslagen getrennt:

1. Noch keine Entscheidung: Prüfen, ob der vorgesehene App-Ablauf die Anfrage auslöst und ob die richtige Systemdarstellung erscheint.
2. Zustimmung erteilt: Kontrollieren, ob die App den Status korrekt übernimmt und nur die dadurch erlaubten Abläufe fortsetzt.
3. Anfrage abgelehnt: Verifizieren, dass die App die Entscheidung respektiert und nicht durch eigene Dialoge Druck aufbaut.
4. Eingeschränkter Zugriff oder deaktivierte Anfragen: Festhalten, ob Geräteeinstellungen oder Einschränkungen die sichtbare Systemanfrage verhindern.
5. Erneute Anfrage im EU-Kontext: Die von Apple dokumentierte jährliche Bedingung in einer geeigneten Testkonfiguration prüfen und die verwendete Methode zur Herstellung des Ausgangszustands protokollieren.

Die ATT-Dokumentation zum Autorisierungsstatus sollte neben dem sichtbaren Bildschirm ausgewertet werden. Für jeden Fall gehört ins Protokoll, ob der Dialog erschien, welcher Status zurückkam und welche Folgeaktion die App ausführte. Verwenden Sie keine echten Nutzerkonten oder produktiven Kennungen, um einen Testzustand künstlich herzustellen. Das Zurücksetzen einer App, das Verwenden eines anderen Geräts oder ein geänderter Testaccount kann andere Bedingungen schaffen; notieren Sie deshalb genau, was zurückgesetzt wurde.

Abnahme in Xcode und vor der Veröffentlichung reproduzierbar machen

Eine aussagekräftige Freigabe besteht nicht nur aus einem Screenshot. Sie verbindet den reproduzierbaren Build mit einem dokumentierten Testfall und der beobachteten Statusverarbeitung. Für Teams, die Xcode aktualisieren, sind Beta und endgültige Werkzeugversion ausdrücklich auseinanderzuhalten. Apples Xcode-27.2-Beta-Release-Notes sind vor der Festlegung einer Werkzeugversion zu prüfen; die Versionsnummer allein belegt weder, dass ein bestimmtes Projekt unverändert baut, noch dass eine reale EU-Gebietsbedingung simuliert werden kann.

Der folgende Ablauf lässt sich als Freigabeschritt in ein Team-Wiki oder ein internes Testprotokoll übernehmen:

1. Datenfluss feststellen. SDKs, Kennungen, Empfänger und Verwendungszweck prüfen. Als Ergebnis festhalten, ob nach Apples Definition ein ATT-relevantes Tracking vorliegt.
2. Build-Grundlage einfrieren. App-Commit, Build-Konfiguration, verwendete Xcode-Version und Zielsystemversion dokumentieren. Bei einer Beta die Kennzeichnung „Beta“ ausdrücklich mitführen.
3. Plist und Texte kontrollieren. NSUserTrackingUsageDescription im tatsächlich gebauten App-Bundle prüfen; eine ergänzende Markdown-Erklärung nur dann aufnehmen, wenn der verwendete Ablauf sie erfordert und die Apple-Vorgaben erfüllt sind.
4. Gebietstest festlegen. Gewünschtes Auslieferungsgebiet, Testgerät, Sprache und Regionseinstellungen getrennt notieren. Nicht aus einer einzelnen Geräteeinstellung auf die globale Verteilung schließen.
5. Statusfälle abarbeiten. Unentschieden, Zustimmung, Ablehnung und Einschränkungen als eigenständige Fälle testen. Bei EU-Tests zur jährlichen erneuten Anfrage zusätzlich den vorgesehenen Ausgangszustand dokumentieren.
6. Systemdarstellung und Rückgabe vergleichen. Sichtbaren Text, Zusatzinformationen, Rückgabestatus und App-Verhalten gemeinsam kontrollieren; ein Screenshot allein ist kein vollständiger Nachweis.
7. Freigabeakte sichern. App-Build, Testbedingungen, Textversionen, Gebiet, Ergebnis und offene Abweichungen aufbewahren. Nach einer Änderung an Beta, API oder Apple-Regeln nur die betroffenen Fälle gezielt wiederholen und die Quelle erneut prüfen.

Ein kompaktes Protokoll kann beispielsweise so aussehen:

App-Build:          <Commit oder Build-Kennung>
Xcode:              <Version und Beta-/Release-Kennzeichnung>
iOS/iPadOS:         <Systemversion>
Testgebiet:         <dokumentierte Testbedingung>
ATT-Ausgangsstatus: <Status vor dem Ablauf>
Systemdarstellung:  <beobachtet / nicht beobachtet>
Rückgabestatus:     <API-Ergebnis>
Texte geprüft:      <NSUserTrackingUsageDescription / Zusatztext>
Ergebnis:           <bestanden / Fehler mit Reproduktionsschritten>

Bei einer Remote-Mac-Umgebung bleibt die Testgrenze dieselbe: Sie kann für macOS-Werkzeuge und Xcode-Arbeit dienen, aber die Herkunft des Macs belegt keine regionale Berechtigung auf dem iOS-Gerät. Wer seine Werkzeugumgebung bewertet, kann sich zunächst über die Remote-Mac-Angebote von NodeMini informieren und die benötigte Systemversion, den Zugriff auf Testgeräte sowie den konkreten Testablauf gegen die eigenen Anforderungen abgleichen. Eine Testnotiz sollte stets festhalten, welche Schritte lokal auf dem iOS-Gerät und welche auf dem Mac ausgeführt wurden.

Häufige Fragen zur EU-Abnahme von ATT

Was ändert sich an den ATT-Hinweisen in iOS 27.2?

Die iOS- und iPadOS-27.2-Beta ergänzt eine alternative Systemdarstellung für ATT in der EU und eine Möglichkeit zur jährlichen erneuten Anfrage bei EU-Nutzern. Das ändert nicht automatisch die Definition von Tracking oder die Voraussetzung, dass eine App eine Berechtigung benötigt. Da es sich um Beta-Verhalten handelt, sollten Sie vor einer Veröffentlichung die aktuellen Apple Release Notes und Tests mit der vorgesehenen Systemversion heranziehen.

In welchen EU-Ländern gilt die alternative ATT-Darstellung?

Apple nennt Frankreich, Deutschland, Italien, Polen und Rumänien als Länder, in denen die alternative Version die anwendbare einzige Systemdarstellung ist. Für andere EU-Gebiete beschreibt Apple die alternative Darstellung als wählbare Möglichkeit. Prüfen Sie die aktuelle Apple-Dokumentation und testen Sie die tatsächliche Auslieferungs- und Gerätebedingung; der Aufenthaltsort eines Testers allein ist kein belastbarer Nachweis für die Gebietsberechtigung.

Welche Erklärung gehört in NSUserTrackingMarkdownUsageDescription?

Die ergänzende Markdown-Erklärung ist nicht pauschal für jede App verpflichtend und ersetzt weder NSUserTrackingUsageDescription noch die ATT-Berechtigungsanfrage. Verwenden Sie sie nur, wenn die ergänzende Apple-Systemdarstellung eingesetzt wird und die aktuelle Dokumentation dies für den konkreten Ablauf unterstützt. Der Inhalt sollte verständlich und wahrheitsgemäß den Tracking-Zweck erklären, ohne Zustimmung durch Druck oder ein unbelegtes Funktionsversprechen zu fördern.

Ist nach einer ATT-Ablehnung eine erneute Anfrage nach einem Jahr möglich?

Apple beschreibt für EU-Nutzer eine jährliche Möglichkeit zur erneuten Anfrage. Behandeln Sie das nicht als Freigabe für wiederholte Dialoge nach eigenem Zeitplan: Die maßgeblichen Bedingungen und das Verhalten hängen von der aktuellen Apple-Regelung und dem tatsächlichen Autorisierungsstatus ab. Dokumentieren Sie den Status und testen Sie den Ablauf mit geeigneten Testbedingungen, statt aus einem nicht angezeigten Dialog auf eine neue Berechtigung zu schließen.

Für den nächsten Testlauf die passende Mac-Umgebung wählen

Ein vorhandener Entwicklungsrechner ist oft die einfachste Wahl, wenn bereits eine kompatible macOS- und Xcode-Umgebung verfügbar ist und Tests nur gelegentlich anstehen. Für dauerhaft wiederholte Builds kann ein eigener Mac sinnvoll sein, besonders wenn lokale Geräteverbindungen oder verlässliche Kontrolle über die Hardware erforderlich sind. Ein zusätzlicher Rechner bindet jedoch Kapital, muss gepflegt werden und hilft nicht, wenn das Team den benötigten Testaufbau nur für eine begrenzte Abnahmephase braucht. Allgemeine Informationen zum Bestellen eines Mac mini über NodeMini können bei der Abwägung zwischen eigener Hardware und einem zeitlich begrenzten Bedarf helfen.

Wenn das Team eine separate macOS-Umgebung nur für Xcode-Builds und klar eingegrenzte Tests benötigt, kann ein gemieteter Mac von NodeMini die flexiblere Option sein, ohne einen Kauf allein für diesen Release-Schritt vorauszusetzen. Er ersetzt weder ein geeignetes iOS-Testgerät noch den Nachweis der Apple-Gebietsbedingungen; bei langfristiger Dauerlast oder zwingendem Zugriff auf physische Schnittstellen kann eigene Hardware passender sein. Entscheidend ist, zuerst die nötige Systemversion und den tatsächlichen Testweg festzulegen und erst dann zu entscheiden, ob eine temporäre Mac-Umgebung den Aufwand rechtfertigt.