Privacy Manifest – szczegółowa analiza: co liczy się jako zbieranie danych

Od 1 maja 2024 r. każda aplikacja i każdy SDK innej firmy przesyłany do App Store Connect musi posiadać privacy manifest deklarujący użycie „required reason APIs”, swoje zachowanie w zakresie śledzenia oraz zbierane typy danych¹. Manifest jest plikiem property list (PrivacyInfo.xcprivacy), który App Store wczytuje w momencie przesłania, weryfikuje wobec znanego zakresu APIs wrażliwych z punktu widzenia prywatności i prezentuje na widocznej dla użytkownika etykiecie odżywczej prywatności. Aplikacje, które pomijają manifest lub używają wrażliwego z punktu widzenia prywatności API bez zadeklarowania zatwierdzonego powodu, są odrzucane przy przesyłaniu z błędem ITMS-91053 lub powiązanymi kodami².

Większość zespołów traktuje manifest jako jednorazowe zadanie zgodności: napisać, wysłać, nigdy więcej do tego nie wracać. Manifest to coś więcej. To ustrukturyzowany kontrakt między aplikacją a Apple, który kodyfikuje, co aplikacja robi z prywatnymi danymi, i jest jedynym miejscem, w którym ten kontrakt istnieje w formacie czytelnym maszynowo. Uważne przeczytanie go ujawnia, co Apple uznaje za wrażliwe z punktu widzenia prywatności (zakres jest szerszy, niż większość deweloperów się spodziewa), co użytkownik faktycznie widzi na etykiecie odżywczej (bardziej szczegółowo, niż większość zespołów sobie uświadamia) oraz co SDKs innych firm muszą ujawnić (realny obowiązek, a nie uprzejmość).

TL;DR

• Privacy manifest ma cztery sekcje najwyższego poziomu: NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes oraz NSPrivacyAccessedAPITypes³.
• Lista Required Reason API obejmuje pięć początkowych kategorii: znacznik czasu pliku, czas uruchomienia systemu, miejsce na dysku, aktywne klawiatury oraz User Defaults. Każda kategoria ma zamkniętą listę zatwierdzonych kodów uzasadnienia; aplikacje muszą wybrać jeden z nich albo przebudować kod, aby uniknąć danego API⁴.
• Śledzenie jest zdefiniowane wąsko: łączenie danych użytkownika z danymi pochodzącymi od innych firm w celu wyświetlania reklam lub udostępniania ich brokerom danych. Jeśli NSPrivacyTracking ma wartość true, każda domena używana do śledzenia musi pojawić się w NSPrivacyTrackingDomains³.
• SDKs innych firm muszą dostarczać własne manifesty. Manifest aplikacji jest scalany z manifestami wszystkich powiązanych SDKs w momencie przesłania; brakujące manifesty SDKs znajdujących się na liście publikowanej przez Apple blokują aplikację⁵.
• Największa pułapka: dostęp do UserDefaults zawsze liczy się jako wywołanie Required Reason API. Standardowe wywołanie UserDefaults.standard.set(...) wymaga zadeklarowanego kodu uzasadnienia.

Cztery sekcje

Kompletny plik PrivacyInfo.xcprivacy zawiera cztery klucze najwyższego poziomu³. Struktura to property list, edytowana jako XML w surowej postaci lub poprzez edytor privacy manifest w Xcode.

NSPrivacyTracking (Boolean)

Deklaruje, czy aplikacja lub SDK śledzi użytkownika w aplikacjach i witrynach innych firm. Definicja semantyczna jest zgodna z App Tracking Transparency: łączenie danych użytkownika z danymi pochodzącymi od innych firm w celu targetowania reklam, dostarczania reklam ukierunkowanych lub udostępniania danych użytkownika brokerom danych⁶.

Jeśli NSPrivacyTracking ma wartość true, każda domena używana do śledzenia musi pojawić się na liście NSPrivacyTrackingDomains. Jeśli false, lista jest pomijana (lub pusta).

