Etykiety prywatności w App Store: najpierw sprawdź SDK analityczne (checklista 2026)

Twoje etykiety prywatności w App Store muszą obejmować to, co zbierają SDK analityczne i inne zewnętrzne SDK, a nie tylko to, co wysyła twój własny kod. Zanim odpowiesz na pytania App Privacy w App Store Connect, wypisz każde SDK w wydaniu, zanotuj dane, które każde z nich wysyła poza urządzenie, i zdecyduj, czy którekolwiek z nich służą do śledzenia. Odpowiadaj na podstawie tej listy, a nie z pamięci.

Czy etykiety prywatności App Store muszą obejmować dane z zewnętrznych SDK?

Tak. Apple wymaga deklarowania danych zbieranych przez kod partnerów zewnętrznych, nawet jeśli SDK zbiera te dane w celach innych niż analityka czy reklama.

Strona App Privacy Apple definiuje partnerów zewnętrznych jako „narzędzia analityczne, sieci reklamowe, zewnętrzne SDK lub innych zewnętrznych dostawców, których kod dodałeś do swojej aplikacji”. Dlatego narzędzie do raportowania awarii czy biblioteka logowania też trafiają na twoją listę. Kryterium zbierania dotyczy transmisji: „zbieranie” oznacza „przesyłanie danych poza urządzenie w sposób, który pozwala tobie i/lub twoim partnerom zewnętrznym uzyskiwać do nich dostęp przez okres dłuższy niż niezbędny do obsłużenia przesłanego żądania w czasie rzeczywistym”. Dane przetwarzane wyłącznie na urządzeniu nie są zbierane.

Jak przygotować inwentaryzację SDK na potrzeby etykiet prywatności?

Zbuduj inwentaryzację z rozwiązanych zależności buildu wydania, łącznie z zależnościami przechodnimi, i zapisz nazwę oraz wersję każdego SDK.

1. Wyeksportuj listę rozwiązanych zależności dla każdej platformy: Podfile.lock, Package.resolved, pubspec.lock lub drzewo zależności Gradle.
2. Uwzględnij zależności przechodnie. Wymagania Apple dotyczące zewnętrznych SDK mówią, że jesteś „odpowiedzialny za cały kod, który SDK dołącza do twojej aplikacji”, więc wspólny moduł dociągany przez SDK też się liczy.
3. Zapisz nazwę i wersję każdej pozycji. Dostawcy zmieniają sposób obsługi danych między wersjami, więc wersja powinna znaleźć się w notatkach z audytu.
4. Oznacz SDK, które znajdują się na liście Apple popularnych zewnętrznych SDK. W ich przypadku Apple wymaga manifestów prywatności przy przesyłaniu nowej aplikacji lub aktualizacji, która je dodaje, a także podpisów, jeśli są zależnościami binarnymi. „Uwzględniana jest każda wersja SDK z listy, a także wszelkie SDK, które przepakowują SDK z listy”.

Dodaj ten krok do swojej checklisty publikacji w App Store, aby wykonywać go przy każdym wydaniu, a nie tylko przy pierwszym.

Do jakich typów danych prywatności App Store przypisać każde SDK?

Każde SDK odpowiada jednemu lub kilku stałym typom danych Apple, takim jak dane o awariach (Crash Data), dane o wydajności (Performance Data), interakcje z produktem (Product Interaction), identyfikator urządzenia (Device ID) i dane reklamowe (Advertising Data). Przeczytaj dokumentację dostawcy dotyczącą danych i wypełnij wiersz dla każdego SDK:

Apple podaje, że zbierane dane „często są powiązane z tożsamością użytkownika, chyba że przed zebraniem wprowadzono określone zabezpieczenia prywatności, aby je zdeidentyfikować lub zanonimizować”, na przykład usunięcie bezpośrednich identyfikatorów, takich jak identyfikator użytkownika czy imię i nazwisko. Po zebraniu nie wolno też ponownie wiązać danych z użytkownikiem ani łączyć ich z innymi zbiorami danych, które go identyfikują. Jeśli nie możesz potwierdzić, że SDK deidentyfikuje dane, oznacz je jako powiązane z użytkownikiem.

Kiedy SDK analityczne liczy się jako śledzenie?

SDK analityczne liczy się jako śledzenie, gdy łączy dane o twoich użytkownikach lub urządzeniach z danymi z aplikacji lub stron innych firm na potrzeby reklam targetowanych lub pomiaru reklam albo udostępnia te dane brokerowi danych.

Definicja Apple brzmi: „łączenie danych zebranych w twojej aplikacji o konkretnym użytkowniku końcowym lub urządzeniu, takich jak identyfikator użytkownika, identyfikator urządzenia lub profil, z danymi stron trzecich na potrzeby reklam targetowanych lub pomiaru reklam albo udostępnianie danych zebranych w twojej aplikacji o konkretnym użytkowniku końcowym lub urządzeniu brokerowi danych”. Analityka, która pozostaje w obrębie danych twojej własnej aplikacji, nie jest śledzeniem. Pomiar reklam, który współdzieli identyfikator między aplikacjami, już tak.

Pułapką jest partner, który nie jest SDK reklamowym. Przykład Apple to „SDK logowania, które wykorzystuje dane zbierane z twojej aplikacji do umożliwienia reklam targetowanych w aplikacjach innych deweloperów”, co liczy się jako śledzenie, nawet jeśli ty nie używasz SDK w tym celu. Jeśli któreś z twoich SDK tak robi, zwykle rozwiązaniem jest zmiana konfiguracji, która wyłącza wykorzystanie danych między aplikacjami, albo zmiana dostawcy.

