App Store-privacylabels: controleer eerst je analytics-SDK's (checklist 2026)

Je App Store-privacylabels moeten dekken wat je analytics- en andere third-party SDK's verzamelen, niet alleen wat je eigen code verstuurt. Voordat je de App Privacy-vragen in App Store Connect beantwoordt, maak je een lijst van elke SDK in de release, noteer je welke data elk ervan van het apparaat verstuurt en bepaal je of iets daarvan voor tracking wordt gebruikt. Antwoord op basis van die lijst, niet uit je geheugen.

Moeten App Store-privacylabels ook data van third-party SDK's bevatten?

Ja. Apple verplicht je om data op te geven die de code van third-party partners verzamelt, ook als de SDK die data voor andere doelen dan analytics of advertenties verzamelt.

Apples App Privacy-pagina definieert third-party partners als "analysetools, advertentienetwerken, third-party SDK's of andere externe leveranciers waarvan je de code aan je app hebt toegevoegd." Een crashreporter of een inlogbibliotheek hoort dus op je lijst. De toets voor verzamelen draait om verzending: "Verzamelen" betekent "data van het apparaat verzenden op een manier waardoor jij en/of je third-party partners er langer toegang toe hebben dan nodig is om het verzonden verzoek in realtime af te handelen." Data die alleen op het apparaat wordt verwerkt, geldt niet als verzameld.

Hoe stel je een SDK-inventaris op voor privacylabels?

Stel de inventaris op aan de hand van de opgeloste dependencies van de release-build, inclusief transitieve, en noteer van elke SDK de naam en versie.

1. Exporteer per platform de lijst met opgeloste dependencies: Podfile.lock, Package.resolved, pubspec.lock of je Gradle-dependencyboom.
2. Neem transitieve dependencies mee. Volgens Apples eisen voor third-party SDK's ben je "verantwoordelijk voor alle code die de SDK in je app opneemt", dus een gedeelde module die een SDK binnenhaalt telt ook mee.
3. Noteer van elke regel de naam en versie. Leveranciers veranderen tussen versies hoe ze met data omgaan, dus de versie hoort in je auditnotities.
4. Markeer SDK's die op Apples lijst van veelgebruikte third-party SDK's staan. Daarvoor eist Apple privacymanifests wanneer je een nieuwe app indient of een update die ze toevoegt, en handtekeningen wanneer het binaire dependencies zijn. "Elke versie van een SDK op de lijst, evenals SDK's die SDK's van de lijst opnieuw verpakken, valt hieronder."

Voeg deze stap toe aan je checklist voor App Store-indiening, zodat hij bij elke release wordt uitgevoerd en niet alleen bij de eerste.

Bij welke App Store-privacydatatypes hoort elke SDK?

Elke SDK hoort bij een of meer van Apples vaste datatypes, zoals Crash Data, Performance Data, Product Interaction, Device ID en Advertising Data. Lees de datadocumentatie van de leverancier en vul voor elke SDK een rij in:

Volgens Apple is verzamelde data "vaak gekoppeld aan de identiteit van de gebruiker, tenzij er vóór het verzamelen specifieke privacymaatregelen zijn getroffen om de data te de-identificeren of te anonimiseren", zoals het verwijderen van directe identificatoren als gebruikers-ID of naam. Na het verzamelen mag je de data ook niet opnieuw aan de gebruiker koppelen of verbinden met andere datasets die de gebruiker identificeren. Als je niet kunt bevestigen dat een SDK data de-identificeert, markeer die dan als gekoppeld.

Wanneer telt een analytics-SDK als tracking?

Een analytics-SDK telt als tracking wanneer die data over je gebruikers of apparaten koppelt aan data uit apps of sites van andere bedrijven voor gerichte advertenties of advertentiemeting, of die data deelt met een databroker.

Apples definitie is "data die vanuit je app is verzameld over een bepaalde eindgebruiker of een bepaald apparaat, zoals een gebruikers-ID, apparaat-ID of profiel, koppelen aan data van derden voor gerichte advertenties of advertentiemeting, of data die vanuit je app is verzameld over een bepaalde eindgebruiker of een bepaald apparaat delen met een databroker." Analytics die binnen de data van je eigen app blijft, is geen tracking. Advertentiemeting die een identificator over apps heen deelt, wel.

De valkuil is een partner die geen advertentie-SDK is. Apples voorbeeld is "een login-SDK die de data die hij vanuit je app verzamelt hergebruikt om gerichte advertenties in apps van andere ontwikkelaars mogelijk te maken". Dat telt als tracking, ook als jij de SDK niet voor dat doel gebruikt. Doet een van je SDK's dit, dan is de gebruikelijke oplossing een configuratiewijziging die het gebruik over apps heen stopt, of een andere leverancier.

Mag je SDK-data weglaten uit je privacylabels?

