Der Privacy Manifest im Detail: Was als Datenerhebung zählt

Seit dem 1. Mai 2024 muss jede App und jedes Drittanbieter-SDK, das in App Store Connect hochgeladen wird, ein Privacy Manifest enthalten, das die Verwendung von „Required Reason APIs”, das Tracking-Verhalten und die erfassten Datentypen deklariert¹. Das Manifest ist eine Property-List-Datei (PrivacyInfo.xcprivacy), die der App Store bei der Einreichung einliest, gegen eine bekannte Menge datenschutzsensibler APIs validiert und im benutzerseitigen Privacy Nutrition Label anzeigt. Apps, die das Manifest weglassen oder ein datenschutzsensibles API ohne Angabe eines genehmigten Grundes verwenden, werden bei der Einreichung mit ITMS-91053 oder verwandten Codes abgelehnt².

Die meisten Teams behandeln das Manifest als einmalige Compliance-Aufgabe: einmal schreiben, ausliefern, nie wieder anschauen. Das Manifest ist mehr als das. Es ist ein strukturierter Vertrag zwischen App und Apple, der kodifiziert, was die App mit privaten Daten macht, und es ist der einzige Ort, an dem dieser Vertrag in maschinenlesbarer Form existiert. Eine sorgfältige Lektüre offenbart, was Apple als datenschutzsensibel betrachtet (die Oberfläche ist breiter, als die meisten Entwickler erwarten), was der Benutzer im Nutrition Label tatsächlich sieht (granularer, als die meisten Teams annehmen), und was Drittanbieter-SDKs offenlegen müssen (eine echte Verpflichtung, keine Höflichkeit).

TL;DR

• Das Privacy Manifest hat vier Abschnitte auf oberster Ebene: NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes und NSPrivacyAccessedAPITypes³.
• Die Required-Reason-API-Liste umfasst zunächst fünf Kategorien: Datei-Zeitstempel, System-Bootzeit, Speicherplatz, aktive Tastaturen und User Defaults. Jede Kategorie hat eine geschlossene Liste genehmigter Reason Codes; Apps müssen einen auswählen oder so umschreiben, dass das API entfällt⁴.
• Tracking ist eng definiert: das Verknüpfen von Benutzerdaten mit Daten anderer Unternehmen zu Werbezwecken oder die Weitergabe an Datenhändler. Wenn NSPrivacyTracking true ist, muss jede für Tracking verwendete Domain in NSPrivacyTrackingDomains aufgeführt sein³.
• Drittanbieter-SDKs müssen eigene Manifeste mitliefern. Das Manifest der App wird bei der Einreichung mit den Manifesten aller verlinkten SDKs zusammengeführt; fehlende SDK-Manifeste auf der von Apple veröffentlichten Liste blockieren die App⁵.
• Die größte Stolperfalle: UserDefaults-Zugriffe zählen immer als Aufruf eines Required Reason APIs. Ein einfaches UserDefaults.standard.set(...) erfordert einen deklarierten Reason Code.

Die vier Abschnitte

Eine vollständige PrivacyInfo.xcprivacy-Datei enthält vier Schlüssel auf oberster Ebene³. Die Struktur ist eine Property List, die als XML im Rohformat oder über den Privacy-Manifest-Editor von Xcode bearbeitet wird.

NSPrivacyTracking (Boolean)

Deklariert, ob die App oder das SDK den Benutzer über Apps und Websites anderer Unternehmen hinweg trackt. Die semantische Definition orientiert sich an App Tracking Transparency: das Verknüpfen von Benutzerdaten mit Daten anderer Unternehmen zum Zweck zielgerichteter Werbung, der Auslieferung zielgerichteter Werbung oder der Weitergabe von Benutzerdaten an Datenhändler⁶.

Wenn NSPrivacyTracking true ist, muss jede für Tracking verwendete Domain in der NSPrivacyTrackingDomains-Liste aufgeführt sein. Bei false entfällt die Liste (oder bleibt leer).

Die enge Definition ist entscheidend. Viele Apps, die Werbung anzeigen (über Apples eigenes SKAdNetwork oder Nicht-Tracking-Werbe-SDKs), können NSPrivacyTracking als false deklarieren. Tracking ist die Verknüpfung mit externen Daten, nicht das Anzeigen von Werbung.

