Guideline 4.2 Minimum Functionality: aplicație respinsă

Guideline 4.2, „Minimum Functionality”, respinge o aplicație care nu oferă nimic în plus față de un site web sau care oferă prea puțin ca s-o păstrezi. Soluția nu e să îngrămădești funcții native, ci să pui una în centrul utilizării și apoi să-i spui reviewerului unde s-o găsească. Corectura trece aproape întotdeauna printr-un build nou.

Îmi public propriile aplicații iOS: Solys, TradaZen și Nolera sunt pe App Store. Ghidul ăsta se bazează pe textul oficial al Apple, citit pe 15 octombrie 2026, și pe respingeri 4.2 publicate de dezvoltatori pe forumurile Apple. Aplicațiile respinse de mai jos sunt exemple. Pentru imaginea de ansamblu a tuturor motivelor, citește mai bine de ce respinge Apple o aplicație.

Ce spune guideline 4.2?

4.2 se află în secțiunea 4, „Design”, din App Review Guidelines. Prima frază stabilește criteriul: „Your app should include features, content, and UI that elevate it beyond a repackaged website.” Altfel spus, aplicația ta trebuie să ofere funcții, conținut și o interfață care o ridică deasupra unui site web pus într-o cutie.

Textul adaugă două idei. O aplicație care nu e cu adevărat utilă, unică sau „app-like” nu-și are locul pe App Store. Și o aplicație care nu oferă nici divertisment durabil, nici utilitate suficientă poate fi respinsă. Deci 4.2 judecă două lucruri: diferența față de web și cantitatea de valoare.

Subregulile pe care le poate cita mesajul

Subregulă	Ce cere Apple	Respingerea tipică
4.2	Să treci dincolo de un site web	Site afișat într-un WebView
4.2.1	O experiență reală de realitate augmentată	Un model 3D pus în vizualizarea AR
4.2.2	Nu doar marketing sau linkuri	Aplicație vitrină, agregator, linkuri
4.2.3	O aplicație autonomă, descărcări clare	Aplicație care cere o altă aplicație
4.2.6	Nu aplicații făcute dintr-un șablon comercial	Șablon trimis de un furnizor de servicii

Trei precizări. 4.2.2 face o excepție pentru cataloage: „Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” Deci un catalog de produse poate trece. O broșură publicitară, nu.

4.2.3 are două alineate. (i) cere ca aplicația să funcționeze singură, fără să instalezi o altă aplicație. (ii) cere, dacă aplicația trebuie să descarce resurse la prima lansare, să anunți dimensiunea descărcării și să ceri acordul înainte.

4.2.6, despre șabloanele comerciale și serviciile de generare de aplicații, e detaliată în ghidul guideline 4.3, pentru că merge mână în mână cu regula anti-spam.

Cele mai frecvente două mesaje 4.2

Mesajul Apple începe cu titlul „Guideline 4.2 - Design - Minimum Functionality”. Restul spune care dintre cele două probleme a văzut reviewerul. Iată două formulări publicate de dezvoltatori pe forumurile Apple. Au câțiva ani: textul exact se poate fi schimbat, cele două familii nu.

Aplicația seamănă cu un site. „Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.” Mesajul ăsta, publicat pe forumurile Apple, conține o frază decisivă: „Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store.”

Aplicația e prea subțire. „We found that the usefulness of your app is limited by the minimal amount of content or features it includes.” Acest al doilea mesaj cere să regândești conceptul și recunoaște că nicio regulă cu cifre nu definește ce e util sau distractiv.

Să adaugi notificări, localizare și un buton de partajare unui site împachetat nu e suficient: Apple a scris-o în propriile respingeri.

Patru cazuri tipice de respingere 4.2

Cele patru cazuri de mai jos sunt exemple construite ca să ilustreze regula, nu aplicații reale.

Site-ul web împachetat

Exemplu: o sală de sport își afișează site-ul mobil într-un WebView, cu o bară de taburi nativă deasupra. Programul, rezervarea și contul sunt pagini web. Reviewerul găsește acolo ce i-ar arăta Safari. Apple o spune pe pagina App Review: un site servit într-o aplicație iOS, un conținut web neadaptat la iOS sau interacțiuni web limitate nu fac o aplicație de calitate.

