Vereisten voor het verwijderen van app-accounts stellen dat elke app die accountaanmaak aanbiedt, mensen ook moet laten dat account en de gegevens erachter verwijderen. Apple wil dat pad in de app zelf. Google wil het zowel in de app als op het web. Mis een van beide, en uw release komt stil te liggen.
U heeft vrijwel zeker al een scherm Account verwijderen uitgebracht. De lastigere vraag is of dat aan beide winkels voldoet, want de twee regels zijn niet identiek. Teams die dit ooit voor iOS hebben opgelost, zijn op Android routinematig niet-conform, zonder dat iemand hen dat ooit vertelt.
Het verkeerd doen is zelden in één dag te repareren. Een afwijzing kost een beoordelingscyclus die u had ingepland voor de lancering. Erger nog, een live app die tijdens een hercontrole van het beleid wordt verwijderd, kost omzet terwijl u herbouwt en opnieuw indient. Geen van beide uitkomsten komt naar voren in een codereview, want er is technisch niets kapot.
Deze gids behandelt wat elke winkel controleert en waarom een deactiveringsschakelaar niet volstaat. Ook laat hij zien hoe u bevestigt dat uw flow werkt voordat een reviewer dat voor u doet. Wilt u die verificatie liever overlaten aan een team dat dit elke week uitvoert? Daar dienen onze diensten voor het testen van softwarenaleving voor.
Wat vereisten voor het verwijderen van app-accounts betekenen, en wie eraan moet voldoen
Haal de beleidstaal eraf en de regel wordt kort. Als mensen in uw product een account kunnen aanmaken, moeten ze dat account zonder de app te verlaten ook kunnen verwijderen. Het record verdwijnt, en daarmee ook de persoonlijke gegevens die eraan vastzitten.
U valt binnen de reikwijdte als een van deze uw app beschrijft:
- Elke App Store- of Google Play-vermelding die accountaanmaak aanbiedt
- Aanmelding via een sociale login in plaats van een native formulier
- Aanmelding die op uw website gebeurt in plaats van in de app
- Onboarding die stilzwijgend een account voor de gebruiker aanmaakt
Apple sluit het voor de hand liggende achterdeurtje rechtstreeks af. Wanneer een app mensen naar een browser stuurt om zich te registreren, blijft de app hen alsnog verwijdering binnen de app verschuldigd, en het uitbesteden van die stap verandert daar niets aan. De App Store Review Guidelines leggen de plicht dus bij de app die het account heeft aangeboden.
Aan Googles kant bestaan twee smalle uitzonderingen, waarbij permanent privé-apps en tools voor enterprise-apparaatbeheer buiten het beleid vallen. Alle anderen vallen eronder, dus de vereiste voor accountverwijdering in de appstore geldt ongeacht of uw gebruikers betalen.
Apple versus Google: waar elke vereiste voor accountverwijdering geldt
De meeste teams gaan ervan uit dat één implementatie voor beide winkels volstaat. Dat is niet zo, en vereisten voor het verwijderen van app-accounts lopen precies op één rij in deze tabel uiteen.
Waar het pad moet bestaan
In de app
In de app, plus een weblink die elke gebruiker kan bereiken
Wat weg moet
Het volledige accountrecord en de bijbehorende persoonlijke gegevens, inclusief content die met anderen is gedeeld
Het account en de gebruikersgegevens die eraan vastzitten
Tijdelijke opschorting
Deactivering alleen is “onvoldoende”
“Geldt niet als accountverwijdering”
Waar u het aangeeft
In de app zelf, en in reviewnotities wanneer een gereguleerde flow van toepassing is
In het URL-veld van Play Console en op uw storevermelding
Hoe het wordt gehandhaafd
Afwijzing bij review
Afwijzing bij review, en verwijdering na een hercontrole van live vermeldingen
De Apple-vereiste voor accountverwijdering is de eenvoudigere van de twee. Er is één bereikbaar pad nodig, gestart in de app, dat het record verwijdert in plaats van het te parkeren. Ons werk op het gebied van App Store-nalevingstesten behandelt dat als een gedragscontrole in plaats van een schermafbeelding.
Google voegt echter een tweede verplichting toe, en daar struikelen de meeste cross-platform teams. We vergeleken beide regelboeken volledig in Apple App-richtlijnen versus Google Play-beleid.
Waarom de Google Play-vereiste voor accountverwijdering iOS-first teams verrast
Hier is het feit dat een geslaagde iOS-build in een Android-afwijzing verandert. Google verplicht u om “gebruikers een pad in de app te bieden om hun app-accounts en bijbehorende gegevens te verwijderen”. Vervolgens voegt Google een tweede plicht toe: “bied een webresource waar gebruikers verwijdering van hun app-account kunnen aanvragen”. U heeft beide routes nodig, het is dus geen kwestie van ‘het een of het ander’.
De redenering is praktisch, want iemand die uw app al heeft verwijderd, kan geen knop erin aantikken. Die persoon heeft nog steeds een account op uw servers, dus wil Google een route die de deïnstallatie overleeft, iets wat geen scherm in de app kan bieden.
Hier misleidt veel van het openbare advies u actief. Verschillende veelgelezen pagina’s stellen dat Google verwijdering vanuit de app vereist in plaats van via een externe website, wat het beleid omdraait. In werkelijkheid vraagt Google’s eigen vereisten voor accountverwijdering om allebei. U geeft de webroute aan in het Google Play-gegevensveiligheidsformulier dat op uw vermelding verschijnt.
Die weblink kent zijn eigen voorwaarden, en die zijn testbaar. Google verwacht dat de pagina “functioneel is (laadt bijvoorbeeld zonder fouten)” en “prominent aanwezig en gemakkelijk vindbaar” is. Een formulier achter een login die uw gedeïnstalleerde gebruikers niet kunnen passeren, faalt op beide punten. Hetzelfde geldt voor een supportadres dat een mens uiteindelijk beantwoordt.
Een ontbrekend eindpunt is inmiddels een erkende afwijzingstrigger in plaats van een uitzonderingsgeval. We behandelden dat bij de actuele Google Play-afwijzingsredenen. Daarom is het controleren van de link routine in onze Google Play-nalevingstests.
Een account deactiveren is het niet verwijderen
Veel gelanceerde flows verwijderen helemaal niets. Ze zetten een statuskolom om, verbergen het profiel en houden elk record precies zoals het was. Voor de gebruiker leest dat als verwijdering, voor een reviewer als bewaring. Het is dan ook niet verrassend dat beide winkels dat achterdeurtje schriftelijk hebben gesloten.
Google’s beleid voor gebruikersgegevens is bot: “Tijdelijke accountdeactivering, uitschakeling of het ‘bevriezen’ van het app-account geldt niet als accountverwijdering.” Het voegt toe dat het verwijderen van het account u ook verplicht om de bijbehorende gebruikersgegevens te verwijderen.
Apple komt vanuit de andere richting op hetzelfde punt uit. De richtlijnen voor accountverwijdering stellen dat “alleen de mogelijkheid bieden om een account tijdelijk te deactiveren of uit te schakelen onvoldoende is”. Apple rekent ook door gebruikers gegenereerde content die met anderen is gedeeld tot accountgegevens. Foto’s, berichten en reviews vallen dus allemaal binnen de reikwijdte.
Het is eerlijk om te benoemen waarom dit patroon zo vaak voorkomt. Zachte verwijdering is oprecht goede engineering voor herstel, betalingsgeschillen en misbruikonderzoek. Het wordt echter pas een nalevingsprobleem wanneer niets ooit de klus afmaakt. Dat gat is meestal een ontbrekend achtergrondproces, geen slechte beslissing.
Eén scherm, vijf systemen: wat er achter de verwijderknop schuilt
Voor een directielid dat afweegt waar het QA-budget naartoe gaat, is dit het duidelijkste voorbeeld van verborgen complexiteit in het hele indieningsproces. Verwijdering neemt één scherm in uw interface in beslag. Daaronder reikt het echter in vijf systemen die nooit zijn ontworpen om het met elkaar eens te zijn.
- Uw identiteitsprovider, die mogelijk een token bewaart dat het lokale record overleeft
- Actieve abonnementen, waarbij een geannuleerd account een levende factureringsrelatie kan achterlaten
- Analytics- en crash-SDK’s van derden die kopieën bewaren die u zelf nooit heeft geschreven
- Records die u bewust bewaart om fraude-, belasting- of auditredenen
- Het webeindpunt, dat meestal op andere code draait dan het pad in de app
Elk systeem kan afzonderlijk slagen en het account toch deels intact laten. Een gebruiker verwijdert zijn profiel, en twee dagen later komt er een pushmelding binnen omdat één dienst het bericht nooit ontving. Er trad geen fout op, en de flow meldde succes.
De storing die het meest kost, is de stille. Gegevens waarvan u dacht dat ze weg waren, blijven bereikbaar via een API die niemand opnieuw heeft gecontroleerd nadat de verwijderfunctie live ging. Dat gat vinden ligt dichter bij penetratietesten dan bij functionele QA, want het betekent onderzoeken naar wat niet meer zou moeten reageren.
Wat er verandert als u in een gereguleerde sector zit
Als u een fintech-, healthtech- of medtech-product runt, heeft u de spanning waarschijnlijk al opgemerkt. Sommige records moeten wettelijk een verwijderverzoek overleven, en beide winkels houden daar rekening mee, al minder ruim dan teams verwachten.
Apple staat apps in sterk gereguleerde sectoren toe om “aanvullende klantenserviceflows te gebruiken om het proces van accountverwijdering te bevestigen en te faciliteren”. Lees dat zorgvuldig, want het staat een extra bevestigingsstap toe, geen vervanging. Apps buiten die sectoren krijgen die ruimte niet. Apple zegt dat zij “mensen niet mogen verplichten om te bellen, te e-mailen of andere supportflows te doorlopen”.
Googles tegemoetkoming gaat over reikwijdte in plaats van route. U mag specifieke gegevens bewaren voor beveiliging, fraudepreventie of wettelijke naleving, mits u “gebruikers duidelijk informeert over uw praktijken voor gegevensbewaring”. Gedeeltelijke verwijdering is dus legitiem wanneer die wordt vermeld, en alles stilzwijgend bewaren is dat niet.
De praktische conclusie is dat regelgeving verandert wát u verwijdert, nooit óf gebruikers erom mogen vragen. Ondertussen worden aangiftes bij beide winkels inmiddels veel agressiever gecontroleerd. We volgden die verschuiving in onze blik op Apples AI-richtlijnen voor gegevensdeling.
Zo test u of uw verwijderknop echt verwijdert
Bijna elke gids over vereisten voor het verwijderen van app-accounts stopt bij het beleid. De meeste vertellen u vervolgens om een clausule aan uw privacyverklaring toe te voegen. Geen enkele stelt de enige vraag waar een reviewer om geeft, namelijk of de knop doet wat het scherm belooft. Dit is de reeks die wij uitvoeren.
- Verwijder een echt account via het pad in de app, en probeer vervolgens opnieuw in te loggen met dezelfde gegevens.
- Herhaal de hele oefening via de webroute, vanaf een toestel waarop de app nooit heeft gestaan.
- Controleer de identiteitsprovider rechtstreeks en bevestig dat een eventueel sociale-logintoken is ingetrokken, niet verweesd achtergebleven.
- Bevraag uw eigen API’s op de verwijderde gebruiker via ID, niet via zoeken, en bevestig dat niets nog antwoordt.
- Controleer of een actief abonnement wordt geannuleerd of duidelijk wordt uitgelegd, in plaats van stilzwijgend te blijven factureren.
- Wacht 48 uur en let dan op pushmeldingen, samenvattende e-mails of analyticsgebeurtenissen die aan die gebruiker zijn gekoppeld.
- Laad de openbare verwijderpagina in een privévenster en meet hoe lang het duurt om die te vinden.
Stap 6 vangt meer echte storingen op dan de rest samen, want asynchrone taken zijn waar verwijdering meestal breekt. Vindbaarheid is de controle die teams het vaakst overslaan, terwijl een reviewer die binnen enkele seconden beoordeelt.
Niet dit alles is op u van toepassing. Heeft uw app geen accounts, dan geldt niets hiervan. Een verwijderflow toevoegen aan een product zonder aanmelding verspilt gewoon een sprint.
Tools voor enterprise-apparaatbeheer en permanent privé-apps vallen ook buiten Googles beleid. Ga buiten die gevallen ervan uit dat u binnen de reikwijdte valt. Behandel elke claim van vrijstelling als iets om vóór indiening te verifiëren, niet nadat een afwijzingsbericht binnenkomt. Afwijzingen clusteren rond aannames als deze, zoals ons overzicht van App Store-afwijzingsredenen laat zien.
Hoe QAwerk winkelnaleving verifieert voordat u indient
Winkelnalevingswerk is het soort niche werk dat de meeste QA-leveranciers overslaan, want het beloont diepgaande kennis van één regelboek boven breed testen. Wij voeren App Store- en Google Play-controles uit als staande dienst. Dat betekent dat we al weten welke claims reviewers verifiëren en welke ze slechts lezen.
Bij een geblokkeerde release bepaalt snelheid de uitkomst. Ons team-extensiemodel zet binnen dagen in plaats van weken engineers op uw indiening. Een afgewezen build wordt dus gediagnosticeerd terwijl het reparatievenster nog open is. Wij testen het gedrag achter elke aangifte en overhandigen vervolgens het bewijs in een vorm die u aan een bezwaar kunt toevoegen.
Wilt u weten of uw verwijderflow een review zou doorstaan? Vraag een nalevingsaudit aan bij ons team.
Veelgestelde vragen
Heeft mijn app een functie voor accountverwijdering nodig?
Ja, als gebruikers een account kunnen aanmaken. Vereisten voor het verwijderen van app-accounts gelden voor elke App Store- en Google Play-vermelding die aanmelding aanbiedt. Zowel sociale logins als accounts die tijdens onboarding worden aangemaakt, tellen mee. Google maakt alleen een uitzondering voor permanent privé-apps en tools voor enterprise-apparaatbeheer. Al het andere heeft een werkend pad nodig dat het account en de bijbehorende gegevens verwijdert, niet één dat ze verbergt.
Wat zijn Apples vereisten voor accountverwijdering?
Apple verplicht apps die accountaanmaak ondersteunen om mensen verwijdering binnen de app te laten starten, een regel die van kracht is sinds 30 juni 2022. Het accountrecord en de bijbehorende persoonlijke gegevens moeten weg, inclusief content die met andere gebruikers is gedeeld. Alleen tijdelijke deactivering aanbieden is expliciet onvoldoende, en niet-gereguleerde apps mogen gebruikers niet naar e-mail- of telefonische support duwen in plaats daarvan.
Is een account deactiveren hetzelfde als het verwijderen?
Nee, en beide winkels zeggen dat schriftelijk. Google’s beleid voor gebruikersgegevens stelt dat tijdelijke deactivering, uitschakeling of het bevriezen van een account niet geldt als verwijdering. Apple noemt een optie die alleen deactiveert onvoldoende. Als uw flow een statusvlag omzet en de onderliggende records intact laat, faalt die bij review, ook al zien gebruikers een bevestigingsbericht.
Heb ik een webpagina nodig voor accountverwijdering op Google Play?
Ja, Google vereist zowel een verwijderpad in de app als een webresource, niet het een of het ander. De webroute bestaat voor mensen die uw app al hebben gedeïnstalleerd en geen scherm in de app meer kunnen bereiken. Die pagina moet zonder fouten laden en gemakkelijk te vinden zijn. U geeft de URL ervan op, zodat die op uw Play Store-vermelding verschijnt.
Ontdek hoe we onboardingflows voor een crypto-assetmanagementplatform hebben geoptimaliseerd, waardoor de gebruikersuitval met 15% is verminderd
