Privacylabels en SDK-declaratie: wat de stores sinds 2026 vragen
Sinds begin 2026 zijn de eisen rond privacylabels flink aangescherpt: niet alleen voor je eigen code, maar voor elke derde-partij-SDK die je meelevert. Dat verandert iets aan hoe je bouwt, want een bibliotheek toevoegen is nu ook een administratieve handeling.
Wat er precies wordt gevraagd
Beide stores vroegen al langer om een privacylabel: een overzicht van welke gegevens je app verzamelt, waarvoor, en of die aan de gebruiker gekoppeld zijn. Wat er sinds begin 2026 bij is gekomen, is de granulariteit. Je moet per categorie preciezer zijn, en de opgave strekt zich uit tot elke SDK van derden die in je app zit.
Dat laatste is de kern van de verandering. Een analytics-bibliotheek, een crashreporter, een advertentie-SDK of een chatwidget verzamelt gegevens, en dat telt mee als jouw verzameling. Je bent verantwoordelijk voor de opgave, ook al heb je de code niet geschreven en weet je niet precies wat erin gebeurt.
Daarnaast moet je expliciet aangeven of en hoe je AI-modellen gebruikt en welke gegevens daarbij gedeeld worden. Dat sluit aan op de bredere lijn dat automatische functies zichtbaar moeten zijn voor wie de app gebruikt.
Waar het in de praktijk misgaat
Het meest voorkomende probleem is niet onwil maar onwetendheid. Een team voegt gaandeweg een handvol bibliotheken toe, elk met een goede reden, en bij de storeopgave blijkt niemand te weten wat SDK nummer zeven precies naar buiten stuurt. Dan wordt er gegokt, en een verkeerde opgave is erger dan een onvolledige.
Het tweede probleem is drift. Je vult het label in bij de eerste publicatie en werkt het daarna niet bij, terwijl de app in de tussentijd drie nieuwe afhankelijkheden heeft gekregen. Bij de volgende controle klopt de opgave niet meer met de werkelijkheid.
Het derde is transitief: een SDK die zelf weer een andere SDK meebrengt. Wat die tweede laag doet zie je niet in je eigen projectbestand, terwijl het wel in je app zit.
Hoe je dit bijhoudt tijdens het bouwen
De praktische oplossing is administratief en kost weinig als je er vroeg mee begint. Houd één lijst bij van elke externe afhankelijkheid, met daarbij waarom die erin zit, welke gegevens die volgens de leverancier verwerkt en waar dat staat gedocumenteerd. Die lijst is tegelijk je bron voor de storeopgave en voor je verwerkingsregister.
Maak het toevoegen van een SDK een bewuste stap in plaats van een terloopse. Een bibliotheek erbij betekent een regel erbij op de lijst, en zonder die regel gaat hij er niet in. Dat klinkt bureaucratisch maar scheelt bij publicatie een middag zoekwerk.
Bouw je met AI-codegeneratie, let dan extra op: gegenereerde code brengt soms afhankelijkheden mee die je niet zelf hebt gekozen. Loop het projectbestand na voordat je publiceert, niet erna.
De verplichte verwijdermogelijkheid
Los van de labels geldt er nog een eis die vaak wordt gemist: gebruikers moeten in de app zelf hun account en de bijbehorende gegevens kunnen laten verwijderen. Niet via een mailtje naar de klantenservice, maar via een route die in de app te vinden is.
Dat lijkt een klein ding maar raakt je architectuur. Verwijderen betekent bepalen wat er weg moet, wat om administratieve of wettelijke redenen bewaard blijft, en wat er gebeurt met gegevens die al bij derden staan. Dat is een ontwerpvraag, geen knop die je op het laatst toevoegt.
