Zum Inhalt springen
AppFoyer
Starten

Ratgeber Nach dem Launch

Die Datenschutzerklärung im Gleichklang mit dem Build halten

Eine Datenschutzerklärung wird einmal geschrieben und veraltet an dem Tag, an dem ein Pull Request ein SDK hinzufügt. Wie Sie das im Pull Request selbst bemerken, mit einer kostenlosen Prüfung, die nur Ihre Build-Dateien liest.

Halten Sie fest, aus welchen SDKs, Datentypen und Berechtigungen Ihre Seiten geschrieben wurden, und vergleichen Sie dann die Build-Dateien jedes Pull Requests mit diesem Stand. Taucht eine Abhängigkeit oder Berechtigung auf, die der festgehaltene Stand nicht enthält, zeigt der Pull Request sie, bevor es das Release tut – solange Datenschutzerklärung und Store-Formulare noch leicht zu aktualisieren sind.

Erledigen Sie das stattdessen in wenigen Minuten

AppFoyer hostet die Seiten, um die es in diesem Ratgeber geht – Datenschutzerklärung, Nutzungsbedingungen, Support, Kontolöschung und app-ads.txt –, auf einer eigenen Subdomain, ohne eigene Domain oder eigenen Server. Eine App ist kostenlos, und nichts, was ein Store verlangt, steht jemals hinter einer Bezahlschranke.

Kostenlos starten Live-Beispiel ansehen

Geprüft am 30. September 2026. Store-Richtlinien ändern sich, manchmal ohne Ankündigung. Alles Folgende verlinkt die offizielle Dokumentation, und maßgeblich ist die dort verlinkte Seite, nicht diese hier. Widersprechen sich beide, hat der Store recht. Dieser Ratgeber ist aus dem Englischen übersetzt; Zitate aus der Store-Dokumentation bleiben im englischen Original.

Eine Datenschutzerklärung zu schreiben, ist eine einmalige Aufgabe. Sie wahr zu halten, nicht: Die Erklärung beschreibt den Build, den Sie beim Schreiben hatten, und der Build ändert sich ständig. Ein Pull Request fügt Crash-Reporting, eine Abo-Bibliothek oder eine Standortberechtigung hinzu, die App wird ausgeliefert, und Datenschutzerklärung, Data-safety-Formular und App-Privacy-Angaben beschreiben noch die alte App.

Beide Stores sehen das als Ihr Problem, nicht als ihres. Google Play sagt, Ihre Data-safety-Antworten müssen jederzeit korrekt und vollständig bleiben und Daten, die von Drittanbieter-Bibliotheken und SDKs in Ihrer App erhoben werden, müssen Sie angeben. Apple sagt dasselbe über die App-Privacy-Angaben und fügt hinzu, dass Sie die Antworten jederzeit in App Store Connect ändern können, ohne ein Update einzureichen.

Woher die Abweichung tatsächlich kommt

Fast nie aus einer Entscheidung, „mehr Daten zu erheben“. Sie entsteht aus gewöhnlicher Entwicklungsarbeit:

  • Eine neue Abhängigkeit. Crash-Reporting, Analytics, ein Paywall-SDK, eine Kartenbibliothek.
  • Eine neue Berechtigung. Standort für eine Funktion, die Kamera für einen Scanner, Tracking für Werbung.
  • Ein Flavor oder Target. Ein kostenloser Build bekommt ein Werbe-SDK, das der bezahlte Build nicht hat.
  • Eine Entfernung. Auch eine Abweichung – die Erklärung gibt nun zu viel an, was der sicherere Fehler ist, aber trotzdem ein Fehler.

Jede davon landet in einer Build-Datei – build.gradle, AndroidManifest.xml, Podfile, Package.swift, Info.plist, pubspec.yaml, package.json. Genau das macht sie prüfbar.

Der Ansatz: ein festgehaltener Stand und eine Prüfung bei jedem Pull Request

  1. Wenn Ihre Seiten geschrieben werden, halten Sie fest, woraus sie geschrieben wurden: die SDKs, die Datentypen und die Berechtigungen im Build zu diesem Zeitpunkt.
  2. Lesen Sie bei jedem Pull Request die Build-Dateien erneut und vergleichen Sie.
  3. Wenn sich etwas unterscheidet, sagen Sie was, wo (Datei und Zeile) und welche Seite oder welches Formular es betreffen kann.

Zwei Eigenschaften sind wichtig. Die Prüfung darf nur Build-Dateien lesen – nie Quellcode, nie Secrets –, damit sie auf jedem Repository sicher läuft. Und sie muss „möglicherweise veraltet“ sagen, nicht „Verstoß“: Eine Bibliothek in einer Build-Datei ist kein Beweis, dass die App sie nutzt, und nur Sie wissen, ob sie ändert, was Ihre App erhebt.

Einrichtung mit AppFoyer

Die Prüfung ist in jedem Tarif kostenlos. Sie liest nur Build-Dateien, braucht keinen Schlüssel und kein Secret, sendet nichts irgendwohin und ändert nie eine Seite.

