Privacy Manifest — co to jest, plik PrivacyInfo.xcprivacy i wymagania

Co to jest Privacy Manifest?

Privacy Manifest to plik PrivacyInfo.xcprivacy w formacie property list (XML), który deklaruje, jakie typy danych zbiera aplikacja i dlaczego używa określonych API. Apple wprowadziło manifesty w ramach inicjatywy zwiększenia przejrzystości prywatności, podobnej do Privacy Nutrition Label, ale na poziomie kodu i binaru.

Głównym celem manifestu jest dokumentowanie używania tak zwanych Required Reason API. Są to kategorie API, które mogą być używane do pobierania cyfrowego odcisku urządzenia (fingerprinting), dlatego każde ich użycie musi być poparte deklaracją konkretnej przyczyny z zatwierdzonej przez Apple listy.

Od 1 maja 2024 roku Apple odrzuca kompilacje, które nie zawierają Privacy Manifest. Dotyczy to zarówno głównych targetów aplikacji, jak i wszystkich wbudowanych SDK i zależności. Według WWDC 2023, manifest jest obowiązkowy dla wszystkich aplikacji dystrybuowanych przez App Store.

Manifest musi być obecny w każdym binarniku — nie tylko w głównej aplikacji, ale także w każdym frameworku i bibliotece statycznej. Jeśli zewnętrzny SDK nie dostarczył manifestu, deweloper musi dodać go ręcznie lub skontaktować się z dostawcą SDK w celu aktualizacji.

Dlaczego Apple wprowadziło Privacy Manifest

Przed pojawieniem się manifestów deweloperzy mogli używać rozbudowanych systemowych API (dostęp do systemu plików, daty/czasu, logów systemowych) bez przejrzystego wyjaśnienia celu użycia. Stwarzało to ryzyko wycieku danych przez zewnętrzne SDK, które mogły zbierać informacje bez wiedzy dewelopera.

Według danych Mysk Inc. (2023), wiele popularnych SDK używało API do pobierania odcisku urządzenia bez wyraźnej potrzeby — na przykład odczytywały czas uptime do określenia strefy czasowej lub skanowały katalogi w celu zebrania metadanych. Privacy Manifest zobowiązuje do deklarowania każdego takiego działania.

Oprócz Required Reason API, manifest zawiera sekcję NSPrivacyTracking — flagę wskazującą, czy aplikacja używa trackingu (wymaga ATT), oraz NSPrivacyCollectedDataTypes — listę typów zbieranych danych w formacie Privacy Nutrition Label.

Różnica między Privacy Manifest a Privacy Nutrition Label

Privacy Nutrition Label to widoczny dla użytkownika opis na stronie aplikacji w App Store, pokazujący, jakie dane zbiera aplikacja. Privacy Manifest to plik techniczny wewnątrz binaru, który jest sprawdzany automatycznie przez Apple. Jeśli dane w manifeście nie zgadzają się z etykietami w App Store Connect, Apple odrzuca kompilację.

Manifest jest źródłem prawdy dla systemu sprawdzania Apple. Na jego podstawie automatycznie generowane są etykiety prywatności, ale deweloper musi utrzymywać oba przedstawienia w aktualnym stanie. Zmiana manifestu po publikacji wymaga wysłania nowej kompilacji do recenzji.

Struktura PrivacyInfo.xcprivacy

Plik PrivacyInfo.xcprivacy używa formatu property list z typem głównym Dictionary. Główne klucze najwyższego poziomu: NSPrivacyTracking (Boolean), NSPrivacyTrackingDomains (Array), NSPrivacyCollectedDataTypes (Array), NSPrivacyAccessedAPITypes (Array).

Klucze najwyższego poziomu

Klucz NSPrivacyTracking — wartość boolowska wskazująca, czy aplikacja używa trackingu (wymaga ATT). Jeśli true, należy również podać NSUserTrackingUsageDescription w Info.plist. Klucz NSPrivacyTrackingDomains — tablica domen, na których stosowany jest tracking.

Klucz NSPrivacyCollectedDataTypes — tablica słowników, z których każdy opisuje typ zbieranych danych: kategoria (NSPrivacyCollectedDataType), obowiązkowość (NSPrivacyCollectedDataTypeLinked), cel (NSPrivacyCollectedDataTypePurposes). Cele obejmują: oznaczenia stron trzecich, analitykę, rozwój produktu i personalizację treści.