Ce aș face eu: aș reconstrui nativ ecranele acțiunii principale, aici programul și rezervarea. Apoi aș adăuga ce site-ul nu știe să facă: un memento înainte de antrenament, programul consultabil fără rețea, următorul antrenament într-un widget.

Aplicația prea simplă

Exemplu: o aplicație care afișează un citat pe zi și nimic altceva. O termini în zece secunde. 4.2 vorbește de „lasting entertainment value or adequate utility”: o valoare care durează sau o utilitate suficientă. Ca să corectezi, adaugă profunzime acțiunii principale, nu ecrane în jurul ei. Aici: un istoric, favorite, un memento la ora aleasă, un widget pe ecranul principal.

Aplicația generată cu AI, fără nimic nativ

Exemplu: un câmp de text, un buton, un răspuns AI afișat ca text simplu. Apple nu judecă unealta, ci ce ajunge pe ecranul reviewerului. Dacă experiența încape într-o pagină web, 4.2 are șanse mari să cadă.

Detaliez ce face bine AI-ul și ce ratează în cum creezi o aplicație cu AI. Formatul produs de fiecare generator, aplicație web sau proiect mobil, e comparat în Lovable, Rork sau FlutterFlow.

Cochilia care așteaptă conținut

Exemplu: un marketplace fără anunțuri, un director gol, un feed care afișează „În curând”. Reviewerul deschide o aplicație care n-are nimic de arătat. Cazul ăsta atinge și 2.1, care respinge conținutul provizoriu: vezi ghidul guideline 2.1. Trimite aplicația când are conținut real sau oferă un cont demo deja completat.

Testul pe care îl fac: „Și în Safari?”

Înainte să trimit, mă întreb dacă un site web ar putea oferi aceeași funcție principală. Dacă da, aplicația e expusă la 4.2. Iată grila mea pentru a judeca o funcție nativă. O funcție contează când servește acțiunea principală, nu când decorează.

Funcție	Contează când...	Nu e suficientă când...
Notificări	Aduc o informație așteptată	Îți redistribuie articolele
Offline	Conținutul principal rămâne utilizabil	Apare doar un ecran de eroare
Widget	Arată o dată proprie persoanei	Îți afișează logoul
Partajare	Se trimite conținut către aplicația ta	Partajează doar un link
Cameră, senzori	Fac parte din acțiunea principală	Îți deschid site-ul
Date locale	Aplicația calculează, organizează, reține	Totul trăiește pe o pagină web

Recomandările Apple merg în aceeași direcție. Un widget afișează un conținut actual, lizibil dintr-o privire. O notificare aduce o informație utilă, în puține cuvinte, și nu servește la a împinge spre o sarcină în aplicație.

Ce fac aplicațiile mele și un site nu face

Concep fiecare aplicație în jurul unei funcții principale care nu există într-un browser sau al unei valori care te face să revii.

• Solys e un ceas deșteptător. Alarma trece prin AlarmKit, serviciul de alarmă din iOS 26: sună și în modul silențios, ca deșteptătorul Apple. Ca s-o oprești, trebuie să câștigi un mini-joc, iar aplicațiile alese rămân în pauză după trezire. Nicio pagină web nu face un iPhone să sune pe silențios.
• TradaZen e un simulator de trading: un grafic real la o dată reală, o decizie, lumânări care se dezvăluie, dueluri clasate și un rang care crește. Aici nu o funcție nativă duce aplicația. E valoarea de divertisment durabil despre care vorbește 4.2.
• Nolera e o garderobă: îți fotografiezi hainele, aplicația le decupează și le organizează, apoi îți propune o ținută în fiecare dimineață. Camera face parte din acțiunea principală. Nu e un bonus.

4.2 nu cere o listă de funcții native: cere un motiv să instalezi aplicația în loc să deschizi un site.

Cum corectezi o respingere 4.2, pas cu pas

