Guideline 4.0 Design: aplicație respinsă pentru interfață
De Mehdi Azizi
Publicat pe , 9 min.
Guideline 4.0 Design: Apple respinge o interfață greu de folosit, des pe iPad. Testează fiecare ecran pe iPhone SE și iPad, corectează, apoi răspunde.
„Guideline 4.0 - Design” nu e o regulă numerotată ca celelalte: e introducerea secțiunii Design din regulile Apple, citată când interfața ta pare sub nivelul așteptat. Respingerile publicate seamănă între ele: ecrane înghesuite pe iPad, text greu de citit, autentificare trimisă în Safari, Sign in with Apple integrat prost. Corectura începe aproape mereu pe dispozitivul pe care îl citează mesajul, ecran cu ecran.
Îmi public propriile aplicații iOS cu Expo: Solys, TradaZen și Nolera sunt setate doar pentru iPhone, și totuși reviewerul a testat Solys și Nolera pe iPad. Ghidul ăsta se bazează pe textul Apple, pe respingeri 4.0 publicate de alți developeri și pe grila vizuală pe care o aplic înainte de fiecare trimitere. Pentru imaginea de ansamblu a motivelor, citește de ce respinge Apple o aplicație.
Ce acoperă guideline-ul 4.0 Design?
Secțiunea 4 din App Review Guidelines se deschide cu un paragraf fără număr: „Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store.” Adaugă că designul îți aparține, dar că restul stabilește niște „minimum standards for approval”. Avertizează și că o aplicație care se degradează după aprobare poate fi retrasă.
Pe scurt: Apple așteaptă o aplicație simplă, îngrijită și ușor de folosit, iar 4.0 se folosește când problema nu ține de nicio subregulă precisă. Textul nu dă criterii cifrate. Referința practică sunt Human Interface Guidelines, regulile de design ale Apple.
Cele mai frecvente respingeri 4.0
Iată cele patru cazuri pe care le-am găsit în mesaje publicate pe forumurile Apple, cu formularea citată.
| Caz | Formularea Apple | Corectură |
|---|---|---|
| Ecrane înghesuite pe iPad | „crowded” | Layout fluid |
| Text greu de citit | „hard to read type” | Dimensiuni HIG |
| Autentificare în Safari | „taken to Safari” | Autentificare în aplicație |
| Sign in with Apple | Nume cerut din nou | Nume deja furnizat |
Ecrane înghesuite sau tăiate pe iPad
Mesajul tipic, publicat în septembrie 2025: „Parts of the app's user interface were still crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air (5th generation) running iPadOS 26.0.” Continuarea preciza că aplicația folosea doar o parte din ecran (thread pe forum).
Cauza ține de regula 2.4.1: „iPhone apps should run on iPad whenever possible.” Cu Expo, opțiunea ios.supportsTablet are implicit valoarea false, conform configurației de aplicație Expo. Aplicația ta de iPhone rulează atunci pe iPad în modul de compatibilitate, într-o fereastră în format iPhone. Să setezi aplicația doar pentru iPhone nu o ferește de un test pe iPad. Pe un iPad Air a devenit imposibil de câștigat demo-ul din Solys, un caz detaliat în ghidul despre guideline 2.1.
Două ieșiri. Fie suporți cu adevărat iPad-ul, cu un layout care urmează spațiul disponibil. Regulile de design Apple cer să decizi aranjarea după size classes, nu după modelul de dispozitiv. Fie rămâi pe iPhone, iar fiecare ecran trebuie să încapă în fereastra de compatibilitate.
Text greu de citit
Mesajul, publicat în ianuarie 2025: „Your app included hard to read type or typography.” Apple amintește acolo că utilizatorii așteaptă aplicații „simple, refined, and easy to use” (thread pe forum).
Regulile de tipografie Apple dau repere pe iOS: 17 puncte implicit, minimum 11 puncte. Regulile de accesibilitate cer un contrast de cel puțin 4,5 la 1 pentru text de până la 17 puncte și zone de atingere de 44 pe 44 de puncte implicit.
O capcană dacă micșorezi fonturile pe ecranele mici, cum fac eu ca să păstrez aceleași rupturi de rând peste tot: verifică dacă cel mai mic text al tău, micșorat pe iPhone SE, rămâne la cel puțin 11 puncte.
Autentificare trimisă în Safari
Mesajul, publicat pe forumul Apple: „We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience.” Apple cere să permiți înregistrarea și autentificarea în aplicație și recomandă o vizualizare Safari integrată.
Cu Expo, expo-web-browser acoperă ambele nevoi fără să ieși din aplicație: openAuthSessionAsync deschide o sesiune de autentificare într-o fereastră modală, iar openBrowserAsync afișează o pagină într-o vizualizare Safari integrată. Dacă deschizi autentificarea cu Linking.openURL, în schimb, utilizatorul ajunge în aplicația Safari. Alegerea metodelor de autentificare oferite ține de altă regulă, 4.8.
Sign in with Apple integrat prost
Mesajul, publicat în mai 2024: „Your app requires users to provide their name after using Sign in with Apple. This information is already provided by the Authentication Services framework.” (thread pe forum).
Documentația expo-apple-authentication explică capcana: numele și e-mailul sunt furnizate doar la prima autentificare. Salvează-le imediat, altfel vei fi tentat să le ceri din nou. Folosește și butonul oferit de bibliotecă: culoarea se alege cu buttonStyle, iar colțurile cu cornerRadius, niciodată prin style.
4.0, 4.2, 4.3: trei respingeri de design de nu confundat
| Regulă | Ce se judecă | Corectură |
|---|---|---|
| 4.0 | Interfața | Corectezi ecranele |
| 4.2 | Utilitatea aplicației | Adaugi conținut nativ |
| 4.3 | Asemănarea | Schimbi conceptul |
4.2, Minimum Functionality, cere funcții, conținut și o interfață care ridică aplicația „beyond a repackaged website”. Granița cu 4.0 e subțire: un site împachetat într-o aplicație le poate lua pe amândouă. Dacă aplicației tale îi lipsește substanța, retușarea ecranelor nu va fi de ajuns.
4.3 vizează copiile și categoriile saturate: am detaliat cele două alineate în ghidul despre guideline 4.3 Design Spam. O interfață îngrijită nu salvează o aplicație care seamănă cu alte o mie.
Grila vizuală înainte de trimitere
E elementul pe care îl adaug la fiecare trimitere. În aplicațiile mele, fiecare ecran e desenat pentru cel mai mare iPhone, apoi micșorat cu o singură scară pe cele mai mici: aceleași proporții, aceleași rupturi de rând. Apoi compar randările una lângă alta: iPhone SE, iPhone standard, cel mai mare iPhone și un iPad pentru modul de compatibilitate.
| Verificare | Dispozitiv | Ce trebuie să reziste |
|---|---|---|
| Prima lansare | iPhone SE | Nimic tăiat |
| Onboarding complet | iPad | Fiecare buton accesibil |
| Tastatură deschisă | iPhone SE | Câmp și buton vizibile |
| Text mărit | iPhone standard | Niciun text trunchiat |
| Mod întunecat | Toate | Text lizibil peste tot |
| Zone sigure | Cel mai mare | Nimic sub Dynamic Island |
| Paywall | iPhone SE | Prețuri și linkuri vizibile |
| Autentificare | iPad | Rămâne în aplicație |
Trei precizări:
- Text mărit. Regulile de tipografie Apple propun un test simplu: activezi cele mai mari dimensiuni de text din Settings, Accessibility, Display & Text Size, apoi verifici că totul rămâne lizibil.
- Mod întunecat. Regulile Apple despre Dark Mode cer ca aplicația să rămână lizibilă în ambele aspecte. Expo aplică implicit
lightdacă nu seteziuserInterfaceStyle. Solys urmează setarea telefonului, TradaZen rămâne pe întunecat, Nolera pe luminos: în toate trei cazurile, testez aspectul afișat. - Zone sigure. Conținutul nu trece nici sub Dynamic Island, nici sub indicatorul Home. Expo detaliază metoda în ghidul său despre zonele sigure.
Pe Mac, simulatorul se configurează din linia de comandă, ceea ce face grila rapid de reluat:
xcrun simctl ui booted appearance dark
xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
xcrun simctl io booted screenshot ecran-se-sombre.png
Pe un telefon real, refac același tur cu un build TestFlight. Metodologie: grila asta e a mea, construită pe respingerile primite de aplicațiile mele, nu o listă furnizată de Apple. Reduce surprizele, dar nu garantează acceptarea.
Cum răspunzi la o respingere 4.0?
- Identifică dispozitivul și versiunea citate în mesaj, apoi deschide același model în simulator.
- Corectează toate aparițiile. Mesajul tipic cere să „address all instances” ale problemei, nu doar ecranul din captură.
- Trimite un build nou: reviewerul testează codul inclus în aplicație.
- Răspunde cu capturi făcute pe același dispozitiv, răspunzând la mesajul App Review.
- Fă apel doar dacă ești sigur: Apple îți permite să sesizezi App Review Board, cu un singur apel per trimitere respinsă.
Modelul pe care l-aș folosi, de adaptat:
Hello,
Thank you for your feedback regarding Guideline 4.0.
We reproduced the issue on [device] running [OS version].
Changes in build [X]:
- [Screen]: [what was crowded or hard to read], now [fix].
- [Screen]: [fix].
We also checked every screen on iPhone SE, a standard
iPhone, the largest iPhone and iPad, with larger text
sizes and Dark Mode.
Attached: screenshots of the updated screens on [device].
Best regards,
Pregătește-ți trimiterea fără respingeri de design
Review Kit adună checklistul meu dinainte de trimitere, care acoperă printre altele regula 2.4.1 despre iPad, și skills Claude Code care îți recitesc proiectul. Pentru o privire umană, rezervă o oră cu mine: îți deschidem ecranele pe mai multe dimensiuni, pe video. Demersul complet după o respingere e pe pagina aplicație respinsă de Apple.
Îți pregătești prima lansare? Fă-ți diagnosticul gratuit: pune pașii în ordine și îți trimite checklistul meu anti-respingere Apple.
Întrebări frecvente
Ce înseamnă „Guideline 4.0 - Design” într-un mesaj de respingere?
Apple consideră că interfața ta e sub nivelul așteptat, fără să vizeze o subregulă precisă: ecrane înghesuite, text greu de citit, flux de autentificare considerat prost. Mesajul citează de obicei dispozitivul folosit și atașează des o captură.
Aplicația mea e setată doar pentru iPhone: de ce o testează Apple pe iPad?
Pentru că regula 2.4.1 cere ca aplicațiile de iPhone să ruleze pe iPad ori de câte ori e posibil. Aplicația ta se deschide acolo în modul de compatibilitate, într-o fereastră în format iPhone, și fiecare ecran trebuie să rămână utilizabil.
Am nevoie de un build nou după o respingere 4.0?
Da, în majoritatea cazurilor. Reviewerul testează codul inclus în aplicație la prima lansare, iar o corectură livrată de la distanță îi poate scăpa. Explic asta în ghidul despre guideline 2.1.
E obligatoriu modul întunecat ca să fii acceptat?
Textul regulilor de review nu îl impune. Regulile de design amintesc că utilizatorii se așteaptă ca aplicațiile să le urmeze setarea. Dacă forțezi modul luminos sau întunecat, cum permite Expo, testează aspectul ăla. Dacă urmezi setarea telefonului, testează-le pe amândouă.
Poți face apel la o respingere 4.0?
Da, la App Review Board, dacă crezi că aplicația ta respectă regulile. Apple cere motive precise, un singur apel per trimitere respinsă și să răspunzi mai întâi la cererile de informații.