Alleen als een datatype aan alle vier de criteria van Apple voor optionele openbaarmaking voldoet, en analytics- en crashdata doen dat vrijwel nooit. De criteria zijn:

• De data wordt niet gebruikt voor tracking.
• De data wordt niet gebruikt voor advertenties van derden, je eigen advertenties of marketing, of andere doeleinden.
• De data wordt alleen in uitzonderlijke gevallen verzameld buiten de kernfunctionaliteit van de app, en is optioneel voor de gebruiker.
• De gebruiker verstrekt de data via de interface van de app, het is duidelijk voor hem wat er wordt verzameld, zijn naam of accountnaam staat prominent in het indieningsformulier en hij kiest er elke keer actief voor om de data te verstrekken.

Apple voegt daaraan toe dat "data die doorlopend wordt verzameld na een eerste toestemmingsverzoek, moet worden opgegeven." Analytics-SDK's draaien continu en de gebruiker kiest er niet elke keer voor, dus ze vallen door de laatste twee toetsen.

Hoe ziet een afgeronde SDK-audit eruit?

Een afgeronde audit geeft elke SDK één rij die aangeeft wat je opgeeft, of de data aan de gebruiker is gekoppeld en of die voor tracking wordt gebruikt. Hier is het sjabloon voor een fictieve habit-tracker-app met drie SDK's. De antwoorden hangen af van de documentatie van elke leverancier, dus dit zijn geen bevindingen over echte producten.

De inlogrij verandert het werk. Die maakt van de app een tracking-app, dus de labels moeten dat vermelden en je afhandeling van toestemming moet daarbij passen. Overstappen op een inlogleverancier die geen data over apps heen deelt, of dat delen uitzetten, is vóór de indiening veel goedkoper dan na een afwijzing. Test daarna de release-build met alle SDK's ingeschakeld, zoals in het testplan voor de release-build.

Wat ging er mis bij andere ontwikkelaars?

Openbaar gemelde gevallen laten drie faalpunten zien: labels die niet overeenkomen met de binary, SDK-data waarvan de ontwikkelaar niet op de hoogte was, en SDK's van de lijst die zonder manifest werden meegeleverd.

• Een ontwikkelaar op de Apple Developer Forums haalde tracking uit een nieuwe build, maar kon het niet van het label verwijderen. App Store Connect meldde "Your app contains NSUserTrackingUsageDescription, indicating that you will request permission to track users," en de review bleef afwijzen met "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." Volgens de ontwikkelaar werd de app goedgekeurd nadat die bezwaar had ingediend en het antwoord had afgewacht voordat die opnieuw indiende.
• Een andere ontwikkelaar op de Apple Developer Forums gebruikte Firebase Analytics met uitgeschakelde verzameling van IDFA en IDFV en een label 'geen tracking', en kreeg toch een afwijzing onder Guideline 5.1.2. Het bericht luidde: "Collecting cookies is a form of tracking." Het wees naar cookies op webcontent die de app laadde, niet naar Firebase. In een reactie werd op die mismatch gewezen; een oplossing werd niet gepost.
• Ontwikkelaars in een GitHub-issue van RxSwift kregen "ITMS-91061: Missing privacy manifest" voor RxSwift, RxRelay en RxCocoa. Eén gebruiker liet CocoaPods naar de 6.8.0-branch wijzen, die het manifest bevat, en meldde dat de volgende update werd uitgebracht "without any warnings from Apple."

De rode draad: Apple vergelijkt je antwoorden met wat de uitgeleverde binary en de webcontent ervan werkelijk doen. Een inventaris op basis van de echte build vangt dus alle drie de problemen op voordat de review dat doet.

Hoe publiceer en wijzig je privacylabels in App Store Connect?

Publiceer privacylabels vanuit het onderdeel App Privacy van je app in App Store Connect. De antwoorden gaan pas live nadat je op Publish klikt, en volgens Apple kun je ze op elk moment wijzigen zonder een app-update in te dienen.

1. Selecteer in App Store Connect de app, klik in de zijbalk op App Privacy en klik daarna op Get Started.
2. Geef aan of jij of je third-party partners data verzamelen, selecteer elk datatype uit je audit en klik op Save.
3. Beantwoord de vervolgvragen voor elk datatype, klik op Save en bekijk de Product Page Preview.
4. Klik rechtsboven op Publish en bevestig het dialoogvenster over de juistheid.

Volgens Manage app privacy heb je de rol Account Holder, Admin of App Manager nodig. Staat de productpagina nog niet live, dan worden je antwoorden gepubliceerd zodra die live gaat. Is de app al te koop, dan moeten je antwoorden alleen de data weergeven die door die versie wordt verzameld. Wijzigingen in URL's van het privacybeleid "gaan mee met je volgende appversie." Heeft de review al privacyproblemen gesignaleerd, begin dan met de gids voor het oplossen van App Store-afwijzingen.