Klucz NSPrivacyAccessedAPITypes — tablica słowników dla każdej kategorii Required Reason API: kategoria (NSPrivacyAccessedAPITypeReasons) — konkretna przyczyna z zatwierdzonej listy Apple oraz NSPrivacyAccessedAPIType — identyfikator kategorii API.

<!-- PrivacyInfo.xcprivacy -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Kategorie danych w NSPrivacyCollectedDataTypes

Typy danych dzielą się na kilka kategorii: dane kontaktowe (imię, email, telefon), finanse (dane płatnicze), identyfikatory (IDFA, User ID), dane o użytkowaniu (logi, kliknięcia), diagnostyka (crash logs) oraz treści użytkownika (zdjęcia, wideo, pliki). Każda kategoria dodatkowo oznaczona jest jako „powiązana z użytkownikiem” (linked) lub „niepowiązana” (not linked).

Linked oznacza, że dane są powiązane z kontem użytkownika; not linked — dane są zagregowane lub anonimizowane. Od tego oznaczenia zależy, jak Apple wyświetla etykietę prywatności: linked dane oznaczone są na żółto, not linked — na zielono.

Które API wymagają podania przyczyn

Apple wyróżniło kilka kategorii API, każde użycie których musi być poparte konkretną przyczyną z zatwierdzonej listy. Przyczyna to unikalny kod, na przykład C617.1 lub 35F9.1, który jest przypisany do konkretnego celu dozwolonego przez Apple.

Główne kategorie Required Reason API

Kategoria NSPrivacyAccessedAPICategoryFileTimestamp obejmuje API do dostępu do znaczników czasowych plików (creationDate, modificationDate). Przyczyny: C617.1 (synchronizacja plików), 3B52.1 (backup), 0A2A.1 (antifraud).