NSPrivacyTrackingDomains (Array von Strings)

Die Liste der Domains, die die App oder das SDK zu Tracking-Zwecken kontaktiert. Apps, die NSPrivacyTracking als true deklarieren, müssen hier jeden Tracking-Endpunkt aufzählen.

Die Liste wird zur Laufzeit über den App Privacy Report durchgesetzt: Wenn die App eine Domain kontaktiert, die als Tracking eingestuft, aber nicht deklariert ist, weist der App Privacy Report den Benutzer auf die Diskrepanz hin. Wiederholte Verstöße riskieren die Entfernung aus dem App Store.

NSPrivacyCollectedDataTypes (Array von Dictionaries)

Die strukturierte Datenerhebungs-Deklaration, die das Privacy Nutrition Label des App Store speist³. Jeder Eintrag beschreibt einen Datentyp, den die App erhebt, mit Unter-Schlüsseln:

• NSPrivacyCollectedDataType: der Datentyp aus Apples geschlossener Liste (z. B. NSPrivacyCollectedDataTypeName, NSPrivacyCollectedDataTypeEmailAddress, NSPrivacyCollectedDataTypeCrashData).
• NSPrivacyCollectedDataTypeLinked: Boolean, ob die Daten mit der Identität des Benutzers verknüpft sind.
• NSPrivacyCollectedDataTypeTracking: Boolean, ob die Daten für Tracking verwendet werden.
• NSPrivacyCollectedDataTypePurposes: Array, die Zwecke, zu denen die Daten erhoben werden (Analytics, App-Funktionalität, Werbung etc.).

Dieser Abschnitt ist die Wahrheitsquelle für das Privacy Nutrition Label. Die Kategorien „Daten, die zur Verfolgung verwendet werden” und „Mit Ihnen verknüpfte Daten” im Nutrition Label werden aus diesen Flags berechnet. Ungenaue Deklarationen führen zu ungenauen Nutrition Labels und riskieren App-Store-Durchsetzungsmaßnahmen.

NSPrivacyAccessedAPITypes (Array von Dictionaries)

Die Required-Reason-API-Deklaration. Jeder Eintrag verbindet eine Required-Reason-API-Kategorie mit einer Menge genehmigter Reason Codes⁴.

<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>C617.1</string>
        </array>
    </dict>
</array>

Die Reason Codes sind geschlossene Listen. Die App wählt einen oder mehrere aus Apples veröffentlichter Liste pro Kategorie aus; beliebige Strings werden bei der Einreichung abgelehnt.

Die fünf Required-Reason-API-Kategorien

Apples ursprüngliche Liste von 2024 definierte fünf Kategorien von APIs, die einen deklarierten Grund erfordern⁴:

NSPrivacyAccessedAPICategoryFileTimestamp

Wird durch jedes API ausgelöst, das die Erstellungs-, Änderungs- oder Zugriffszeit einer Datei zurückgibt. Häufige Einstiegspunkte: URL.resourceValues(forKeys: [.creationDateKey, ...]), FileManager.attributesOfItem(atPath:), stat(), fstat(), lstat(). Die vier genehmigten Gründe⁴:

• DDA9.1. Datei-Zeitstempel dem Gerätebenutzer anzeigen. Aus diesem Grund abgerufene Informationen dürfen das Gerät nicht verlassen.
• C617.1. Auf Datei-Metadaten (Zeitstempel, Größe etc.) für Dateien innerhalb des App-Containers, App-Group-Containers oder CloudKit-Containers zugreifen.
• 3B52.1. Auf Datei-Metadaten für Dateien oder Verzeichnisse zugreifen, denen der Benutzer ausdrücklich Zugriff gewährt hat (Document Picker etc.).
• 0A2A.1. Drittanbieter-SDK-Wrapper, die nur dann auf Datei-Zeitstempel-APIs zugreifen, wenn die App den Wrapper aufruft. Nur für SDKs.

Die meisten Apps verwenden C617.1 (Zugriff auf den eigenen Container) für interne Dateiverwaltung. Apps, die Datums-Werte in der Benutzeroberfläche anzeigen, verwenden DDA9.1. Apps, die vom Benutzer freigegebene Dateien lesen (Document Picker, Share-Extension-Targets), verwenden 3B52.1. SDK-Autoren verwenden ausschließlich 0A2A.1.