Wąska definicja ma znaczenie. Wiele aplikacji wyświetlających reklamy (poprzez własną sieć Apple SKAdNetwork lub SDKs reklamowe nieśledzące) może zadeklarować NSPrivacyTracking jako false. Śledzenie to powiązanie z zewnętrznymi danymi, a nie samo wyświetlanie reklam.

NSPrivacyTrackingDomains (tablica ciągów znaków)

Lista domen, z którymi aplikacja lub SDK kontaktuje się w celach śledzenia. Aplikacje deklarujące NSPrivacyTracking jako true muszą wymienić tutaj każdy punkt końcowy śledzenia.

Lista jest egzekwowana w czasie wykonania poprzez App Privacy Report: jeśli aplikacja kontaktuje się z domeną oznaczoną jako śledząca, ale niezadeklarowaną, App Privacy Report przedstawia tę rozbieżność użytkownikowi. Powtarzające się naruszenia grożą usunięciem ze sklepu App Store.

NSPrivacyCollectedDataTypes (tablica słowników)

Ustrukturyzowana deklaracja zbierania danych, która zasila etykietę odżywczą prywatności w App Store³. Każdy wpis opisuje jeden typ danych zbieranych przez aplikację, z podkluczami:

• NSPrivacyCollectedDataType: typ danych z zamkniętej listy Apple (np. NSPrivacyCollectedDataTypeName, NSPrivacyCollectedDataTypeEmailAddress, NSPrivacyCollectedDataTypeCrashData).
• NSPrivacyCollectedDataTypeLinked: wartość Boolean, czy dane są powiązane z tożsamością użytkownika.
• NSPrivacyCollectedDataTypeTracking: wartość Boolean, czy dane są wykorzystywane do śledzenia.
• NSPrivacyCollectedDataTypePurposes: tablica, cele, w jakich dane są zbierane (analityka, działanie aplikacji, reklama itp.).

Ta sekcja jest źródłem prawdy dla etykiety odżywczej prywatności. Kategorie etykiety odżywczej „Dane wykorzystywane do śledzenia użytkownika” oraz „Dane powiązane z użytkownikiem” są obliczane na podstawie tych flag. Niedokładne deklaracje skutkują niedokładnymi etykietami odżywczymi i grożą działaniami egzekucyjnymi App Store.

NSPrivacyAccessedAPITypes (tablica słowników)

Deklaracja Required Reason API. Każdy wpis łączy kategorię Required Reason API z zestawem zatwierdzonych kodów uzasadnienia⁴.

<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>

Uzasadnienia stanowią listy zamknięte. Aplikacja wybiera jedno lub więcej z opublikowanej przez Apple listy dla danej kategorii; dowolne ciągi znaków są odrzucane przy przesyłaniu.

Pięć kategorii Required Reason API

Początkowa lista Apple z 2024 r. zdefiniowała pięć kategorii API wymagających zadeklarowanego uzasadnienia⁴:

NSPrivacyAccessedAPICategoryFileTimestamp

Wyzwalana przez każdy API, który zwraca czas utworzenia, modyfikacji lub dostępu do pliku. Typowe punkty wejścia: URL.resourceValues(forKeys: [.creationDateKey, ...]), FileManager.attributesOfItem(atPath:), stat(), fstat(), lstat(). Cztery zatwierdzone uzasadnienia⁴:

• DDA9.1. Wyświetlanie znaczników czasu plików użytkownikowi urządzenia. Informacje uzyskane z tego powodu nie mogą być wysyłane poza urządzenie.
• C617.1. Dostęp do metadanych pliku (znaczników czasu, rozmiaru itp.) dla plików w kontenerze aplikacji, kontenerze grupy aplikacji lub kontenerze CloudKit.
• 3B52.1. Dostęp do metadanych pliku dla plików lub katalogów, do których użytkownik wyraźnie udzielił dostępu (selektor dokumentów itp.).
• 0A2A.1. Wrappery SDK innych firm, które uzyskują dostęp do APIs znaczników czasu plików tylko wtedy, gdy aplikacja wywoła wrapper. Tylko dla SDK.

