Guideline 5.1.1: cum înțelegi și repari un refuz App Store

Guideline 5.1.1 este regula Apple despre colectarea și stocarea datelor. La cele trei refuzuri primite din această familie, cauza a fost una dintre aceste două nepotriviri: ce făcea aplicația cu datele nu se potrivea cu ce era declarat, sau cererea de permisiune îl împingea pe utilizator să spună da.

Articolul ăsta tratează doar această regulă: alineatele ei, ce verific înainte de trimitere și ce trebuie corectat, cu trei refuzuri pe care le-am primit pe propriile aplicații. Pentru imaginea de ansamblu a tuturor motivelor, citește mai bine de ce refuză Apple o aplicație.

Ce este guideline 5.1.1?

Guideline 5.1.1, „Data Collection and Storage”, stabilește ce trebuie să respecte o aplicație de îndată ce atinge date personale: o politică de confidențialitate completă, un consimțământ înainte de colectare, cereri de permisiune oneste și un cont care poate fi șters. Se aplică tuturor aplicațiilor, chiar și celor care nu colectează aproape nimic.

Textul oficial se găsește în App Review Guidelines, secțiunea 5 „Legal”, partea 5.1 „Privacy”. Mesajul Apple citează adesea un alineat precis, între paranteze: 5.1.1(i), 5.1.1(iv), 5.1.1(v). Alineatul ăsta îți spune unde să cauți.

Cele cinci alineate din 5.1.1 pe care trebuie să le știi mai întâi

Alineat	Ce cere Apple	Refuzul tipic
5.1.1(i) Privacy Policies	Politică completă și legată	Lipsă sau incompletă
5.1.1(ii) Permission	Consimțământ înainte de colectare	Text de permisiune vag
5.1.1(iii) Data Minimization	Doar datele utile	Acces complet la poze
5.1.1(iv) Access	Să nu împingi la acceptare	Ecran care împinge la acceptare
5.1.1(v) Account Sign-In	Fără cont impus	Autentificare obligatorie

Trei precizări. Politica de confidențialitate are link în App Store Connect și în aplicație. Ea spune ce date sunt colectate, cum și în ce scop, confirmă că terții care le primesc oferă aceeași protecție și explică cum îți retragi acordul sau ceri ștergerea datelor. O funcție plătită nu poate depinde de un acces la date pe care utilizatorul e liber să-l refuze. Și un cont creat în aplicație trebuie să poată fi șters din aplicație.

Regula mai are și alte alineate, de la (vi) la (x), despre cazuri mai speciale, cum ar fi domeniile reglementate sau compilarea de date personale.

Cele trei lucruri pe care le compar înainte de trimitere

Nu am manualul de lucru al reviewerului. Iată ce compar eu înainte de fiecare trimitere, pentru că refuzurile mele au venit dintr-o nepotrivire între aceste elemente:

• ce spune politica publicată online, la URL-ul declarat în App Store Connect;
• ce face aplicația în realitate, ecran cu ecran, inclusiv fiecare cerere de permisiune;
• ce e declarat în fișa aplicației, în partea despre confidențialitatea aplicației (App Privacy Details).

Testez și fiecare ecran de permisiune închizând aplicația și apoi repornind-o. Asta e cauza pe care am identificat-o la al doilea refuz pe Nolera.

Trei refuzuri 5.1.1 pe care le-am primit și cauza lor reală

Clic: politica online era versiunea veche

Clic transformă un produs în slide-uri gata de publicat, cu AI. Pe 16 septembrie 2026, Apple refuză aplicația citând 5.1.1(i) și 5.1.2(i). Ecranul de consimțământ pentru AI era în aplicație. Problema era în afara aplicației: politica de confidențialitate publicată pe site era versiunea veche. Cea nouă exista, dar nu fusese pusă online.

Corecția: politica completă publicată, un rezumat în engleză adăugat pentru reviewer, notele de review actualizate. N-am făcut un build nou: am retrimis aceeași submisie.

Lecția: Apple citește ce e online, nu ce e în repository-ul tău. În ziua trimiterii, deschide URL-ul politicii tale și caută numele fiecărui serviciu terț pe care îl folosește aplicația.

Nolera: un buton „Allow” înaintea cererii sistemului