NSPrivacyAccessedAPICategorySystemBootTime

Wird durch mach_absolute_time(), mach_continuous_time() und verwandte Uptime-APIs ausgelöst. Das Datenschutzproblem: Die System-Bootzeit ist ein fingerprintfähiges Signal, mit dem ein Gerät über Neuinstallationen hinweg identifiziert werden kann. Die drei genehmigten Gründe⁴:

• 35F9.1. Auf die System-Bootzeit zugreifen, um Zeitintervalle zwischen App-Ereignissen zu messen oder Timer zu ermöglichen.
• 8FFB.1. Auf die System-Bootzeit zugreifen, um absolute Zeitstempel von Ereignissen innerhalb der App zu berechnen.
• 3D61.1. System-Bootzeit-Informationen in einem optionalen Fehlerbericht hinzufügen, den der Benutzer zum Absenden auswählt.

Die meisten Apps verwenden 35F9.1 zur Performance-Messung. 8FFB.1 deckt Fälle ab, in denen die App Ereignis-Zeitstempel aus der Bootzeit ableitet (relativ zur Gerätesitzung). Beachten Sie, dass Date() und Date.now diese Kategorie nicht auslösen; sie verwenden eine andere Zeitquelle. Die Kategorie deckt speziell Aufrufe der mach_*_time-Familie ab.

NSPrivacyAccessedAPICategoryDiskSpace

Wird durch APIs ausgelöst, die die Festplattenkapazität oder den freien Speicherplatz zurückgeben, einschließlich URL.resourceValues(forKeys: [.volumeAvailableCapacityKey, ...]) und der Dateisystem-Attribute-APIs von NSFileManager. Das Datenschutzproblem: Speicherplatz-Muster sind ein fingerprintfähiges Signal. Die vier genehmigten Gründe⁴:

• 854F.1. Speicherplatz-Informationen dem Gerätebenutzer anzeigen, entweder in Dateneinheiten oder in Medienzeiteinheiten.
• E174.1. Speicherplatz prüfen beim Schreiben von Dateien oder zur Verwaltung von wenig Speicherplatz (Entscheidung, ob ein Asset heruntergeladen wird, Aufräumen zwischengespeicherter Dateien).
• 7D9E.1. Speicherplatz-Informationen in einen optionalen Fehlerbericht aufnehmen, den der Benutzer zum Absenden auswählt.
• B728.1. Apps für Gesundheitsforschung, die wenig Speicherplatz erkennen und Teilnehmer darüber informieren, dass die Studiendatenerhebung beeinträchtigt ist.

NSPrivacyAccessedAPICategoryActiveKeyboards

Wird durch UITextInputMode.activeInputModes ausgelöst. Apps, die diese Liste lesen (typischerweise zur Lokalisierung des Verhaltens oder zur Erkennung der Eingabesprache), müssen einen Grund deklarieren. Die zwei genehmigten Gründe⁴:

• 3EC4.1. Eine benutzerdefinierte Tastatur-App, die die aktiven Tastaturen auf dem Gerät ermittelt.
• 54BD.1. Zugriff auf Informationen zu aktiven Tastaturen, um die Benutzeroberfläche entsprechend anzupassen (typischerweise für eine eingabesprachenbewusste UX).

Die meisten Apps benötigen diese Kategorie nicht. Falls Ihr Code activeInputModes indirekt über eine Drittanbieter-Bibliothek aufruft, deklariert das Manifest dieser Bibliothek den Grund.

NSPrivacyAccessedAPICategoryUserDefaults

Die Kategorie, die fast jede App erfasst. Jeder Zugriff auf UserDefaults (UserDefaults.standard, App-Group-Defaults über init(suiteName:), einzelne set/get-Aufrufe) löst die Anforderung aus⁷. Die vier genehmigten Gründe⁴:

• CA92.1. Auf User Defaults zugreifen, um Daten zu lesen/schreiben, die ausschließlich der App selbst (oder einer ausschließlich mit der App gepaarten App-Erweiterung) gehören.
• 1C8F.1. Auf User Defaults zugreifen, um Daten ausschließlich innerhalb von Apps, App-Erweiterungen und App Clips zu lesen/schreiben, die Mitglieder derselben App Group sind.
• C56D.1. Drittanbieter-SDK-Wrapper, die nur dann auf User-Defaults-APIs zugreifen, wenn die App den Wrapper aufruft. Nur für SDKs.
• AC6B.1. Auf User Defaults zugreifen, um verwaltete App-Konfigurationen abzurufen, die von einem MDM-/IT-Administrator gesetzt wurden, oder um Feedback-Informationen für den Administrator zu speichern.

Fast jede iOS-App verwendet UserDefaults.standard für mindestens einen Zustand (den zuletzt ausgewählten Tab, die bevorzugte Sortierreihenfolge, ein Feature-Flag). Der Grund CA92.1 deckt das ab. Apps, die Zustand über App-Erweiterungen hinweg via App Group teilen, ergänzen 1C8F.1. SDK-Autoren verwenden C56D.1. Apps, die über ein MDM ausgerollt werden und vom Administrator gesetzte Schlüssel lesen (z. B. com.apple.configuration.managed), verwenden AC6B.1.

Der Haken: Ein Drittanbieter-SDK, das UserDefaults berührt, löst die Anforderung im Auftrag der App aus. Das Manifest des SDKs muss den Grund deklarieren. Steht das SDK auf Apples Liste der SDKs, die ein Privacy Manifest mitliefern müssen, blockiert das Fehlen des SDK-Manifests die App.

Tracking-Domains: Validierung zur Laufzeit

NSPrivacyTrackingDomains wird zur Laufzeit über den App Privacy Report durchgesetzt⁶. Wenn eine App NSPrivacyTracking = true deklariert, verfolgt das System jede Netzwerkanfrage und gleicht das Ziel mit der deklarierten Liste ab. Domains, die zu Tracking-Zwecken kontaktiert, aber nicht deklariert sind, erscheinen in den Abschnitten „Häufige Standorte” und „Andere kontaktierte Domains” des App Privacy Reports.

Die Laufzeit-Validierung schafft eine interessante Anreizstruktur. Eine App, die NSPrivacyTracking = false deklariert (kein Tracking), aber dabei beobachtet wird, bekannte Tracking-Domains zu kontaktieren, wird im App Privacy Report markiert und riskiert Beschwerden von Benutzern. Der richtige Weg ist eine ehrliche Deklaration.

Bei SDKs deklariert das Privacy Manifest des SDKs sein Tracking-Verhalten. Das Manifest der App muss die Tracking-Domains des SDKs nicht aufzählen; das Manifest des SDKs tut das bereits. Bei der Einreichung führt Apple die Manifeste zusammen und prüft die Konsistenz.

SDK-Manifeste: eine echte Verpflichtung

Drittanbieter-SDKs in zwei Kategorien müssen ein Privacy Manifest mitliefern⁵:

1. SDKs auf Apples veröffentlichter Liste der SDKs, die ein Privacy Manifest erfordern. Die Liste umfasst Firebase Analytics, Google Mobile Ads, Adjust, Segment, AppsFlyer und etwa 30 weitere zum Stand iOS 26.
2. SDKs, die als vorkompilierte Binärdateien (XCFrameworks, statische Bibliotheken) verteilt werden, gegen die die App linkt.

Die Einreichung einer App, die ein erforderliches SDK ohne dessen Manifest verlinkt, scheitert mit einem Fehler aus der ITMS-91xxx-Reihe, der ein fehlendes Privacy Manifest, eine fehlende Manifest-Signatur oder eine fehlende API-Deklaration im Namensraum des SDKs abdeckt². Die Lösung ist entweder ein Update auf eine Version des SDKs, die ein Manifest mitliefert, oder das Entfernen des SDKs.

Bei Erstanbieter-SDKs (Ihr Team liefert ein internes Framework, das von Ihren Apps genutzt wird) können Sie das Manifest weglassen, sofern das Framework nicht auf Apples Liste steht. Der pragmatische Schritt ist, dennoch eines mitzuliefern: Künftige Erweiterungen der Apple-Liste, künftige Audits und künftige Wiederverwendung durch Dritte profitieren alle davon, ein Manifest bereits an Ort und Stelle zu haben.

Häufige Stolperfallen