Czy można pominąć jakieś dane z SDK w etykietach prywatności?

Tylko wtedy, gdy dany typ danych spełnia wszystkie cztery kryteria Apple dotyczące opcjonalnego ujawniania, a dane analityczne i dane o awariach prawie nigdy ich nie spełniają. Kryteria są następujące:

• Dane nie są używane do śledzenia.
• Dane nie są używane do reklam stron trzecich, twoich własnych reklam lub marketingu ani do innych celów.
• Dane są zbierane tylko sporadycznie, poza podstawową funkcjonalnością aplikacji, a ich podanie jest dla użytkownika opcjonalne.
• Użytkownik podaje je w interfejsie aplikacji, jest dla niego jasne, co jest zbierane, jego imię i nazwisko lub nazwa konta są wyraźnie widoczne w formularzu przesyłania, a za każdym razem świadomie decyduje się je podać.

Apple dodaje, że „dane zbierane w sposób ciągły po początkowej prośbie o zgodę muszą zostać ujawnione”. SDK analityczne działają nieprzerwanie, a użytkownik nie decyduje o nich za każdym razem, więc nie spełniają dwóch ostatnich kryteriów.

Jak wygląda gotowy audyt SDK?

Gotowy audyt przypisuje każdemu SDK jeden wiersz, który określa, co zadeklarować, czy dane są powiązane z użytkownikiem i czy służą do śledzenia. Oto szablon dla hipotetycznej aplikacji do śledzenia nawyków z trzema SDK. Odpowiedzi zależą od dokumentacji każdego dostawcy, więc nie są to ustalenia dotyczące rzeczywistych produktów.

Wiersz logowania zmienia zakres pracy. Czyni aplikację aplikacją śledzącą, więc etykiety muszą to uwzględniać, a obsługa zgód musi być z nimi spójna. Przejście na dostawcę logowania, który nie udostępnia danych między aplikacjami, lub wyłączenie takiego udostępniania jest znacznie tańsze przed wysłaniem do recenzji niż po odrzuceniu. Następnie przetestuj build wydania ze wszystkimi włączonymi SDK, tak jak w planie testów buildu wydania.

Co poszło nie tak u innych deweloperów?

Publicznie opisane przypadki pokazują trzy punkty awarii: etykiety niezgodne z plikiem binarnym, dane z SDK, o których deweloper nie wiedział, oraz SDK z listy wysłane bez manifestów.

• Deweloper na Apple Developer Forums usunął śledzenie z nowego buildu, ale nie mógł usunąć go z etykiety. App Store Connect pokazywał komunikat "Your app contains NSUserTrackingUsageDescription, indicating that you will request permission to track users," a recenzja wciąż odrzucała aplikację z uzasadnieniem "The app privacy information you provided in App Store Connect indicates you collect data in order to track the user… However, you do not use App Tracking Transparency." Deweloper napisał, że aplikacja została zatwierdzona po złożeniu odwołania i odczekaniu na odpowiedź przed ponownym przesłaniem.
• Inny deweloper na Apple Developer Forums używał Firebase Analytics z wyłączonym zbieraniem IDFA i IDFV oraz etykietą „brak śledzenia”, a mimo to otrzymał odrzucenie z Guideline 5.1.2. Komunikat brzmiał: "Collecting cookies is a form of tracking." Wskazywał on na pliki cookie w treściach webowych ładowanych przez aplikację, a nie na Firebase. W odpowiedzi ktoś zwrócił uwagę na tę rozbieżność, ale nie opublikowano rozwiązania.
• Deweloperzy w zgłoszeniu na GitHubie RxSwift otrzymali "ITMS-91061: Missing privacy manifest" dla RxSwift, RxRelay i RxCocoa. Jeden z użytkowników skierował CocoaPods na gałąź 6.8.0, która zawiera manifest, i zgłosił, że wydał kolejną aktualizację „bez żadnych ostrzeżeń od Apple”.

Wspólny mianownik: Apple porównuje twoje odpowiedzi z tym, co faktycznie robi wysłany plik binarny i jego treści webowe, więc inwentaryzacja zbudowana na podstawie rzeczywistego buildu wychwyci wszystkie trzy problemy, zanim zrobi to recenzja.

Jak opublikować i zaktualizować etykiety prywatności w App Store Connect?

Etykiety prywatności publikujesz w sekcji App Privacy swojej aplikacji w App Store Connect. Odpowiedzi stają się widoczne dopiero po kliknięciu Publish, a Apple podaje, że możesz je zmieniać w dowolnym momencie bez przesyłania aktualizacji aplikacji.

1. W App Store Connect wybierz aplikację, kliknij App Privacy na pasku bocznym, a następnie Get Started.
2. Określ, czy ty lub twoi partnerzy zewnętrzni zbieracie dane, zaznacz każdy typ danych z audytu i kliknij Save.
3. Odpowiedz na pytania uzupełniające dla każdego typu danych, kliknij Save i przejrzyj Product Page Preview.
4. Kliknij Publish w prawym górnym rogu i potwierdź okno dotyczące poprawności danych.

Zgodnie z Manage app privacy potrzebujesz roli Account Holder, Admin lub App Manager. Jeśli strona produktu nie jest jeszcze opublikowana, twoje odpowiedzi zostaną opublikowane razem z nią. Jeśli aplikacja jest już w sprzedaży, odpowiedzi powinny odzwierciedlać wyłącznie dane zbierane przez tę wersję. Zmiany adresów URL polityki prywatności „zostaną wydane z następną wersją aplikacji”. Jeśli recenzja już zgłosiła problemy z prywatnością, zacznij od poradnika naprawy odrzuceń w App Store.