Nolera e aplicația mea de garderobă. Pe 17 septembrie 2026, după un review pe iPad Air, Apple citează 5.1.1(iv). Înaintea cererii de acces la cameră, aplicația afișa un ecran explicativ cu un buton „Allow the camera”.

Regulile de design ale Apple sunt precise aici. Un ecran propriu pus înaintea unei cereri a sistemului trebuie să aibă un singur buton, care deschide acea cerere. Apple recomandă un termen ca „Continue” sau „Next”, și nu „Allow”: un buton care seamănă cu cel al sistemului te împinge să apeși apoi pe adevăratul „Allow” fără să fi vrut.

Regula vizează ecranele puse înaintea unei cereri a sistemului: cameră, microfon, locație, contacte, calendar, tracking. Lasă o excepție, pentru un consimțământ cerut de lege.

Corecția: butonul se numește „Continue”, în cele 8 limbi ale aplicației.

Lecția: un ecran care pregătește o permisiune explică. Nu decide în locul utilizatorului.

Nolera, al doilea refuz: ecranul „cameră refuzată” apărea înaintea cererii

Retrimisă, Nolera e refuzată a doua oară pe 22 septembrie 2026, tot pe 5.1.1(iv), de data asta pe iPad Pro de 11 inci. Apple semnalează două puncte: o trimitere către Settings înaintea cererii de acces și un ecran pe care îl puteai părăsi fără să vezi această cerere.

Cauza pe care am identificat-o: un caz pe care nu-l testasem. Ecranul de fotografiere își afișa panoul „cameră refuzată”, cu linkul către Settings și o soluție alternativă, imediat ce accesul nu era acordat. Inclusiv când nu fusese cerut niciodată. Pe traseul normal, ecranul explicativ venea înainte și totul mergea bine. Dar dacă închideai aplicația la jumătate și o reporneai, ajungeai direct la fotografiere, fără să fi văzut cererea sistemului.

Corecția: cât timp iOS mai poate pune întrebarea, ecranul declanșează singur cererea sistemului. Panoul „cameră refuzată” apare doar după un refuz real. Corecția asta a cerut un build nou, pentru că reviewerul testează codul inclus în aplicație.

Lecția: „niciodată cerut” și „refuzat” sunt două stări diferite. Testează fiecare ecran de permisiune revenind la el după ce ai închis aplicația, nu doar în ordinea traseului.

5.1.1 și AI: ce adaugă 5.1.2(i)

La Clic, Apple a citat 5.1.2(i) pe lângă 5.1.1. Regula asta cere să indici clar unde sunt partajate datele personale cu terți și numește explicit AI-ul terț („third-party AI”). Cere și o permisiune explicită înainte de partajare.

Ce fac de la refuzul ăsta: trei lucruri coerente între ele.

• Un ecran de consimțământ în aplicație, înainte de primul trimis, care spune la ce serviciu pleacă datele și care anume.
• Aceeași informație în politica de confidențialitate online.
• Aceeași informație în declarațiile de confidențialitate din fișă.

Detaliile despre ce trebuie să conțină politica sunt în politica de confidențialitate a unei aplicații.

Ce să-i răspunzi lui Apple după un refuz 5.1.1

Conversația are loc în secțiunea App Review a aplicației tale, în App Store Connect. Procedura oficială pentru a răspunde la App Review e aceeași ca la celelalte reguli. Scrie în engleză, sobru: ce era problema, ce s-a schimbat, cum se verifică. Iată modelul pe care îl folosesc (înlocuiește numărul de build și corecția cu ale tale):

Hello,

Thank you for your review.

Issue: the custom screen shown before the camera permission
request used an "Allow" button, and the "camera denied" panel
could appear before the system alert had ever been shown.

Fix in build X:
- The custom screen now has a single "Continue" button that
  opens the system alert.
- The "camera denied" panel only appears after the user has
  actually denied access in the system alert.

How to verify: delete the app, install this build, launch it
and go to the photo step. The system alert appears first.

Best regards,

Sunt două cazuri:

• Cauza e online (politică, pagină de suport, declarațiile din fișă): corectezi, răspunzi, iar aceeași submisie poate pleca din nou fără build nou.
• Cauza e în aplicație (ecran, buton, ordinea cererilor): ai nevoie de un build nou. Un update de la distanță nu ajunge, cum explic în ghidul despre guideline 2.1.

Checklist-ul 5.1.1 înainte de trimitere

• URL-ul politicii tale de confidențialitate se deschide, iar pagina online e ultima versiune.
• Politica numește fiecare serviciu terț care primește date, inclusiv AI-ul. E regula mea, mai strictă decât textul Apple.
• Declarațiile de confidențialitate din fișă spun același lucru ca politica și ca privacy manifest-ul din build.
• Fiecare text de permisiune explică utilizarea într-o frază precisă.
• Nicio permisiune nu e cerută la pornire dacă aplicația poate funcționa fără. Aceeași logică pentru modurile de background: niciun mod declarat fără o funcție care să-l folosească.
• Un ecran propriu înaintea unei cereri are un singur buton, „Continue”, care deschide cererea sistemului.
• Cine refuză o permisiune poate continua altfel sau înțelege ce pierde.
• Ecranul „acces refuzat” apare doar după un refuz real. L-ai testat închizând și repornind aplicația.
• Aplicația se poate folosi fără cont când contul nu e indispensabil.
• Un cont creat în aplicație poate fi șters din aplicație: rețeta e în ștergerea contului iOS.
• Totul e testat și pe iPad: ambele refuzuri 5.1.1 pe Nolera au fost semnalate pe iPad.

Repară-ți refuzul cu cineva care l-a primit deja

Dacă aplicația ta tocmai a fost refuzată pe 5.1.1, Apple Review Kit te ajută să găsești regula citată, ce cere ea și un exemplu de corecție și de răspuns. Dacă vrei să ne uităm împreună la cazul tău chiar acum, rezervă o oră cu mine, pe video. Tot demersul e și pe pagina aplicație refuzată de Apple.

Dacă îți pregătești prima lansare, fă diagnosticul gratuit: îți pune pașii în ordine și îți trimite checklist-ul meu anti-refuz Apple, inclusiv partea de confidențialitate. Ca să îți creezi aplicația mobilă gândită pentru review încă de la început, parcursul în patru pași din iOS Kit merge de la idee până la trimiterea către Apple.

Nimeni nu poate garanta că Apple îți va accepta aplicația. Ce pot face eu e să te ajut să eviți refuzurile 5.1.1 pe care le-am plătit deja cu câte un ciclu de review.

Întrebări frecvente

Ce înseamnă „Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage”?

E titlul complet al regulii în mesajul Apple. Semnalează o problemă de date personale: politică de confidențialitate incompletă, cerere de permisiune considerată insistentă sau cont imposibil de șters. Alineatul dintre paranteze, de exemplu 5.1.1(iv), îți spune care.

E nevoie de un build nou după un refuz 5.1.1?

Nu întotdeauna. Dacă cauza e online, cum ar fi o politică de confidențialitate neactualizată, corectezi pagina, îi răspunzi lui Apple și submisia pleacă din nou fără build nou. Dacă cauza e un ecran sau un buton din aplicație, ai nevoie de un build nou.

Pot afișa un ecran explicativ înaintea unei cereri de permisiune?

Da, Apple permite asta când e cu adevărat util. Ecranul are atunci un singur buton, care deschide cererea sistemului, cu un termen ca „Continue” sau „Next”. Fără buton „Allow”, fără buton de închidere sau de sărire, cu excepția unui consimțământ cerut de lege.

Aplicația mea folosește un AI extern: ce trebuie să declar?

Guideline 5.1.2(i) cere să indici unde sunt partajate datele cu terți, inclusiv AI, și să obții înainte o permisiune explicită. Eu o aplic în trei locuri: un ecran de consimțământ în aplicație, politica de confidențialitate online și declarațiile de confidențialitate din fișă. La Clic, Apple a citat regula asta împreună cu 5.1.1.

Contul e obligatoriu ca să respecți 5.1.1?

Nu, e invers. Dacă aplicația ta nu are o funcție care să depindă cu adevărat de un cont, Apple cere să o lași utilizabilă fără autentificare. Iar dacă permite crearea unui cont, trebuie să permită și ștergerea lui din aplicație.