Fünf wiederkehrende Fehlermuster aus den App-Store-Ablehnungsprotokollen:

1. Vergessene UserDefaults-Deklaration. Die häufigste Ablehnung. Die App verwendet @AppStorage (was UserDefaults einpackt) an einer unscheinbaren Stelle, das Manifest deklariert es nicht. Lösung: Jede App, die @AppStorage, UserDefaults oder einen Wrapper darum verwendet, benötigt NSPrivacyAccessedAPICategoryUserDefaults mit CA92.1.

2. Versteckter Datei-Zeitstempel-Zugriff über URLResourceValues. Code, der Datei-Änderungsdaten über URL.resourceValues(forKeys: [.contentModificationDateKey]) liest, löst die Kategorie aus, auch wenn die Aufrufstelle nicht wie ein stat-Aufruf aussieht.

3. Erwartungen an SDK-Manifeste. App-Teams gehen davon aus, dass das Manifest des SDKs die Aufgabe des SDK-Autors ist. Das stimmt, aber die Einreichung des App-Teams scheitert, bis das SDK eines mitliefert.

4. NSPrivacyTracking = false trotz verlinktem Tracking-SDK. Das Verlinken von Firebase Analytics oder Google Mobile Ads mit Standardeinstellungen löst oft Tracking-Verhalten aus. Wenn das Manifest der App NSPrivacyTracking = false deklariert, das Manifest des SDKs aber true, entsteht ein Widerspruch, den die Zusammenführung markiert.

5. Veraltete Reason Codes. Apple aktualisiert die genehmigten Reason Codes gelegentlich. Codes, die 2024 gültig waren, können ersetzt oder erweitert worden sein. Die Lösung ist, bei jedem Major-Release die aktuell veröffentlichte Liste erneut zu prüfen, statt alte Manifeste fortzuschreiben.

Validierungs-Werkzeuge

Drei Prüfungen, die sich vor der Einreichung lohnen:

Xcodes „Generate Privacy Report”-Workflow im Archiv. Nach Product > Archive bietet der Organizer eine Aktion „Generate Privacy Report”, die einen aggregierten Bericht aus dem Manifest der App und denen aller verlinkten SDKs erstellt. Der Bericht ist genau das, was App Store Connect einliest; ihn lokal auszuführen ist das nächstgelegene Äquivalent zu einem Probelauf vor der Einreichung.

Statische Analyse für Required Reason APIs. Open-Source-Werkzeuge scannen ein Projekt nach den API-Aufrufstellen, die die fünf Kategorien auslösen. Das von der Community gepflegte CLI stelabouras/privacy-manifest parst Swift-Quellcode und xcframework-Binärdateien, um deklarierte und nicht deklarierte Reason Codes sichtbar zu machen; crasowas/app_store_required_privacy_manifest_analyser bietet einen ähnlichen Scan. Beides liefert einen nützlichen Vor-Einreichungs-Check für fehlende Deklarationen.

Abgleich mit dem App Privacy Report. Führen Sie die App im App-Privacy-Report-Modus von iOS aus (Einstellungen > Datenschutz & Sicherheit > App-Datenschutzbericht). Domains, die die App kontaktiert, erscheinen im Bericht; gleichen Sie diese mit den Tracking-Deklarationen des Manifests ab.

Was dieses Muster für iOS-26+-Apps bedeutet

Drei Erkenntnisse.

1. Behandeln Sie das Privacy Manifest als strukturierten Vertrag, nicht als Checkbox. Das Manifest ist die einzige maschinenlesbare Aufzeichnung dessen, was die App mit privaten Daten macht. Es einmal aufzubauen und für immer zu ignorieren, ist der Weg zu einer abgelehnten Einreichung sechs Monate später, wenn ein SDK-Update die erforderliche Oberfläche des Manifests stillschweigend erweitert.

2. Auditieren Sie bei jedem Release Ihre Zugriffe auf UserDefaults und Datei-Zeitstempel. Das sind die zwei Kategorien, die mit der Codebasis stillschweigend wachsen. Eine bei einem Refactor hinzugefügte SwiftUI-View mit @AppStorage zieht NSPrivacyAccessedAPICategoryUserDefaults in den Geltungsbereich; eine später hinzugefügte Funktion zur Dateiauflistung zieht NSPrivacyAccessedAPICategoryFileTimestamp mit. Validieren Sie jedes Mal neu.