Większość aplikacji używa C617.1 (dostęp do własnego kontenera) do wewnętrznego zarządzania plikami. Aplikacje wyświetlające daty plików w interfejsie użytkownika używają DDA9.1. Aplikacje czytające pliki, do których użytkownik udzielił dostępu (selektor dokumentów, cele rozszerzeń udostępniania), używają 3B52.1. Autorzy SDK używają wyłącznie 0A2A.1.

NSPrivacyAccessedAPICategorySystemBootTime

Wyzwalana przez mach_absolute_time(), mach_continuous_time() i powiązane APIs czasu działania. Obawa dotycząca prywatności: czas uruchomienia systemu jest sygnałem podatnym na fingerprinting, który może służyć do identyfikacji urządzenia po ponownych instalacjach. Trzy zatwierdzone uzasadnienia⁴:

• 35F9.1. Dostęp do czasu uruchomienia systemu w celu mierzenia odstępów czasowych między zdarzeniami aplikacji lub umożliwienia działania timerów.
• 8FFB.1. Dostęp do czasu uruchomienia systemu w celu obliczania bezwzględnych znaczników czasu zdarzeń w aplikacji.
• 3D61.1. Dodawanie informacji o czasie uruchomienia systemu w opcjonalnym raporcie błędu, który użytkownik decyduje się przesłać.

Większość aplikacji używa 35F9.1 do pomiaru wydajności. 8FFB.1 obejmuje przypadki, w których aplikacja wyprowadza znaczniki czasu zdarzeń z czasu uruchomienia (względem sesji urządzenia). Należy zauważyć, że Date() i Date.now nie wyzwalają tej kategorii; korzystają one z innego źródła czasu. Kategoria obejmuje konkretnie wywołania z rodziny mach_*_time.

NSPrivacyAccessedAPICategoryDiskSpace

Wyzwalana przez APIs zwracające pojemność dysku lub wolne miejsce, w tym URL.resourceValues(forKeys: [.volumeAvailableCapacityKey, ...]) oraz APIs atrybutów systemu plików NSFileManager. Obawa dotycząca prywatności: wzorce miejsca na dysku stanowią sygnał podatny na fingerprinting. Cztery zatwierdzone uzasadnienia⁴:

• 854F.1. Wyświetlanie informacji o miejscu na dysku użytkownikowi urządzenia, w jednostkach danych lub jednostkach czasu trwania mediów.
• E174.1. Sprawdzanie miejsca na dysku podczas zapisywania plików lub zarządzanie niewystarczającą ilością miejsca (decydowanie, czy pobrać zasób, czyszczenie plików w pamięci podręcznej).
• 7D9E.1. Dołączanie informacji o miejscu na dysku do opcjonalnego raportu błędu, który użytkownik decyduje się przesłać.
• B728.1. Aplikacje badań zdrowotnych wykrywające i informujące uczestników o niewystarczającej ilości miejsca na dysku wpływającej na zbieranie danych badawczych.

NSPrivacyAccessedAPICategoryActiveKeyboards

Wyzwalana przez UITextInputMode.activeInputModes. Aplikacje czytające tę listę (zazwyczaj w celu lokalizacji zachowania lub wykrywania języka wprowadzania) muszą zadeklarować uzasadnienie. Dwa zatwierdzone uzasadnienia⁴:

• 3EC4.1. Niestandardowa aplikacja klawiatury określająca aktywne klawiatury na urządzeniu.
• 54BD.1. Dostęp do informacji o aktywnej klawiaturze w celu odpowiedniego dostosowania interfejsu użytkownika (zazwyczaj dla UX uwzględniającego język wprowadzania).

Większość aplikacji nie potrzebuje tej kategorii. Jeśli kod wywołuje activeInputModes pośrednio przez bibliotekę innej firmy, to manifest tej biblioteki ją deklaruje.

NSPrivacyAccessedAPICategoryUserDefaults

Kategoria, która dotyczy niemal każdej aplikacji. Każdy dostęp do UserDefaults (UserDefaults.standard, defaults grupy aplikacji poprzez init(suiteName:), indywidualne wywołania set/get) wyzwala wymóg⁷. Cztery zatwierdzone uzasadnienia⁴:

• CA92.1. Dostęp do user defaults w celu odczytu/zapisu danych wyłącznych dla samej aplikacji (lub dla rozszerzenia aplikacji sparowanego wyłącznie z aplikacją).
• 1C8F.1. Dostęp do user defaults w celu odczytu/zapisu danych wyłącznie w aplikacjach, rozszerzeniach aplikacji i App Clips należących do tej samej grupy aplikacji.
• C56D.1. Wrappery SDK innych firm, które uzyskują dostęp do APIs user defaults tylko wtedy, gdy aplikacja wywoła wrapper. Tylko dla SDK.
• AC6B.1. Dostęp do user defaults w celu pobrania zarządzanych konfiguracji aplikacji ustawionych przez administratora MDM/IT lub w celu zapisania informacji zwrotnych dla administratora.

Niemal każda aplikacja iOS używa UserDefaults.standard do co najmniej jednego elementu stanu (ostatnio wybrana zakładka użytkownika, preferowana kolejność sortowania, feature flag). Uzasadnienie CA92.1 to obejmuje. Aplikacje współdzielące stan między rozszerzeniami aplikacji poprzez grupę aplikacji dodają 1C8F.1. Autorzy SDK używają C56D.1. Aplikacje wdrażane przez MDM, które odczytują klucze ustawione przez administratora (np. com.apple.configuration.managed), używają AC6B.1.

Pułapka: SDK innej firmy, który dotyka UserDefaults, wyzwala wymóg w imieniu aplikacji. Manifest SDK musi zadeklarować uzasadnienie. Jeśli SDK znajduje się na liście SDKs, które muszą dostarczać privacy manifest, brak manifestu SDK blokuje aplikację.

Domeny śledzące: walidacja w czasie wykonania

NSPrivacyTrackingDomains jest egzekwowane przez App Privacy Report w czasie wykonania⁶. Gdy aplikacja deklaruje NSPrivacyTracking = true, system śledzi każde żądanie sieciowe i porównuje cel z zadeklarowaną listą. Domeny, z którymi nawiązano kontakt w celach śledzenia, ale które nie zostały zadeklarowane, pojawiają się w sekcjach „Najczęstsze lokalizacje” oraz „Inne kontaktowane domeny” w App Privacy Report.

Walidacja w czasie wykonania tworzy interesującą strukturę motywacyjną. Aplikacja deklarująca NSPrivacyTracking = false (brak śledzenia), która zostaje zaobserwowana podczas kontaktu ze znanymi domenami śledzącymi, jest oznaczana w App Privacy Report i naraża się na skargi użytkowników. Właściwym posunięciem jest uczciwa deklaracja.

W przypadku SDKs, manifest SDK deklaruje jego zachowanie w zakresie śledzenia. Manifest aplikacji nie musi wyliczać domen śledzących SDK; manifest SDK już to robi. Przy przesłaniu Apple scala manifesty i sprawdza spójność.

Manifesty SDK: realny obowiązek

SDKs innych firm w dwóch kategoriach muszą dostarczać privacy manifest⁵:

1. SDKs znajdujące się na opublikowanej liście SDKs wymagających privacy manifestu firmy Apple. Lista obejmuje Firebase Analytics, Google Mobile Ads, Adjust, Segment, AppsFlyer i około 30 innych według stanu na iOS 26.
2. SDKs dystrybuowane jako wstępnie skompilowane pliki binarne (XCFrameworks, biblioteki statyczne), z którymi aplikacja jest linkowana.

Przesłanie aplikacji linkującej wymagany SDK bez manifestu SDK kończy się niepowodzeniem z błędem z serii ITMS-91xxx obejmującym brakujący privacy manifest, brakujący podpis manifestu lub brakującą deklarację API w przestrzeni nazw SDK². Naprawa polega na aktualizacji do wersji SDK dostarczającej manifest lub na usunięciu SDK.

W przypadku SDKs pierwszej strony (twój zespół dostarcza wewnętrzny framework używany przez wasze aplikacje) można pominąć manifest, jeśli framework nie znajduje się na liście Apple. Pragmatycznym posunięciem jest jednak dostarczenie manifestu i tak: przyszłe rozszerzenia listy Apple, przyszłe prace audytowe, przyszłe ponowne wykorzystanie przez strony trzecie – wszystkie skorzystają z istniejącego manifestu.

