{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"preview": {
"distribution": "internal"
},
"production": {
"ios": {
"simulator": false
}
}
},
"submit": {
"production": {}
}
}Dacă ai de lansat prima ta aplicație în App Store în 2026, vestea bună e că nu mai trebuie să-ți prinzi urechile în Keychain-ul de pe macOS ca pe vremuri. Am trecut recent prin asta cu un proiect pe care l-am ridicat de la zero pentru un client și am configurat tot fluxul de EAS Build în sub 40 de minute.
Hai să-ți arăt cum să lași Expo să facă toată treaba murdară cu certificatele Apple, fără să pierzi nopțile și fără să te lovești de erori criptice de code signing.
Configurația de bază în eas.json
Înainte de orice comandă în terminal, ai nevoie de un fișier eas.json curat în rădăcina proiectului. Nu te complica cu zeci de flag-uri inutile din prima. Pentru producție, ai nevoie doar de un profil de production simplu.
Odată ce ai structura asta pregătită, asigură-te că ești logat în CLI-ul Expo folosind eas login.
Magia din spatele credențialelor automate
Aici e unde mulți developeri la început de drum se blochează pentru că nu înțeleg ce face Expo în spate. Când rulezi comanda de build, CLI-ul te va întreba cum vrei să gestionezi credențialele:
eas build --platform ios --profile production
Alege întotdeauna varianta automată (Let Expo handle your credentials). EAS se va conecta securizat la contul tău de Apple Developer (da, ai nevoie de abonamentul de 99$/an) și va genera singur:
- Un Distribution Certificate nou (dacă nu ai deja unul valid).
- Un App ID explicit în portalul Apple, folosind bundle identifier-ul tău.
- Un Provisioning Profile asociat.
Am pățit la un proiect cu peste 8.000 de utilizatori activi să ne expire certificatul vechi, cel generat manual de fostul dev. Când am trecut pe EAS auto-manage, la următorul build, sistemul a detectat problema, a revocat certificatul expirat și a generat unul nou complet transparent. Am economisit cel puțin 3-4 ore de debug și transpirații reci.
Trade-off-ul sincer: Când NU funcționează auto-manage
Să fim realiști, managementul automat nu e un glonț de argint. Funcționează impecabil doar dacă ai rol de Account Holder sau Admin în echipa de Apple Developer.
Dacă lucrezi ca freelancer sau contractor pentru o companie mare, iar departamentul lor de IT îți oferă doar acces de tip "Developer", EAS nu va putea genera profilele și certificatele de distribuție în locul tău. În scenariul ăsta, ești blocat. Va trebui să le ceri lor să genereze manual fișierele .p12 și profilele de provisioning, pe care apoi le urci manual în Expo folosind eas credentials. E un proces greoi, plin de pași birocratici. Sfatul meu? Negociază accesul de Admin temporar încă din faza de ofertare.
Trimiterea directă în TestFlight
După ce build-ul s-a terminat cu succes în cloud-ul Expo (ceea ce îți salvează resursele locale și timp prețios), trimiterea în magazin se face extrem de simplu:
eas submit --platform ios --profile production
Pentru a evita problemele cu autentificarea în doi pași (2FA) de la Apple, nu folosi parola ta personală în CLI. Mergi în App Store Connect, generează o cheie API (App Store Connect API Key) și oferă-i acea cheie lui EAS. Este mult mai stabilă, nu expiră la fel de repede și rulează perfect în pipeline-urile de CI/CD.
Voi cum vă gestionați acum release-urile de iOS? Tot prin Xcode-ul local sau ați trecut complet pe build-uri în cloud?