{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"production": {
"ios": {
"simulator": false
},
"distribution": "store"
}
}
}Am publicat luna trecută o aplicație de ride-sharing pentru o flotă locală, un proiect cu în jur de 1.200 de utilizatori activi în prima săptămână. În loc să pierd două zile cu Xcode, Mac-uri virtuale și certificate descărcate manual, am lăsat totul în seama Expo EAS. Dacă ai primul tău release pe iOS în 2026, ghidul ăsta îți salvează cel puțin o zi de înjurături.
Setup-ul minim în eas.json
Nu ai nevoie de un Mac local ca să faci build-ul. Asta e cea mai mare economie de timp pe care am experimentat-o – am redus timpul de livrare cu vreo 40% nefiind blocat de resursele mașinii locale. Ai nevoie doar de un cont Apple Developer activ (da, ăla de 99$/an) și un terminal.
Înainte de a rula orice comandă, asigură-te că fișierul tău eas.json are profilul de producție configurat corect. Am văzut mulți devși care se încurcă aici și trimit build-uri de tip ad-hoc în loc de cele destinate magazinului oficial. Vezi în codul de mai jos cum trebuie să arate structura de bază.
Cum funcționează magia din spatele auto-manage
Când rulezi comanda de build, EAS te întreabă politicos dacă vrei ca Expo să se ocupe de credențiale. Răspunsul tău ar trebui să fie un „Da” hotărât.
Ce se întâmplă în spate? Expo folosește un App Store Connect API Key pe care îl generezi o singură dată din portalul Apple Developer. Cu cheia asta, scripturile lor automate creează un Distribution Certificate, un App ID unic pentru aplicația ta și un Provisioning Profile corect. Totul în mai puțin de două minute.
Am avut un proiect mai vechi cu peste 8.000 de utilizatori unde a trebuit să facem update-uri rapide în producție. Faptul că certificatul era gestionat în cloud ne-a permis să facem deployment de pe orice laptop, direct din terminalul unui coleg aflat în concediu, fără să exportăm chei private din Keychain Access.
Trade-off-ul de care nu-și spune nimeni
Sună perfect, dar există și o parte mai puțin plăcută pe care trebuie să o asumi. Auto-manage-ul celor de la Expo merge brici pentru echipe mici, startup-uri sau developeri independenți.
Dacă lucrezi într-o corporație mare, cu reguli stricte de securitate, departamentul de IT nu o să-ți dea niciodată acces la App Store Connect API cu drepturi de admin pentru a genera chei. În scenariul ăla, ești pe cont propriu. Va trebui să generezi manual fișierele .p12 și profilele de provizionare, iar apoi să le uploadezi în EAS folosind eas credentials. E un proces anevoios care te întoarce fix în era configurărilor manuale.
Pașii exacți pentru lansare
Dacă ai acces complet la contul Apple, urmează pașii ăștia simpli:
- Instalează CLI-ul rulând
npm install -g eas-cli. - Loghează-te în contul tău:
eas login. - Inițializează proiectul cu
eas build:configure. - Generează o cheie API în Apple Developer Portal (la secțiunea Users and Access -> Keys) și oferă-i acces de Admin sau App Manager. Descarcă fișierul
.p8. - Rulează comanda de build:
eas build --platform ios --profile production.
EAS îți va cere fișierul .p8, Key ID-ul și Issuer ID-ul. Odată introduse, le va salva securizat în serverele lor și nu te va mai întreba de ele la build-urile viitoare. La final, vei primi un fișier .ipa gata de urcat în TestFlight.
Voi cum faceți acum build-urile de iOS? Tot pe Mac-ul local cu Xcode deschis și ventilatoarele la maxim, sau ați trecut complet pe cloud-ul celor de la Expo?