Cum publici o actualizare iOS: lansare treptată
De Mehdi Azizi
Publicat pe , 10 min.
Cum publici o actualizare iOS: versiune nouă, build nou, textul de noutăți, apoi lansare manuală, automată sau treptată pe 7 zile.
Ca să publici o actualizare iOS, creezi o versiune nouă în App Store Connect, cu un număr mai mare. Îi atașezi un build nou, scrii textul „Noutăți”, apoi o trimiți la App Review. Fiecare versiune nouă trece din nou prin review-ul Apple, chiar și pentru o simplă corectură. Înainte de trimitere, alegi cum va ieși după aprobare: manual, imediat, nu înainte de o anumită dată sau prin lansare treptată pe 7 zile.
Lansarea treptată afectează doar actualizările automate: 1% dintre acești utilizatori în prima zi, toți în a șaptea. Poți s-o pui pe pauză până la 30 de zile în total sau s-o termini dintr-odată. Ghidul ăsta urmează paginile de ajutor Apple, recitite pe 3 noiembrie 2026.
Eu public actualizările aplicațiilor mele iOS cu Expo și EAS, printre ele Solys, TradaZen și Nolera. Cazurile de mai jos vin din aceste lansări.
Cum publici o actualizare iOS: pașii în ordine
Ajutorul App Store Connect despre versiunile noi dă acest parcurs:
- În Apps, alege aplicația, apoi apasă butonul + de lângă platformă.
- Introdu un număr de versiune mai mare decât cel anterior, apoi apasă Create.
- Recitește metadatele: cele ale versiunii live sunt copiate automat.
- Trimite un build nou, cu numărul de build incrementat.
- Testează build-ul în TestFlight, adaugă-l la versiune, apoi trimite-o la App Review.
Două condiții înainte să începi. Versiunea live trebuie să aibă statusul Ready for Distribution. Și ai nevoie de unul dintre aceste roluri: Account Holder, Admin, App Manager sau Marketing.
Nu există cale de întoarcere. Apple scrie asta pe aceeași pagină: dacă o versiune are probleme, nu poți reveni la cea anterioară. Trebuie să creezi și să trimiți o versiune nouă.
Numărul de versiune și numărul de build
Versiunea e numărul pe care clienții tăi îl văd pe pagina aplicației. Build-ul identifică fiecare trimitere. Perechea versiune și build trebuie să fie unică: regulile și erorile asociate sunt în versiune și număr de build.
Convenția mea, care nu e o regulă Apple: ultima cifră crește pentru o corectură, de la 1.4.0 la 1.4.1. Cea din mijloc crește pentru o funcție nouă, de la 1.4.1 la 1.5.0. Numărul de build doar crește, de la o versiune la alta. Cu Expo, versiunea stă în app.json, iar EAS poate incrementa build-ul la fiecare compilare de producție. Configurarea e în publicarea unei aplicații Expo cu EAS.
Textul „Noutăți”: ce cere Apple
Pagina cu informațiile versiunii descrie câmpul What's New in This Version:
- Maximum 4.000 de caractere.
- Lipsește la prima versiune, obligatoriu pentru toate următoarele.
- Se poate traduce în fiecare limbă a paginii tale.
Regula 2.3.12 din App Review Guidelines adaugă o cerință: să descrii clar funcțiile noi și schimbările produsului. O formulare generală e suficientă pentru simple corecturi de bug-uri, de securitate sau de performanță. O schimbare importantă trebuie listată. „Corecturi de bug-uri și îmbunătățiri” nu ajunge deci pentru o versiune care îți schimbă abonamentul sau ecranul principal.
Apple mai recomandă, pe pagina dedicată recenziilor, să menționezi în note problemele corectate pe care clienții le descriseseră în recenzii.
Iată trei modele de adaptat, câte unul pentru fiecare tip de versiune.
Pentru o corectură:
Corecturi și stabilitate.
- [Funcție]: [ce nu mergea] a fost corectat.
- [Ecran] se încarcă mai repede.
Mulțumim celor care ne-au semnalat problema.
Pentru o funcție nouă:
Nou: [funcția, în cinci cuvinte].
[Ce poți face acum, într-o frază.]
Unde o găsești: [tab] > [buton].
Tot în această versiune:
- [Îmbunătățire vizibilă].
- Corecturi de bug-uri.
Pentru un parcurs care se schimbă:
[Ecranul sau parcursul] se schimbă.
- Ce se schimbă pentru tine: [efect concret].
- Ce păstrezi: [date, setări, achiziție].
Ai o întrebare? [Setări] > [Ajutor].
Ultimul rând din modelul de corectură se pune doar dacă cineva chiar a semnalat problema. Nu scrie niciodată o noutate care nu e în build: regula 2.3 cere metadate fidele aplicației.
Lansare manuală, automată sau la o dată
Ajutorul despre opțiunile de lansare propune trei:
| Opțiune | După aprobarea Apple |
|---|---|
| Manuală | Status Pending Developer Release, publici când vrei |
| Automată | Versiunea iese imediat după aprobare |
| Automată, nu înainte de... | Așteaptă data aleasă, apoi iese singură |
La lansarea manuală, deschizi versiunea cu statusul Pending Developer Release, apeși Release This Version, apoi confirmi. Apple avertizează că poate dura până la 24 de ore să apară în App Store. Un mesaj pe pagina versiunii îți oferă Cancel This Release ca s-o anulezi. Dacă versiunea stă în așteptare mai mult de 30 de zile, Apple îți trimite un e-mail de reamintire.
Lansarea manuală îți permite să alegi momentul, de exemplu ca să publici în ziua unui anunț. Solys 2.0.0, care venea cu o versiune nouă a abonamentului anual, a plecat la review la sfârșitul lui septembrie 2026 cu lansare manuală.
Pentru o versiune de rutină, las lansarea automată. Nolera 1.0.2, acceptată pe 12 octombrie 2026, a apărut în App Store la mai puțin de un minut după e-mailul Apple, conform API-ului public de căutare iTunes. E o singură observație: lasă-ți o marjă.
Lansarea treptată pe 7 zile
Ajutorul Apple despre lansarea treptată dă calendarul exact:
| Zi | Procent din utilizatori |
|---|---|
| 1 | 1% |
| 2 | 2% |
| 3 | 5% |
| 4 | 10% |
| 5 | 20% |
| 6 | 50% |
| 7 | 100% |
Actualizarea pleacă spre un eșantion aleatoriu dintre utilizatorii care au activat actualizările automate, pe dispozitivele compatibile. Ei nu sunt anunțați că fac parte din el.
Lansarea treptată frânează doar actualizările automate. Apple precizează că oricine poate descărca noua versiune din App Store, oricând. Cineva care îți instalează aplicația sau apasă „Update” pe pagina ei o poate primi deci din prima zi. Nu e un test pe 1% din utilizatori: e o frână pentru ceilalți.
Ca s-o activezi, deschide versiunea, coboară la secțiunea Phased Release for Automatic Updates, bifează „Release update over a 7-day period using phased release”, apoi salvează. Ai nevoie de rolul Account Holder, Admin sau App Manager. Opțiunea rămâne disponibilă până la statusul Pending Developer Release: o poți activa și după aprobarea Apple, cât timp versiunea așteaptă lansarea ta manuală.
După ce versiunea e aprobată, statusul ei Ready for Distribution poartă mențiunea „Phased Release”. La finalul celor 7 zile, Admin și App Manager ai aplicației primesc o notificare.
Pauză, reluare și lansare pentru toți
- Pauză: până la 30 de zile în total, de câte ori vrei. O pauză de 10 zile lasă 20 de zile pentru următoarele.
- Reluare: lansarea pornește din nou din ziua în care ai oprit-o.
- Lansare pentru toți: butonul Release to All Users, în dreapta sus pe pagina versiunii, trimite actualizarea pe toate dispozitivele cu actualizări automate.
- Retragerea de la vânzare: oprește lansarea definitiv, inclusiv dacă îți expiră abonamentul la programul pentru dezvoltatori. Dacă aplicația revine la vânzare, versiunea devine disponibilă pentru toți dintr-odată.
După lansarea pentru toți, nu mai poți regla nimic, precizează tabelul proprietăților modificabile.
Nolera 1.0.2 a ieșit fără lansare treptată. Iată cum m-aș folosi de ea în cursul săptămânii:
| Ce vezi | Ce faci | Ce se întâmplă |
|---|---|---|
| Crash-uri sau recenzii îngrijorătoare | Pauză | Actualizările automate se opresc |
| Corectura e gata | Versiune nouă | Trece din nou la review, cu propria lansare |
| Nimic anormal după 3 sau 4 zile | Release to All Users | Toată lumea o primește |
| Aștepți un răspuns de la Apple | Pauză, 30 de zile în total | Reluare din ziua în care te-ai oprit |
În timpul unei pauze, descărcările manuale continuă. Bifează lansarea treptată pentru orice versiune care atinge plata sau prima lansare a aplicației: acolo un defect costă cel mai mult și nu vei putea da înapoi.
Când corectura e urgentă: review-ul accelerat
Apple îți permite să ceri un review accelerat. E rezervat urgențelor reale: un bug critic de corectat sau o lansare legată de un eveniment.
- Trimite mai întâi versiunea. Descrie bug-ul în câmpul Notes destinat reviewer-ului.
- Completează formularul de cerere de review accelerat, apoi alege aplicația și platforma.
- Apple accelerează review-ul în funcție de disponibilitate. Nimic nu e garantat.
Pentru un eveniment, indică în note data lui și legătura ta cu el. Termenele obișnuite sunt în durata de validare App Store.
Ce trece din nou la review și ce nu
| Schimbare | Ce îți trebuie |
|---|---|
| Cod nativ, permisiuni, versiunea SDK-ului | Build nou, versiune nouă, review complet |
| Capturi, descriere, cuvinte cheie, noutăți | O versiune nouă, verificate odată cu ea |
| Text promoțional | Nimic: se schimbă fără o nouă trimitere |
| Pauză, reluare, lansare pentru toți | Nimic: sunt setări de lansare |
| Antetul paginii iOS 27 | Separat în Asset Library sau cu o versiune |
| Corectură JavaScript, cu Expo | E posibilă o actualizare la distanță |
Textul promoțional se schimbă fără o nouă trimitere, conform paginii cu informațiile versiunii. Cu Expo, o actualizare la distanță schimbă JavaScript-ul, textele și imaginile fără să treacă prin App Store. Documentația Expo pune două limite: codul nativ, permisiunile și versiunea SDK-ului cer un binar nou, iar actualizările trebuie să respecte regulile App Store.
Cazul meu: o corectură la distanță pe care reviewer-ul n-a văzut-o niciodată
În septembrie 2026, un build Nolera aștepta review-ul. Corectasem un defect pe ecranul de scanare și publicasem corectura ca actualizare la distanță în timpul așteptării. Build-ul a fost totuși respins, pentru defectul deja corectat.
Explicația e în documentația expo-updates: implicit, aplicația descarcă actualizarea la pornire și o aplică la pornirea următoare. Reviewer-ul instalează aplicația, o pornește o dată și testează codul inclus în build. Aceeași regulă e valabilă pentru utilizatorii tăi noi: prima lor sesiune rulează pe codul din build.
De atunci, orice schimbare a ecranului de start, a paywall-ului sau a funcției principale pleacă într-un build nou. Actualizarea la distanță e doar pentru cei care au deja aplicația.
Resetarea ratingului odată cu o versiune
Fiecare versiune nouă oferă opțiunea Reset rating when this version is released. Conform ajutorului Apple despre resetare, se aplică în toate țările, păstrează recenziile scrise și nu se poate anula după lansare. Apple recomandă s-o folosești cu măsură, pentru că o pagină cu puține ratinguri poate descuraja.
Checklist-ul înainte să trimiți actualizarea
- Numărul de versiune e mai mare, build-ul e incrementat.
- Build-ul e testat în TestFlight, pe un iPhone mic și pe iPad dacă aplicația rulează acolo.
- Noutățile sunt scrise în fiecare limbă, iar schimbările importante sunt listate.
- Capturile arată interfața actuală, dacă s-a schimbat.
- Notele pentru reviewer spun ce s-a schimbat și unde găsește.
- Opțiunea de lansare e aleasă: manuală dacă trebuie să respecți o dată.
- Lansarea treptată e bifată dacă versiunea atinge plata sau prima lansare a aplicației.
- Știi dacă o eventuală corectură poate pleca la distanță sau dacă va cere un build.
Cum treci de review la fiecare actualizare
Fiecare actualizare trece din nou prin App Review, iar o respingere îți blochează corectura. Review Kit adună checklist-ul meu dinainte de trimitere, respingerile mele corectate și două skill-uri Claude Code care îți verifică proiectul și pagina din App Store, apoi îți pregătesc răspunsul dacă Apple respinge. Parcursul complet e pe pagina publicarea unei aplicații în App Store.
Dacă îți pregătești prima lansare, fă-ți diagnosticul gratuit: îți pune pașii în ordine și îți trimite checklist-ul meu anti-respingere Apple.
Întrebări frecvente
Cât durează lansarea treptată în App Store?
Șapte zile: 1% dintre utilizatorii cu actualizări automate în prima zi, apoi 2, 5, 10, 20 și 50%, și 100% în a șaptea. O poți pune pe pauză până la 30 de zile în total sau o poți termina oricând cu Release to All Users.
O actualizare de aplicație iOS trece din nou prin review-ul Apple?
Da. Fiecare versiune nouă, cu build-ul și metadatele ei, trece prin App Review. Textul promoțional și setările de lansare, în schimb, se modifică fără o nouă trimitere.
Poți reveni la versiunea veche a unei aplicații în App Store?
Nu. Trebuie să creezi o versiune nouă, cu corectura, și s-o trimiți la review. De asta sunt utile lansarea treptată și pauza ei.
Utilizatorii noi primesc actualizarea în timpul lansării treptate?
Da, dacă descarcă aplicația din App Store. Lansarea treptată reglează doar actualizările automate: oricine poate descărca noua versiune oricând.
Poți activa lansarea treptată după aprobarea Apple?
Da, cât timp versiunea are statusul Pending Developer Release, adică e pe lansare manuală și încă nepublicată. După ce versiunea a ieșit, e prea târziu pentru ea.
Ce pui în notele de versiune ale unei actualizări?
Funcțiile noi și schimbările importante, listate clar: asta cere regula 2.3.12. Pentru o simplă corectură de bug-uri, de securitate sau de performanță, o formulare generală e suficientă. Câmpul acceptă 4.000 de caractere și se traduce în fiecare limbă.