1. Identifică familia. Navigare web: e site-ul împachetat. Conținut sau funcții minime: e aplicația prea subțire. 4.2.3: o dependență de altă aplicație sau o descărcare neanunțată.
2. Schimbă produsul, nu formularea. Un răspuns care argumentează fără să schimbe nimic n-are niciun motiv să convingă. Reconstruiește nativ ecranele acțiunii principale sau adaugă profunzimea care lipsește.
3. Pregătește un build nou. Cauza e în aplicație: un update la distanță nu ajunge. Fiecare trimitere trece din nou prin coadă, vezi timpul de aprobare App Store.
4. Scrie note de review care ghidează. Apple cere, pe pagina despre informațiile pentru un review complet, să descrii conceptul, funcțiile și publicul. Pentru un update: ce s-a schimbat și unde găsești.
5. Fă apel doar dacă reviewerul a ratat ceva. Dacă funcția ta nativă exista deja dar n-a fost văzută, răspunde în App Store Connect cu un video scurt. Apelul la App Review Board se justifică atunci când aplicația ta a fost înțeleasă greșit, nu când e subțire.

Modelul de note pe care l-aș folosi, în engleză, de adaptat:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Scrie doar ce există în build-ul trimis. O funcție anunțată și negăsită ți-ar aduce o nouă respingere, de data asta pe 2.1.

Checklistul 4.2 înainte de trimitere

• Poți spune într-o frază ce face aplicația ta și un site nu face.
• Ecranele acțiunii principale sunt native, nu pagini web.
• Fiecare funcție nativă servește acțiunea principală, iar reviewerul o întâlnește în mai puțin de două minute.
• Aplicația are conținut real de la prima lansare sau un cont demo completat.
• Aplicația funcționează singură, fără altă aplicație de instalat.
• O descărcare mare la prima lansare își anunță dimensiunea și cere acordul.
• Notele de review descriu conceptul, publicul și locul fiecărei funcții.
• Dacă ideea ta e la limită, ai testat-o înainte să scrii cod, cu un MVP de aplicație iOS bine definit.

Treci de 4.2 de la următoarea trimitere

Dacă aplicația ta tocmai a fost respinsă pe 4.2, Apple Review Kit te ajută să găsești regula citată și ce cere ea, cu modele de note pentru tester. Dacă încă construiești, parcursul din iOS Kit pornește de la funcția principală înainte de prima linie de cod. Pentru o privire umană, rezervă o oră cu mine. Demersul complet e pe pagina aplicație respinsă de Apple.

Dacă îți pregătești prima lansare, fă diagnosticul gratuit: pune pașii în ordine și îți trimite checklistul meu anti-respingere Apple. Pagina principală arată cum să creezi o aplicație mobilă gândită pentru review de la început.

Nimeni nu poate garanta că Apple îți va accepta aplicația. Eu te pot ajuta să-i dai un motiv să existe pe App Store.

Întrebări frecvente

Ce înseamnă „Guideline 4.2 - Design - Minimum Functionality”?

E titlul respingerii pentru funcționalitate minimă. Apple consideră că aplicația ta seamănă prea mult cu un site web sau că oferă prea puțin conținut ori prea puține funcții. Același titlu poate viza o subregulă: „Guideline 4.2.2” pentru o aplicație vitrină sau o listă de linkuri, 4.2.3 pentru o aplicație care depinde de altă aplicație.

O aplicație în WebView e respinsă întotdeauna?

Nu. Regula vizează site-ul web pus într-o aplicație, nu tehnologia. Reviewerul judecă experiența principală: dacă ecranele ei sunt pagini web care fac același lucru ca Safari, riscul e mare. O pagină de ajutor deschisă în browser nu e problema.

E suficient să adaugi notificări push ca să treci de 4.2?

Nu. Într-un mesaj de respingere publicat pe forumurile sale, Apple scrie că notificările, localizarea și partajarea nu sunt suficiente ca să facă experiența destul de bogată. O notificare contează când servește funcția principală, cum ar fi o alarmă sau un memento ales de persoană.

Care e diferența dintre guideline 4.2 și 4.3?

4.2 îți judecă aplicația singură: aduce destul față de un site web? 4.3 o compară cu celelalte: e o copie, o variantă sau încă o aplicație într-o categorie saturată? Aceeași aplicație le poate primi pe amândouă, dar nu se corectează la fel.

E nevoie de un build nou după o respingere 4.2?

Aproape întotdeauna, pentru că cauza e în aplicația însăși. Singura excepție: reviewerul n-a găsit o funcție care exista deja. În cazul ăsta, răspunde în App Store Connect cu note precise și un video scurt, fără să schimbi build-ul.