Typowe pułapki

Pięć powtarzających się trybów awarii z dzienników odrzuceń App Store:

1. Zapomniana deklaracja UserDefaults. Najczęstsze odrzucenie. Aplikacja używa @AppStorage (które opakowuje UserDefaults) w jakimś niewinnym miejscu, manifest tego nie deklaruje. Naprawa: każda aplikacja używająca @AppStorage, UserDefaults lub jakiegokolwiek wrappera wokół nich potrzebuje NSPrivacyAccessedAPICategoryUserDefaults z CA92.1.

2. Ukryty dostęp do znaczników czasu plików przez URLResourceValues. Kod odczytujący daty modyfikacji plików przez URL.resourceValues(forKeys: [.contentModificationDateKey]) wyzwala kategorię, mimo że miejsce wywołania nie wygląda jak stat.

3. Oczekiwania dotyczące manifestu SDK. Zespoły aplikacji zakładają, że manifest SDK jest problemem autora SDK. Jest, ale przesłanie zespołu aplikacji kończy się niepowodzeniem, dopóki SDK go nie dostarczy.

4. NSPrivacyTracking = false mimo zlinkowanego śledzącego SDK. Linkowanie Firebase Analytics lub Google Mobile Ads z domyślnymi ustawieniami często wyzwala zachowanie śledzące. Manifest aplikacji deklarujący NSPrivacyTracking = false, podczas gdy manifest SDK deklaruje true, tworzy sprzeczność, którą scalanie oznacza.

5. Nieaktualne kody uzasadnienia. Apple od czasu do czasu aktualizuje zatwierdzone kody uzasadnienia. Kody, które były ważne w 2024 r., mogą zostać zastąpione lub rozszerzone. Naprawa polega na ponownym sprawdzeniu aktualnej opublikowanej listy przy każdym dużym wydaniu, zamiast kopiowania starych manifestów do przodu.

Narzędzia walidacyjne

Trzy testy warto przeprowadzić przed przesłaniem:

Workflow archiwum „Generate Privacy Report” w Xcode. Po Product > Archive Organizer oferuje akcję „Generate Privacy Report”, która tworzy zbiorczy raport z aplikacji oraz manifestów wszystkich zlinkowanych SDKs. Raport jest tym, co App Store Connect wczytuje; uruchamianie go lokalnie jest najbliższym odpowiednikiem próbnego przesłania.

Analiza statyczna Required Reason APIs. Narzędzia open-source skanują projekt pod kątem miejsc wywołań API, które wyzwalają pięć kategorii. Utrzymywany przez społeczność CLI stelabouras/privacy-manifest parsuje źródła Swift i pliki binarne xcframework, ujawniając zadeklarowane i niezadeklarowane kody uzasadnienia; crasowas/app_store_required_privacy_manifest_analyser zapewnia podobne skanowanie. Każde z nich daje przydatną przedwysyłkową kontrolę brakujących deklaracji.

Sprawdzenie krzyżowe z App Privacy Report. Uruchom aplikację w trybie App Privacy Report w iOS (Ustawienia > Prywatność i bezpieczeństwo > App Privacy Report). Domeny, z którymi aplikacja się kontaktuje, pojawiają się w raporcie; sprawdź je krzyżowo z deklaracjami śledzenia w manifeście.

Co ten wzorzec oznacza dla aplikacji iOS 26+

Trzy wnioski.

1. Należy traktować privacy manifest jako ustrukturyzowany kontrakt, a nie pole do odhaczenia. Manifest jest jedynym czytelnym maszynowo zapisem tego, co aplikacja robi z prywatnymi danymi. Zbudowanie go raz i ignorowanie na zawsze to droga do odrzuconego przesłania sześć miesięcy później, gdy aktualizacja SDK po cichu rozszerzy wymagany zakres manifestu.

2. Należy audytować dostęp do UserDefaults i znaczników czasu plików przy każdym wydaniu. To dwie kategorie, które po cichu rosną wraz z bazą kodu. Widok SwiftUI używający @AppStorage dodany podczas refaktoryzacji wciąga NSPrivacyAccessedAPICategoryUserDefaults w zakres; funkcja listowania plików dodana później wciąga NSPrivacyAccessedAPICategoryFileTimestamp. Należy każdorazowo ponownie weryfikować.

