{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"production": {
"ios": {
"simulator": false,
"distribution": "store"
}
}
}
}Am lansat recent un MVP pentru un client din zona de retail, estimat la vreo 12k useri activi din prima zi. Pe vremuri, acum vreo 5-6 ani, faza de code signing pentru iOS îmi mânca cel puțin o zi de muncă și jumătate de pachet de țigări. În 2026, cu Expo EAS Build și modul lor auto-managed, am rezolvat totul în fix 15 minute. Totuși, sunt câteva detalii unde poți să te blochezi urât dacă nu ești atent.
Cerința obligatorie: Rolul tău în Apple Developer
Înainte să dai orice comandă în terminal, ai nevoie de două lucruri: un cont Apple Developer activ (ăla de 99$ pe an) și acces de Administrator în App Store Connect.
Am pățit asta la un proiect anul trecut: eram adăugat în echipa clientului doar ca „Developer”. Când am rulat build-ul, EAS s-a blocat pentru că Apple nu permite conturilor fără rol de Admin să genereze profile de provizionare sau certificate de distribuție prin API. A trebuit să aștept trei zile după client să-mi schimbe permisiunile. Asigură-te că ai rolul corect înainte de a începe.
Configurația din eas.json
Nu te complica să configurezi manual Xcode sau să descarci fișiere .p12. Expo se ocupă de tot prin fișierul de configurare. Ai nevoie de un profil de producție în eas.json care să specifice clar că vrei un build pentru store.
Odată ce ai fișierul configurat ca în exemplul alăturat, tot ce trebuie să faci este să rulezi comanda de build în terminal.
Comanda magică și flow-ul de terminal
Deschide terminalul și rulează comanda de build dedicată pentru iOS:
eas build --platform ios --profile production
Prima dată când rulezi asta, CLI-ul te va întreba politicos: „Do you want Expo to handle your credentials?”. Răspunzi cu un „Yes” hotărât.
Expo se va conecta securizat la contul tău de Apple, îți va cere autentificarea în doi pași (ține iPhone-ul aproape pentru codul de validare) și va genera automat tot ce este necesar în cloud: distribuția de producție, Bundle Identifier-ul și Push Notification Key dacă ai notificări active în proiect.
Trade-off-ul de care nu vorbește nimeni
Deși procesul pare desprins din povești, există un compromis major pe care trebuie să-l înțelegi.
Cât timp lași Expo să-ți gestioneze certificatele, cheia ta privată de distribuție este stocată pe serverele lor. Pentru developeri solo, startup-uri sau agenții mici, este un trade-off pe care îl accepți bucuros ca să salvezi timp. Totuși, dacă lucrezi pentru o bancă sau o corporație cu politici stricte de securitate, acest lucru este complet interzis. Ei vor dori ca cheia privată să nu părăsească niciodată infrastructura internă, caz în care va trebui să configurezi certificatele manual și să le uploadezi în EAS sub formă de variabile criptate.
Pentru majoritatea dintre noi, varianta auto-managed este absolut genială și stabilă. Voi cum faceți? Tot pe manual mergeți de frica securității sau ați lăsat frâiele în mâna celor de la Expo?