Kategoria NSPrivacyAccessedAPICategoryDiskSpace obejmuje API do sprawdzania wolnego miejsca na dysku (NSFileManager. Sprawdzenia (NSFileManager). Przyczyny: E174.1 (zarządzanie cache), 85F4.1 (pobieranie treści), B728.1 (diagnostyka).

Kategoria NSPrivacyAccessedAPICategorySystemBootTime obejmuje API dostępu do czasu uruchomienia systemu (uptime). Przyczyna tylko jedna: 35F9.1 (pomiar czasu sesji do analityki). Każde inne użycie traktowane jest jako fingerprinting.

Pełna lista kategorii API

• FileTimestamp — dostęp do znaczników czasowych plików, dozwolony do synchronizacji i backupu
• DiskSpace — sprawdzanie wolnego miejsca, dozwolone do zarządzania cache i pobierania
• SystemBootTime — czas uptime, dozwolony tylko do analityki sesji
• UserDefaults — dostęp do UserDefaults innych aplikacji, całkowicie zabroniony
• ActiveKeyboards — lista aktywnych klawiatur, dozwolona dla deweloperów IME
• SystemAperture — rozmiar wycięcia na ekranie, dozwolony dla zdjęć i aplikacji AR

Każda kategoria ma od 1 do 5 zatwierdzonych przyczyn. Deweloper ma obowiązek wybrać przyczynę najlepiej odpowiadającą rzeczywistemu użyciu API. Podanie nieprawdziwej przyczyny może prowadzić do odrzucenia kompilacji lub zablokowania konta.

Wymagania wobec zewnętrznych SDK

Od 1 maja 2024 roku wszystkie zewnętrzne SDK — zarówno binarne, jak i z otwartym kodem źródłowym — muszą dołączać Privacy Manifest do swojego pakietu. Apple sprawdza manifesty dla wszystkich zależności, a jeśli choć jeden SDK nie ma manifestu, kompilacja zostanie odrzucona.

Duże SDK (Firebase, Adjust, AppsFlyer, Facebook SDK) już zaktualizowały swoje pakiety. Jeśli twój projekt używa mało znanego SDK, sprawdź jego wersję i w razie potrzeby zaktualizuj lub skontaktuj się z deweloperem. Tymczasowym rozwiązaniem jest ręczne dodanie manifestu za SDK do projektu, ale nie jest to zalecane ze względu na rozbieżności przy aktualizacjach.

Jak utworzyć Privacy Manifest w Xcode

Privacy Info.xcprivacy można utworzyć za pomocą wbudowanego szablonu Xcode 15+ lub ręcznie. Rozważymy oba warianty.

Tworzenie przez Xcode 15

W Xcode 15 dodano szablon Privacy Manifest: File → New → File → Resource → Privacy Manifest. Xcode tworzy plik z podstawową strukturą i wypełnia NSPrivacyTracking oraz puste tablice dla API i danych. Po utworzeniu należy ręcznie wskazać przyczyny dla każdego używanego Required Reason API.

Szablon automatycznie dodaje plik do głównego targetu. Jeśli w projekcie jest kilka targetów (Extensions, Watch app), należy dodać manifest do każdego. Xcode nie sprawdza obecności manifestu w zależnościach na etapie kompilacji — dopiero na etapie archiwizacji.

// AppDelegate: sprawdzenie manifestu na etapie rozwoju
import Foundation

func validatePrivacyManifest() {
    guard let path = Bundle.main.path(
        forResource: "PrivacyInfo", ofType: "xcprivacy"
    ) else {
        print("PrivacyInfo.xcprivacy not found")
        return
    }
    guard let dict = NSDictionary(contentsOfFile: path)
    else { return }
    print("Privacy manifest loaded: \(dict.count) keys")
}

Tworzenie ręczne przez XML

Można utworzyć PrivacyInfo.xcprivacy ręcznie jako zwykły plik XML property list. W tym celu utwórz plik o nazwie PrivacyInfo.xcprivacy, napisz standardowy nagłówek plist i dodaj słownik główny z niezbędnymi kluczami. Upewnij się, że plik został dodany do targetu (Target Membership).

Ręczny sposób jest przydatny, gdy trzeba dodać manifest do biblioteki statycznej lub zależności Package Manager bez używania interfejsu Xcode. Po kompilacji sprawdź, czy plik trafił do binaru za pomocą polecenia nm lub archiwizacji.

Sprawdzenie manifestu przed publikacją

Przed wysłaniem kompilacji do App Store należy sprawdzić, czy Privacy Manifest jest poprawny i kompletny. Apple udostępnia kilka narzędzi do weryfikacji.

Wbudowany walidator Xcode

Podczas archiwizacji projektu (Product → Archive) Xcode wykonuje sprawdzenie manifestów. Jeśli wykryta zostanie błąd — brak manifestu, nieprawidłowa przyczyna, pusta kategoria — archiwizacja kończy się błędem. Log błędów jest wyświetlany w Issue navigator z wskazaniem problematycznego SDK i kategorii API.

Dodatkowe sprawdzenie jest wykonywane po stronie App Store Connect przy przesyłaniu kompilacji. Jeśli walidacja nie przejdzie, kompilacja jest odrzucana z automatycznym e-mailem zawierającym identyfikator problematycznego API i zalecaną poprawkę.

Sprawdzenie przez wiersz poleceń

Do automatyzacji sprawdzania używaj skryptów, które analizują binarnik pod kątem użycia Required Reason API. Apple udostępnia narzędzie libtool i skrypty sprawdzania symboli, ale społeczność opracowała wygodniejsze narzędzia.

# Wyszukiwanie użycia FileTimestamp API w binarniku
nm MyApp.app/MyApp | grep "NSFileCreationDate"

# Sprawdzenie obecności PrivacyInfo.xcprivacy w aplikacji
find MyApp.app -name "*.xcprivacy"

Cręste błędy walidacji

Najczęstszym błędem jest brak manifestu w jednym z SDK. Nawet jeśli główny target zawiera manifest, Apple sprawdza wszystkie binarniki osobno. Drugim co do częstości jest nieprawidłowy kod przyczyny: użycie przyczyny dla jednej kategorii API z API z innej kategorii.

Trzecim błędem jest nadmierne deklarowanie API, które w rzeczywistości nie są używane. Deweloperzy dodają wszystkie możliwe przyczyny „na wszelki wypadek”, co niepokoi recenzentów Apple. Dodawaj tylko te kategorie, które są rzeczywiście używane. Użyj statycznego analizatora Xcode do sprawdzenia.