{
"cli": {
"version": ">= 9.0.0"
},
"build": {
"production": {
"ios": {
"distribution": "store"
}
}
}
}Am lansat recent primul proiect pe 2026 în App Store folosind noul workflow de la Expo EAS și pot să spun că mizeria aia de 'nu se potrivește bundle identifier-ul cu profilul de provizionare' e istorie. Dacă ai trecut prin chinul manual de acum câțiva ani cu Keychain Access, certificate descărcate și adăugate manual în Xcode, știi exact despre ce vorbesc. Am pățit asta la un proiect cu vreo 15k useri activi unde am pierdut o zi întreagă doar ca să reînnoiesc un certificat expirat.
Cu EAS Build și managementul automat de certificate de la Expo, totul durează acum sub 15 minute. Dar sunt câteva chestii ascunse unde te poți bloca ușor, mai ales la prima configurare.
Chestia cu cheia API de la Apple (Trade-off-ul crucial)
Ca EAS să facă magie în locul tău, are nevoie de acces în contul tău de Apple Developer. Ai două variante: te loghezi interactiv cu contul tău Apple în terminal sau generezi o cheie API (App Store Connect API Key).
Recomandarea mea e să mergi direct pe varianta cu App Store Connect API Key. De ce? Autentificarea interactivă prin 2FA expiră repede și îți va crăpa build-ul în CI/CD când ți-e lumea mai dragă. Cheia API o generezi o singură dată din portalul Apple Developer (secțiunea Users and Access -> Integrations) cu rolul de Admin sau App Manager. O pui în EAS și ai scăpat de griji.
Trade-off-ul? Dacă cineva îți fură cheia aia, are acces să îți configureze toate aplicațiile din cont, deci ai grijă unde o stochezi. EAS o ține criptată la ei pe servere, ceea ce e destul de sigur pentru majoritatea proiectelor.
Pasul 1: Configurează eas.json
Înainte să rulezi orice comandă în terminal, asigură-te că fișierul tău eas.json are profilurile configurate corect pentru producție. Ai nevoie de proprietatea distribution: "store" ca EAS să știe că vrei un build semnat pentru producție, nu pentru testare internă (AdHoc).
Pasul 2: Comanda de build și auto-provisioning
După ce ai configurat fișierul, deschizi terminalul și rulezi comanda de build. Expo te va întreba politicos dacă vrei ca ei să se ocupe de certificate. Răspunzi cu 'Yes' la tot.
În spate, EAS va face următoarele chestii în mod complet automat:
- Va verifica dacă bundle identifier-ul tău există deja în App Store Connect. Dacă nu, îl va crea automat.
- Va genera o cheie de semnare nouă (Distribution Certificate) și o va salva securizat în serverele lor.
- Va crea un Provisioning Profile asociat cu bundle identifier-ul tău.
Cât te costă de fapt?
EAS Build are un free tier destul de generos, dar ai un mare dezavantaj: cozile de așteptare. La orele de vârf (după-amiază în Europa, când se trezesc și americanii), poți să aștepți și 40 de minute doar ca să îți intre build-ul în execuție.
Pentru un proiect comercial, abonamentul lor de 29$ pe lună (sau varianta pay-as-you-go) merită fiecare cent. Personal, am economisit cel puțin 4-5 ore de build blocat pe lună de când am trecut pe planul plătit.
După ce build-ul e gata, rulezi simplu eas submit --platform ios și build-ul pleacă direct în TestFlight. Fără Xcode deschis, fără erori ciudate de arhivare.
Voi cum faceți build-urile de iOS acum? Tot pe mașina locală cu Xcode sau ați trecut complet pe EAS în cloud?