Review accelerat App Store: cum îl ceri de la Apple
De Mehdi Azizi
Publicat pe , 9 min.
Apple dă două cazuri: un bug critic pe versiunea publicată sau o lansare legată de un eveniment. Procedura, ce să scrii și ce urmează.
Review-ul accelerat există, dar Apple îl păstrează pentru circumstanțe excepționale și dă două exemple: repararea unui bug critic pe o versiune deja publicată sau lansarea unei versiuni sincronizate cu un eveniment de care aplicația ta e direct legată. Mai întâi trimiți versiunea, explici urgența în Notes pentru reviewer, apoi trimiți formularul de cerere. Apple analizează fiecare cerere și accelerează în funcție de disponibilitate: nu e niciodată o garanție.
Aplicațiile mele, Solys, TradaZen și Nolera, sunt făcute cu Expo. Când un bug vine din codul JavaScript, fix-ul pleacă printr-un update la distanță, fără să treacă prin App Review. Așa că review-ul accelerat îmi folosește doar pentru un build nativ, și asta e și prima întrebare pe care să ți-o pui înainte să-l ceri. Ghidul ăsta urmează pagina de ajutor Apple despre review-ul accelerat, recitită pe 6 noiembrie 2026.
Ce dă Apple ca exemplu și ce nu trece
Apple vorbește de circumstanțe excepționale și cere să păstrezi cererile pentru urgențe reale. Pagina App Review dă două exemple și ce trebuie furnizat pentru fiecare. Cele trei rânduri refuzate din tabel sunt interpretarea mea a acestor pagini, nu o listă Apple.
| Motiv | La Apple | Ce trebuie furnizat sau înțeles |
|---|---|---|
| Bug critic pe versiunea publicată | Dat ca exemplu | Pașii de reproducere, versiunea actuală |
| Lansare legată de un eveniment | Dat ca exemplu | Evenimentul, data lui, legătura dintre aplicație și el |
| Prima publicare întârziată | Nu, după părerea mea | Nimic n-o face urgentă în ochii Apple |
| Dată de marketing fără eveniment | Nu, după părerea mea | O campanie nu e un eveniment legat de aplicație |
| Așteptare mai lungă decât de obicei | Nu, după părerea mea | Un termen normal nu e o urgență |
Apple nu definește termenul. În practică, un bug critic e o aplicație care crapă, care blochează o funcție esențială sau care împiedică plata, la utilizatori reali, pe versiunea publicată. O greșeală de tipar pe un ecran nu e. Iar dacă aplicația ta e încă în review când se apropie un eveniment, Apple precizează că poți cere accelerarea și din motivul ăsta.
Procedura în trei pași
- Trimite versiunea în App Store Connect. Doar o versiune deja trimisă poate fi accelerată. Dacă unele funcții cer autentificare, completează un cont demo în secțiunea App Review Information.
- Completează câmpul Notes când trimiți. Pentru un bug critic, descrie bug-ul reparat și cum se reproduce pe versiunea actuală. Pentru un eveniment, dă numele lui, data și ce leagă aplicația ta de el.
- Trimite formularul Request an Expedited App Review, accesibil din pagina de ajutor Apple după ce te conectezi la contul de developer. Acolo alegi aplicația și platforma, apoi trimiți.
Apple analizează cererea și îți răspunde, iar tu urmărești versiunea în App Store Connect. Dacă cererea e acceptată, versiunea trece în In Review mai devreme decât ar fi ajuns prin coadă. Dacă e refuzată, review-ul își urmează cursul normal: nu pierzi nimic.
Butonul Reply to App Review din App Store Connect nu servește la cererea unui review accelerat. Pagina de contact App Review îl rezervă pentru schimburile despre o versiune aflată în review; cererea accelerată și apelul au fiecare formularul lor.
Ce să scrii: două modele
App Review citește în engleză. Iată cele două texte pe care le țin pregătite, de adaptat în Notes și în formular, dacă îți lasă un câmp liber. Au cinci rânduri pentru că un reviewer trebuie să înțeleagă urgența fără să deschidă aplicația.
Bug critic pe versiunea publicată:
Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.
Lansare legată de un eveniment:
This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.
Cele două texte sunt exemple, nu cereri pe care le-am trimis. Două reguli pentru ale tale. Fapte verificabile: versiune, sistem, pași, dată, legătura cu evenimentul. Nimic în afară de urgență: dacă build-ul tău conține și o funcție nouă, spune-o într-o frază, dar n-o apăra.
Înainte să ceri, verifică dacă ai nevoie
Apple cere să-l păstrezi pentru urgențe reale. Trei întrebări, și o capcană, înainte să trimiți formularul.
Trece fix-ul fără review? Cu Expo, un update la distanță înlocuiește codul JavaScript al aplicațiilor deja instalate fără build nou. E calea pe care o folosesc pentru fix-urile mele. Nu acoperă nici codul nativ, nici permisiunile, nici dependențele native: pentru ele ai nevoie de un build și de un review. Iar conținutul lui trebuie să rămână în cadrul a ce a validat Apple, cum amintește prezentarea EAS Update: un update la distanță nu schimbă scopul aplicației. Ghidul despre lansarea progresivă a unui update iOS detaliază ce trece pe unde.
E așteptarea anormală? Apple spune că analizează în general cel puțin 50% din versiunile trimise în mai puțin de 24 de ore și 90% în mai puțin de 48 de ore. Dacă versiunea ta e în așteptarea review-ului de o zi, ești în limitele normale ale termenului de validare App Store. Pagina de urmărire a unei versiuni trimise amintește și ce lungește un review: prima aplicație fără istoric, documente de verificat, domeniu reglementat.
E versiunea trimisă completă? Un review accelerat pe o versiune incompletă nu accelerează nimic. Apple avertizează că o versiune incompletă întârzie review-ul sau eșuează. Cont demo, note, documente: totul trebuie să fie acolo înainte de formular.
Și mai ales, nu-ți retrage versiunea ca s-o retrimiți. O versiune retrasă iese din coadă și o ia de la zero. Dacă Apple îți pune o întrebare în timpul review-ului, răspunde în App Store Connect în loc să retrimiți, cum explică ghidul despre cum îi răspunzi lui App Review în Resolution Center.
Dacă Apple refuză accelerarea
Îți păstrezi locul în coadă: un refuz de accelerare nu schimbă nimic la review-ul în curs. Ca să nu mai treci prin asta:
- Programează-ți lansările. Pentru un eveniment, Apple recomandă publicarea programată în App Store Connect: versiunea e analizată din timp și iese la data dorită. Opțiunea de publicare a unei versiuni se setează pe pagina versiunii, în secțiunea App Store Version Release.
- Trimite devreme. O versiune gata cu o săptămână înainte de eveniment lasă timp pentru un review normal, ba chiar și pentru un refuz corectat.
- Păstrează un canal fără review pentru JavaScript. Cu Expo, asta transformă un bug critic într-un fix de câteva minute.
Modelele mele de note pentru reviewer, checklist-ul meu dinainte de trimitere și răspunsurile la cele mai frecvente refuzuri sunt adunate în Review Kit. Și dacă vrei să afli ce lipsește din versiunea ta înainte s-o trimiți, diagnosticul gratuit îți spune și îți trimite checklist-ul meu anti-refuz Apple. Toți pașii publicării sunt în cum publici o aplicație pe App Store.
Întrebări frecvente
Cât durează un review accelerat App Store?
Apple nu dă niciun termen. Spune că analizează fiecare cerere și accelerează review-ul în funcție de disponibilitate și de volumul de cereri din acel moment. O cerere acceptată trece versiunea în In Review înainte de rândul ei, fără promisiune de oră.
Poți cere un review accelerat pentru prima aplicație?
Nimic nu interzice, dar Apple păstrează accelerarea pentru urgențe reale și dă două exemple: un bug critic pe o versiune deja publicată sau o lansare legată de un eveniment cu dată fixă. O primă publicare întârziată față de planul tău nu intră, după părerea mea, în niciunul dintre ele.
De câte ori poți cere un review accelerat?
Apple nu publică un număr. Cere să păstrezi cererile pentru urgențe reale. După părerea mea, fiecare cerere fără motiv real o face pe următoarea mai puțin credibilă: păstreaz-o pentru un bug care îți afectează utilizatorii.
Trebuie să retragi versiunea înainte să ceri accelerarea?
Nu, dimpotrivă. Doar o versiune deja trimisă poate fi accelerată, iar o versiune retrasă își pierde locul în coadă. Trimite, completează Notes, apoi trimite formularul.
Unde găsești formularul de review accelerat?
Pe site-ul Apple pentru developeri, după ce te conectezi la cont: pagina de ajutor despre review-ul accelerat duce acolo prin linkul Request an Expedited App Review. Acolo alegi aplicația și platforma.
Garantează un review accelerat că aplicația va fi acceptată?
Nu. Schimbă doar poziția în coadă. Versiunea trebuie să respecte App Review Guidelines ca oricare alta, iar un refuz rămâne posibil.
Poți repara un bug fără să treci prin App Review?
Cu Expo sau React Native, un update la distanță înlocuiește codul JavaScript fără build nou și fără review. Codul nativ, permisiunile și dependențele native cer în continuare un build trimis la Apple.