3. Warto używać SDKs, które dostarczają własne manifesty. Przy ocenie SDK innej firmy obecność i jakość jego privacy manifestu jest obecnie sygnałem jakości. SDKs bez manifestów zmuszają zespół aplikacji do walki z upstream; SDKs z manifestami czysto wpasowują się w scalanie.

Pełny klaster Apple Ecosystem: typowane App Intents; serwery MCP; pytanie o routing; Foundation Models; rozróżnienie runtime vs tooling LLM; trzy powierzchnie; wzorzec single source of truth; Dwa serwery MCP; hooki dla rozwoju Apple; Live Activities; kontrakt runtime watchOS; wnętrze SwiftUI; model myślowy przestrzenny RealityKit; dyscyplina schematów SwiftData; wzorce Liquid Glass; wysyłka wieloplatformowa; macierz platformy; framework Vision; Symbol Effects; wnioskowanie Core ML; Writing Tools API; Swift Testing; o czym odmawiam pisania. Hub znajduje się na stronie Apple Ecosystem Series. Szerszy kontekst iOS z agentami AI znajdziesz w przewodniku iOS Agent Development.

FAQ

Jaka jest różnica między NSPrivacyTracking a NSPrivacyCollectedDataTypeTracking?

NSPrivacyTracking to wartość Boolean na poziomie aplikacji: czy ta aplikacja w ogóle śledzi użytkowników (zgodnie z wąską definicją Apple)? NSPrivacyCollectedDataTypeTracking jest per typ danych: dla danego typu danych zbieranych przez aplikację, czy te dane są wykorzystywane do śledzenia? Aplikacja może zbierać dane bez śledzenia (analityka, która nie łączy danych między firmami); flaga per typ rejestruje, czy każdy konkretny typ danych przyczynia się do zachowania śledzącego.

Czy potrzebuję privacy manifestu dla wewnętrznej aplikacji TestFlight?

Tak. Egzekwowanie privacy manifestu odbywa się przy przesyłaniu do App Store Connect, w tym dla buildów TestFlight. Wewnętrzna beta bez manifestu nie przejdzie tej samej kontroli ITMS-91053 co wydanie publiczne.

Co się stanie, jeśli zadeklaruję Required Reason API bez jego użycia?

Nic funkcjonalnego. Manifest deklaruje górną granicę zakresu API; zadeklarowanie nieużywanej kategorii jest nieszkodliwe. Kosztem jest dryf dokumentacji: przyszli opiekunowie mogą założyć, że deklaracja odzwierciedla aktualny kod, podczas gdy w rzeczywistości wywołanie zostało usunięte. Właściwym posunięciem jest deklarowanie tego, czego aplikacja faktycznie używa, audytowane przy każdym dużym wydaniu.

Czy istnieją jakieś kategorie Required Reason API poza pierwotną piątką?

Według stanu na iOS 26 pierwotne pięć kategorii (znacznik czasu pliku, czas uruchomienia systemu, miejsce na dysku, aktywne klawiatury, User Defaults) pozostaje listą kanoniczną⁴. Apple z czasem dodawało zatwierdzone kody uzasadnienia w obrębie kategorii, ale nie rozszerzyło listy kategorii. Warto śledzić stronę dokumentacji Required Reason API Apple pod kątem dodatków.

Jak privacy manifest współdziała z App Tracking Transparency?

App Tracking Transparency (ATT) reguluje runtime’owe zapytanie o uprawnienie do śledzenia między aplikacjami. Privacy manifest deklaruje intencję aplikacji statycznie. Są one komplementarne: aplikacja, która prowadzi śledzenie między aplikacjami, deklaruje NSPrivacyTracking = true w manifeście oraz prosi o uprawnienie ATT w czasie wykonania. Aplikacja deklarująca NSPrivacyTracking = false nie powinna prosić o ATT (brak śledzenia między aplikacjami oznacza, że zapytanie jest zbędne).

Bibliografia