{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"preview": {
"distribution": "internal"
},
"production": {
"ios": {
"simulator": false
},
"distribution": "store"
}
}
}Cine a prins vremurile când generai manual CSR-uri în Keychain Access pe macOS și le urcai cu emoții în Apple Developer Portal știe exact ce durere de cap era fiecare release. În 2026, cu Expo EAS (Expo Application Services), treaba asta a devenit aproape complet invizibilă. Totuși, dacă ești la prima lansare, există câteva detalii stupide unde tot proiectul se poate bloca.
Luna trecută am avut de livrat rapid un MVP pentru un startup din zona de food delivery, cu un target de vreo 2.000 de utilizatori în prima fază. Termenul era strâns și nu aveam chef să pierd o zi întreagă configurând Xcode pe laptopul clientului sau făcând debugging pe scheme de build. Am mers 100% pe EAS Build cu auto-managed credentials și am salvat cel puțin 4-5 ore de muncă brută.
1. Condiția eliminatorie: Drepturile pe contul Apple
Înainte să rulezi orice comandă în terminal, ai nevoie de un cont de Apple Developer activ (taxa aceea simpatică de 99 USD/an). Dar marea capcană în care cad mulți e rolul din echipă.
Dacă ești adăugat pe contul clientului doar ca „Developer”, EAS Build o să crape direct când încearcă să genereze profilele de provizionare. Ai nevoie de rolul de Account Holder sau Admin, iar în secțiunea Users and Access trebuie să ai bifată opțiunea "Access to Certificates, Identifiers & Profiles". Fără asta, nu are rost să pornești terminalul.
2. Configurația eas.json simplificată
În rădăcina proiectului tău ai nevoie de un fișier eas.json. Am păstrat lucrurile cât mai simple, definind clar profilul de producție și cel de preview pentru testarea internă prin TestFlight. Codul de configurare îl găsești atașat mai jos. Am setat distribution pe store pentru profilul de producție, ceea ce îi spune lui EAS că build-ul final va merge direct spre Apple.
3. Comanda magică și workflow-ul de generare
După ce ai instalat EAS CLI global (npm install -g eas-cli) și te-ai logat în contul de Expo (eas login), rulezi comanda:
eas build --platform ios --profile production
Acesta este momentul în care CLI-ul te va întreba: "Do you want Expo to handle your credentials?". Apeși Y (Yes) fără să clipești.
Ce se întâmplă în spate în următoarele 2 minute:
- Expo te va pune să te loghezi în contul tău Apple în terminal. Recomand să folosești un App-Specific Password dacă ai 2FA activat.
- Creează automat un Bundle Identifier unic în contul tău Apple (dacă nu exista deja).
- Generează o cheie de distribuție (iOS Distribution Certificate).
- Generează un Provisioning Profile dedicat pentru build-ul de producție.
Totul se salvează securizat în serverele Expo. Dacă peste un an îți schimbi laptopul, nu trebuie să muți nicio cheie privată dintr-o parte în alta.
Trade-off-uri sincere: De ce nu e totul perfect?
Setup-ul ăsta este genial pentru 90% din aplicații, dar are și limitări de care m-am lovit pe alte proiecte:
- Extensii custom de iOS: Dacă ai nevoie de chestii foarte specifice de sistem, cum ar fi un widget complex sau Siri Shortcuts care cer App Groups și profile de provizionare separate, EAS auto-managed s-ar putea să se încurce. În cazul ăla, trebuie să treci pe credențiale manuale.
- Cozi de așteptare: Pe planul gratuit de la Expo, în zilele aglomerate de marți sau joi, poți sta și 30 de minute la coadă doar ca să înceapă build-ul în cloud. Pentru MVP-ul meu a fost ok, dar la proiecte mari cu CI/CD zilnic, abonamentul lor plătit devine obligatoriu.
După ce build-ul s-a terminat cu succes în cloud-ul Expo, poți folosi eas submit --platform ios ca să trimiți binarul direct în App Store Connect, gata pentru TestFlight.
Voi cum mai gestionați certificatele de iOS în ultima vreme? Tot prin Fastlane configurat manual sau ați trecut complet pe soluții managed în cloud?