3. Verwenden Sie SDKs, die ihre eigenen Manifeste mitliefern. Beim Bewerten eines Drittanbieter-SDKs sind das Vorhandensein und die Qualität seines Privacy Manifests inzwischen ein Qualitätssignal. SDKs ohne Manifeste zwingen das App-Team, mit dem Upstream zu kämpfen; SDKs mit Manifesten fügen sich sauber in die Zusammenführung ein.

Das vollständige Apple-Ökosystem-Cluster: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung von Laufzeit und Tooling-LLM; drei Oberflächen; das Single-Source-of-Truth-Muster; Two MCP Servers; Hooks für die Apple-Entwicklung; Live Activities; der watchOS-Laufzeitvertrag; SwiftUI-Internals; RealityKits räumliches Mental Model; SwiftData-Schema-Disziplin; Liquid-Glass-Muster; Multi-Plattform-Auslieferung; die Plattform-Matrix; Vision-Framework; Symbol Effects; Core-ML-Inferenz; Writing Tools API; Swift Testing; worüber ich mich weigere zu schreiben. Der Hub befindet sich unter der Apple-Ökosystem-Serie. Für den breiteren Kontext zu iOS mit KI-Agenten siehe den iOS-Agent-Development-Leitfaden.

FAQ

Was ist der Unterschied zwischen NSPrivacyTracking und NSPrivacyCollectedDataTypeTracking?

NSPrivacyTracking ist der App-weite Boolean: Trackt diese App Benutzer (im Sinne von Apples enger Definition) überhaupt? NSPrivacyCollectedDataTypeTracking gilt pro Datentyp: Werden für einen bestimmten Datentyp, den die App erhebt, diese Daten zum Tracking verwendet? Eine App kann Daten erheben, ohne zu tracken (Analytics, die nicht über Unternehmen hinweg verknüpft werden); das pro-Typ-Flag erfasst, ob jeder einzelne Datentyp zum Tracking-Verhalten beiträgt.

Benötige ich ein Privacy Manifest für eine rein interne TestFlight-App?

Ja. Die Durchsetzung des Privacy Manifests greift bei der Einreichung an App Store Connect, einschließlich TestFlight-Builds. Eine interne Beta ohne Manifest scheitert an derselben ITMS-91053-Prüfung wie ein öffentliches Release.

Was passiert, wenn ich ein Required Reason API deklariere, ohne es zu verwenden?

Funktional nichts. Das Manifest deklariert eine Obergrenze für die API-Oberfläche; eine ungenutzte Kategorie zu deklarieren ist harmlos. Die Kosten liegen in der Dokumentations-Drift: Künftige Maintainer könnten annehmen, die Deklaration spiegele den aktuellen Code wider, obwohl der Aufruf längst entfernt wurde. Der richtige Weg ist, zu deklarieren, was die App tatsächlich verwendet, und das bei jedem Major-Release zu auditieren.

Gibt es Required-Reason-API-Kategorien jenseits der ursprünglichen fünf?

Zum Stand iOS 26 bleiben die ursprünglichen fünf Kategorien (Datei-Zeitstempel, System-Bootzeit, Speicherplatz, aktive Tastaturen, User Defaults) die kanonische Liste⁴. Apple hat im Laufe der Zeit genehmigte Reason Codes innerhalb der Kategorien ergänzt, die Kategorienliste selbst aber nicht erweitert. Beobachten Sie Apples Dokumentationsseite zu Required Reason API für Ergänzungen.

Wie wirkt das Privacy Manifest mit App Tracking Transparency zusammen?

App Tracking Transparency (ATT) regelt die Laufzeit-Berechtigungsabfrage für app-übergreifendes Tracking. Das Privacy Manifest deklariert die Absicht der App statisch. Sie ergänzen einander: Eine App, die app-übergreifendes Tracking betreibt, deklariert NSPrivacyTracking = true im Manifest und fordert zur Laufzeit die ATT-Berechtigung an. Eine App, die NSPrivacyTracking = false deklariert, sollte ATT nicht anfordern (das Fehlen von app-übergreifendem Tracking macht die Abfrage überflüssig).

Quellenverzeichnis