Mit dem Claude Code-Plugin

  1. Sagen Sie “make this app store-ready”. Neben den Entwürfen der Seiten schreibt das Plugin appfoyer.json in das Stammverzeichnis Ihres Repositorys: den festgehaltenen Stand, aus dem die Seiten geschrieben wurden.
  2. Sagen Sie “add the AppFoyer drift check”. Es zeigt Ihnen einen GitHub-Workflow und schreibt .github/workflows/appfoyer.yml, wenn Sie zustimmen.
  3. Committen Sie beide Dateien. Das Plugin committet und pusht nie für Sie.

Ohne das Plugin

Fügen Sie den Workflow selbst hinzu:

name: AppFoyer drift check
on: pull_request
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: appfoyer/check-action@v1

Öffnen Sie einen Pull Request. Liegt noch keine appfoyer.json im Repository, zeigt die Job-Summary die Datei, die die Prüfung aus Ihrem Build schreiben würde. Vergleichen Sie sie mit Ihren veröffentlichten Seiten und committen Sie sie.

Oder erstellen Sie sie lokal – derselbe Scanner, veröffentlicht auf npm:

npx @appfoyer/check init

Auf einem anderen CI-System

Das npm-Paket läuft überall, wo Node 20 oder neuer läuft. Für GitLab zum Beispiel:

appfoyer-drift-check:
  image: node:22
  script:
    - npx -y @appfoyer/check --fail-on-drift

--format markdown liefert denselben Bericht, den die GitHub-Job-Summary zeigt; --format json ist für Skripte.

Wie ein Befund aussieht

Ein Pull Request, der RevenueCat zu einer App hinzufügt, deren Seiten ohne es geschrieben wurden:

"Trail Notes": 2 changes
  + In-app purchases / subscriptions (data collected)  app/build.gradle.kts:28
      → Privacy policy may not declare "In-app purchases / subscriptions"
      → Google Play Data safety and Apple App Privacy answers may be outdated
      → Terms may not cover purchases and subscriptions
  + RevenueCat (SDK)  app/build.gradle.kts:28
      → Store forms: RevenueCat is not in the app's SDK list
      → Privacy policy may not name this SDK

Standardmäßig berichtet der Job und läuft durch. Fügen Sie fail-on-drift: "true" unter with: hinzu, damit er fehlschlägt, bis der festgehaltene Stand aktualisiert ist.

Wenn sie eine Änderung meldet

  1. Aktualisieren Sie, was die Änderung betrifft. Sagen Sie auf demselben Branch erneut “make this app store-ready”: Das Plugin liest den Build erneut, aktualisiert die Fakten der App, entwirft die Seiten neu, die die Änderung betrifft, und schreibt appfoyer.json neu. Oder bearbeiten Sie die Seiten und den Tab Store forms im Dashboard selbst.
  2. Aktualisieren Sie den festgehaltenen Stand. Das Plugin hat es bereits getan. Nach einer Bearbeitung im Dashboard führen Sie npx @appfoyer/check update aus oder kopieren die aktualisierte Datei aus der Job-Summary, wo sie unter den Befunden steht.
  3. Committen Sie sie im selben Pull Request. Der nächste Lauf zeigt keine Änderungen, und die Historie zeigt, dass Abhängigkeit und Änderung der Offenlegung zusammen kamen.
  4. Aktualisieren Sie die Store-Formulare in den Konsolen. Weder die Prüfung noch AppFoyer kann die Play Console oder App Store Connect erreichen. Die Antwortentwürfe stehen im Tab Store forms des Dashboards.
  5. Veröffentlichen Sie die aktualisierten Entwürfe über den Prüfbildschirm.

Mehrere Apps in einem Repository

appfoyer.json enthält einen Eintrag pro Store-Eintrag. Ein Product Flavor mit eigener Application ID bekommt einen eigenen Eintrag, sodass ein Werbe-SDK, das nur der kostenlose Flavor nutzt, mit den Seiten des kostenlosen Flavors verglichen wird und nicht mit denen des bezahlten. Das Plugin schreibt einen Eintrag pro Flavor, den es store-ready gemacht hat. Von Hand nimmt ein Eintrag eine Liste sourceSets – ["free"], oder bei einem Build mit mehreren Dimensionen jeden Flavor der Kombination plus die Kombination selbst – und einen Ordner root, wenn die App in einem Monorepo liegt.

Was sie nicht sehen kann

  • Abhängigkeiten von Abhängigkeiten, außer unter iOS, wo Podfile.lock sie auflistet. Ein SDK, das eine andere Bibliothek mitbringt, erscheint nicht in Ihrer Build-Datei und daher auch hier nicht.
  • Konfiguration, die nur aus Code besteht. app.config.js / app.config.ts in Expo ist JavaScript und wird nicht gelesen; app.json und package.json schon.
  • Ob Sie nutzen, was Sie deklarieren. Eine Abhängigkeit, die vorhanden, aber ungenutzt ist, wird trotzdem gemeldet.
  • Ihr Backend. Nichts in einer Build-Datei sagt, was Ihr Server speichert oder wie lange.

Sie ist eine Erinnerung in dem Moment, in dem eine Änderung am billigsten offenzulegen ist, kein Compliance-Urteil und keine Rechtsberatung.

Die maßgeblichen Quellen