{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"production": {
"ios": {
"simulator": false
},
"distribution": "store"
}
}
}Salutare! Dacă urmează să scoți prima ta aplicație Expo pe App Store în 2026, am o veste excelentă pentru tine: s-au dus vremurile când trebuia să-ți prinzi urechile în Keychain Access pe macOS ca să generezi manual certificate de distribuție. Săptămâna trecută am urcat în store o aplicație de mobil pentru un client cu peste 10.000 de utilizatori activi și am lăsat totul pe seama EAS (Expo Application Services). Mi-a salvat cel puțin trei ore de muncă și mulți nervi.
Mai țineți minte cum era acum câțiva ani? Generai acel CSR local, îl urcai în Apple Developer, descărcai certificatul, îl importai în Keychain, generai profile de provisioning și tot așa. Cu EAS Build și opțiunea lor de auto-manage, Expo face toată treaba asta în locul tău prin intermediul API-urilor oficiale de la Apple.
Trade-off-ul sincer pe care trebuie să-l accepți
Da, este incredibil de comod. Dar chestia asta vine la pachet cu un compromis major pe care puțini îl menționează direct: lași cheile împărăției (certificatul de distribuție și cheia privată asociată) în serverele Expo.
Pentru 95% dintre startup-uri și clienți medii, este un trade-off pe care îl accepți bucuros ca să livrezi rapid. Dacă lucrezi însă în banking, fintech sau pentru un client enterprise ultra-strict cu securitatea, probabil politica companiei te va obliga să generezi manual aceste credențiale și să le stochezi într-un seif digital propriu. Pentru restul lumii, auto-manage-ul de la Expo este absolut sfânt.
Pașii exacți pentru configurare
În primul rând, ai nevoie de un cont de Apple Developer activ. Da, taxa de 99 de dolari pe an este încă vie și nevătămată.
După ce ai contul pregătit, instalezi CLI-ul EAS și te loghezi în contul tău Expo. Deschizi terminalul în rădăcina proiectului și rulezi configurarea inițială:
eas build:configure
Această comandă îți va genera un fișier eas.json în proiect. Asigură-te că profilul de producție are setat distribution: "store", exact ca în exemplul de configurare atașat.
Pasul critic vine când pornești primul build de iOS:
eas build --platform ios --profile production
În acest moment, CLI-ul te va întreba politicos: "Do you want Expo to handle your credentials?". Răspunzi cu un "Yes" hotărât. CLI-ul îți va cere să te autentifici în contul tău de Apple Developer. Recomand să folosești un App-Specific Password generat din contul tău Apple ca să nu ai probleme cu autentificarea în doi pași în timpul build-ului.
EAS va genera automat certificatul de distribuție, identificatorul aplicației (Bundle ID) și profilele de provisioning direct în portalul tău Apple Developer. Fără ca tu să deschizi măcar o dată browserul.
Capcana de care m-am lovit și cum o eviți
Am pățit o chestie destul de enervantă la un proiect trecut: dacă ai servicii speciale active, cum ar fi Push Notifications sau Sign in with Apple, trebuie neapărat să le ai declarate în app.json sub cheia ios.entitlements înainte să rulezi build-ul.
Dacă rulezi build-ul fără ele, EAS va genera un profil de provisioning simplu. Dacă adaugi serviciile mai târziu, va trebui să rulezi manual eas credentials în terminal ca să cureți credențialele vechi și să forțezi EAS să genereze un profil nou care să includă noile capabilități. Altfel, aplicația va crăpa la pornire în TestFlight când încearcă să inițializeze notificările.
După ce build-ul s-a terminat cu succes în cloud-ul Expo, trimiți aplicația direct în TestFlight cu o singură comandă: eas submit --platform ios. În total, mi-a luat cam 20 de minute de când am dat prima comandă în terminal până când build-ul a apărut la procesat în App Store Connect.
Voi mai folosiți generarea manuală de certificate în vreun scenariu specific, sau ați trecut toți pe EAS auto-manage?