Menjaga kebijakan privasi tetap sesuai dengan build Anda

Menulis kebijakan privasi adalah pekerjaan sekali jalan. Menjaganya tetap benar tidak: kebijakan itu menggambarkan build yang Anda miliki saat menulisnya, dan build terus berubah. Sebuah pull request menambahkan crash reporting, library langganan, atau izin lokasi, aplikasinya dirilis, dan kebijakan, formulir Data safety, serta detail App Privacy masih menggambarkan aplikasi yang lama.

Kedua toko menganggap itu masalah Anda, bukan masalah mereka. Google Play mengatakan jawaban Data safety Anda harus tetap akurat dan lengkap setiap saat, dan bahwa data yang dikumpulkan oleh library dan SDK pihak ketiga di aplikasi Anda wajib Anda deklarasikan. Apple mengatakan hal yang sama tentang detail App Privacy, dan menambahkan bahwa Anda dapat mengubah jawaban di App Store Connect kapan saja tanpa mengirimkan pembaruan.

Dari mana penyimpangan itu sebenarnya berasal

Hampir tidak pernah dari keputusan untuk “mengumpulkan lebih banyak data”. Penyimpangan berasal dari pekerjaan engineering biasa:

• Dependensi baru. Crash reporting, analitik, SDK paywall, library peta.
• Izin baru. Lokasi untuk satu fitur, kamera untuk pemindai, pelacakan untuk iklan.
• Flavor atau target. Build gratis mendapat SDK iklan yang tidak dimiliki build berbayar.
• Penghapusan. Juga penyimpangan — kebijakan kini mendeklarasikan berlebihan, yang merupakan kesalahan yang lebih aman tetapi tetap kesalahan.

Setiap perubahan ini masuk ke file build — build.gradle, AndroidManifest.xml, Podfile, Package.swift, Info.plist, pubspec.yaml, package.json. Itulah yang membuatnya bisa diperiksa.

Pendekatannya: sebuah catatan, dan pemeriksaan di setiap pull request

1. Saat halaman Anda ditulis, catat apa yang menjadi dasarnya: SDK, jenis data, dan izin dalam build pada saat itu.
2. Di setiap pull request, baca file build lagi dan bandingkan.
3. Jika ada yang berbeda, sebutkan apa, di mana (file dan baris), dan halaman atau formulir mana yang mungkin terpengaruh.

Dua sifat yang penting. Pemeriksaan harus membaca hanya file build — tidak pernah kode sumber, tidak pernah secret — sehingga aman dijalankan di repositori mana pun. Dan pemeriksaan harus mengatakan “mungkin sudah usang”, bukan “pelanggaran”: library di file build bukan bukti bahwa aplikasi menggunakannya, dan hanya Anda yang tahu apakah itu mengubah apa yang dikumpulkan aplikasi Anda.

Menyiapkannya dengan AppFoyer

Pemeriksaan ini gratis di setiap paket. Pemeriksaan ini hanya membaca file build, tidak memerlukan key atau secret, tidak mengirim apa pun ke mana pun, dan tidak pernah mengubah halaman.

Dengan plugin Claude Code

1. Katakan “make this app store-ready” (siapkan aplikasi ini untuk toko). Selain menyusun draf halaman, plugin menulis appfoyer.json di root repositori Anda: catatan tentang apa yang menjadi dasar penulisan halaman.
2. Katakan “add the AppFoyer drift check” (tambahkan pemeriksaan penyimpangan AppFoyer). Plugin menunjukkan workflow GitHub kepada Anda dan menulis .github/workflows/appfoyer.yml saat Anda setuju.
3. Commit kedua file. Plugin tidak pernah melakukan commit atau push untuk Anda.

Tanpa plugin

Tambahkan workflow-nya sendiri:

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

Buka pull request. Jika belum ada appfoyer.json di repositori, job summary menampilkan file yang akan ditulisnya dari build Anda. Bandingkan dengan halaman yang sudah Anda terbitkan dan commit file itu.

Atau buat secara lokal — pemindai yang sama, diterbitkan di npm:

npx @appfoyer/check init

Di sistem CI lain

Paket npm berjalan di mana pun Node 20 atau yang lebih baru berjalan. Untuk GitLab, misalnya:

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

--format markdown memberikan laporan yang sama dengan yang ditampilkan job summary GitHub; --format json untuk skrip.

Seperti apa sebuah temuan

Pull request yang menambahkan RevenueCat ke aplikasi yang halamannya ditulis tanpa RevenueCat:

"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

Secara default, job melapor dan lolos. Tambahkan fail-on-drift: "true" di bawah with: agar job gagal sampai catatannya diperbarui.

Saat pemeriksaan melaporkan perubahan

1. Perbarui apa yang terdampak perubahan itu. Katakan “make this app store-ready” lagi di branch yang sama: plugin membaca build lagi, memperbarui fakta aplikasi, menyusun ulang draf halaman yang terdampak perubahan, dan menulis ulang appfoyer.json. Atau edit sendiri halaman dan tab Store forms di dashboard.
2. Segarkan catatannya. Plugin sudah melakukannya. Setelah mengedit di dashboard, jalankan npx @appfoyer/check update, atau salin file yang sudah diperbarui dari job summary, tempatnya ada di bawah temuan.
3. Commit di pull request yang sama. Proses berikutnya tidak menunjukkan perubahan, dan riwayatnya menunjukkan perubahan dependensi dan pengungkapan datang bersamaan.
4. Perbarui formulir toko di konsol. Baik pemeriksaan ini maupun AppFoyer tidak dapat menjangkau Play Console atau App Store Connect. Draf jawabannya ada di tab Store forms di dashboard.
5. Terbitkan draf yang sudah diperbarui dari layar peninjauan.

Beberapa aplikasi dalam satu repositori

appfoyer.json memuat satu entri per listingan toko. Product flavor dengan application id sendiri mendapat entrinya sendiri, sehingga SDK iklan yang hanya digunakan flavor gratis dibandingkan dengan halaman flavor gratis, bukan halaman flavor berbayar. Plugin menulis satu entri per flavor yang disiapkannya untuk toko. Secara manual, sebuah entri menerima daftar sourceSets — ["free"], atau untuk build multi-dimensi setiap flavor dalam kombinasi itu ditambah kombinasinya sendiri — dan folder root jika aplikasi berada di dalam monorepo.

Yang tidak bisa dilihatnya

• Dependensi dari dependensi, kecuali di iOS, tempat Podfile.lock mencantumkannya. SDK yang ditarik oleh library lain tidak muncul di file build Anda, jadi tidak muncul di sini juga.
• Konfigurasi yang hanya berupa kode. app.config.js / app.config.ts di Expo adalah JavaScript dan tidak dibaca; app.json dan package.json dibaca.
• Apakah Anda menggunakan apa yang Anda deklarasikan. Dependensi yang ada tetapi tidak digunakan tetap dilaporkan.
• Backend Anda. Tidak ada apa pun di file build yang menyebutkan apa yang disimpan server Anda atau berapa lama.

Ini adalah pengingat pada saat sebuah perubahan paling murah untuk diungkapkan, bukan putusan kepatuhan dan bukan nasihat hukum.

Sumber resmi

• Provide information for Google Play’s Data safety section — Google Play Console Help: menjaga formulir tetap akurat, dan data SDK pihak ketiga
• App privacy details on the App Store — Apple: menjaga jawaban tetap terbaru, dan memperbaruinya tanpa pembaruan aplikasi
• appfoyer/check-action dan @appfoyer/check — Action dan paket npm, beserta apa yang dibacanya