{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"preview": {
"distribution": "internal"
},
"production": {
"ios": {
"simulator": false
}
}
},
"submit": {
"production": {}
}
}Am lansat prima aplicație din 2026 săptămâna trecută. Un proiect mic de e-commerce, pornit complet de la zero. Clientul nu avea nici măcar contul de Apple Developer configurat corect când am început. Dacă ai trecut vreodată prin calvarul manual din Xcode, cu Keychain Access, certificate de distribuție și provisioning profiles descărcate manual doar ca să constați că ai un conflict de semnătură, știi cât de ușor poți pierde o zi întreagă.
Am folosit Expo EAS Build cu management automat al certificatelor. Am scutit cel puțin 3 ore de configurări inutile și telefoane date clientului ca să-mi dea coduri de autentificare în doi pași. Cum se face treaba asta simplu și curat acum, fără dureri de cap:
Setup-ul inițial în App Store Connect
Înainte să atingi terminalul, ai nevoie de o singură chestie de la client sau de pe contul tău: un App Store Connect API Key. Nu mai folosi contul personal de Apple ID pentru autentificare în CLI. Este o metodă învechită și te vei lovi constant de sesiuni expirate și 2FA.
Mergi în App Store Connect -> Users and Access -> Integrations -> App Store Connect API. Generezi o cheie nouă, îi dai un nume (de exemplu, eas-build-key) și rolul de Admin sau App Manager. Descarcă fișierul .p8 (ai grijă, îl poți descărca o singură dată!) și notează-zi Key ID-ul și Issuer ID-ul.
Configurația din terminal
Odată ce ai cheia, totul devine extrem de simplu. Deschizi terminalul în folderul proiectului tău React Native și rulezi comanda de login și inițializare:
npx eas-cli login
eas build:configure
Când rulezi prima dată eas build --platform ios, EAS te va întreba cum vrei să gestionezi acreditările. Selectează cu încredere opțiunea de auto-management. CLI-ul îți va cere cheia API pe care ai descărcat-o mai devreme. O uploadezi în serverele Expo (sunt criptate în siguranță), iar de acolo EAS se ocupă de tot:
- Generează un Distribution Certificate valid.
- Înregistrează Bundle ID-ul în contul tău de developer.
- Creează un Explicit Provisioning Profile pentru build-ul de producție.
La final, ai un build semnat corect, gata de trimis în TestFlight, direct din cloud.
Trade-off-uri de care trebuie să știi
Să fim sinceri: managementul automat este genial pentru 95% dintre aplicații, dar are și limite.
Merge brici pentru aplicații standard. Devine însă problematic dacă ai în plan integrări complexe, cum ar fi widget-uri de iOS custom scrise în Swift, App Groups sau Keychain Sharing avansat. În aceste cazuri, va trebui să scrii config plugins destul de stufoase în app.json pentru ca EAS să genereze corect drepturile (entitlements) la fiecare build.
De asemenea, dacă lucrezi pentru o corporație mare, cu politici stricte de securitate, echipa de infrastructură s-ar putea să refuze să-ți ofere o cheie API cu rol de Admin. În scenariul ăsta, ești blocat pe varianta manuală, unde ei îți generează certificatele, iar tu le încarci manual în EAS folosind eas credentials.
Pentru un startup sau un client mediu? Varianta auto-managed este absolut imbatabilă. Îți las mai jos fișierul de configurare de bază de la care am pornit noi proiectul.
Voi cum mai faceți build-urile de iOS acum? Tot pe flow-ul clasic cu Xcode și fastlane configurat manual, sau ați trecut complet pe EAS în cloud?