{
"cli": {
"version": ">= 7.0.0"
},
"build": {
"production": {
"ios": {
"simulator": false,
"enterpriseProvisioning": "adhoc"
},
"autoIncrement": true
}
},
"submit": {
"production": {
"ios": {
"appleId": "dev@firma.ro",
"ascAppId": "6471234567",
"appleTeamId": "ABCDE12345"
}
}
}
}Dacă ai prins timpurile când trebuia să exporți manual fișiere .p12, să creezi Provisioning Profiles în Apple Developer Console și să te rogi să nu expire în mijlocul unui release, știi despre ce vorbesc. Luna trecută am lansat un MVP de e-commerce pentru un client, iar cu Expo EAS Auto-Manage am economisit lejer vreo 4 ore de configurații inutile. Îți arăt exact ce pași trebuie să urmezi pentru a trece de prima lansare pe App Store fără dureri de cap.
Practic, Expo se ocupă de generarea, stocarea și reînnoirea tuturor certificatelor de iOS direct în cloud-ul lor securizat. Tot ce-ți trebuie e un cont plătit de Apple Developer (ăia 99$/an de la care nu poți scăpa) și câteva comenzi în terminal.
Pregătirea terenului în eas.json
Primul pas e să te asiguri că ai configurat eas.json corect în rădăcina proiectului. Ai nevoie de un profil de production stabilit clar, dar și de o secțiune de submit pentru a automatiza încărcarea în App Store Connect. Când rulezi comanda de build pentru producție, CLI-ul te va întreba dacă vrei ca Expo să gestioneze toate credențialele. Răspunsul este un „DA” categoric, mai ales dacă ești la prima lansare.
Autentificarea cu Apple și generarea automată
Regula de aur: nu mai folosi parole sau 2FA cu număr de telefon în CLI pe termen lung. Cel mai curat este să generezi o cheie API App Store Connect direct din portalul Apple Developer (secțiunea Users and Access -> Integrations).
Când rulezi eas build --platform ios --profile production, CLI-ul îți va cere cheia API sau te va pune să te autentifici în contul Apple. EAS va comunica direct cu API-ul Apple, va crea un Distribution Certificate și un Provisioning Profile specific pentru App Bundle ID-ul tău (com.firma.app). Dacă procesul eșuează din prima, în 90% din cazuri e pentru că Bundle ID-ul nu este înregistrat sau nu ai acceptat ultimele acorduri legale din contul Apple Developer.
Trade-off-ul sincer: Confort vs. Control
Să fim sinceri. Magia din spatele EAS Auto-Manage e genială când lucrezi singur sau în echipe mici. Am lansat 3 aplicații anul trecut fără să deschid Xcode măcar o dată pentru management de certificate.
Traseul ăsta are însă un dezavantaj evident. Dacă echipa ta crește și ai un departament separat de Security/DevOps care vrea acces strict la cheile private, stocarea lor în cloud-ul Expo s-ar putea să nu treacă de audit. În plus, dacă pierzi accesul la contul Expo fără să fi făcut export la credențiale cu eas credentials, e mai complicat să revoci certificatele existente. Pentru 95% dintre proiecte însă, riscul merită din plin economisia de timp.
Trimiterea automată în TestFlight cu eas submit
După ce build-ul e gata (durează cam 12-15 minute pe runnerii lor gratuiți sau sub 5 minute pe un plan plătit), poți trimite binary-ul .ipa direct în TestFlight fără să îl descarci local. Rulezi doar eas submit -p ios --latest sau configurezi flag-ul --auto-submit direct în comanda de build.
Aplicația va apărea în App Store Connect la secțiunea TestFlight în câteva minute, imediat ce Apple termină procesarea internă. De acolo mai ai doar de completat chestionarul de confidențialitate și screenshot-urile.
Voi cum procedați la proiectele noi de React Native? Mergeți pe EAS direct sau încă mai faceți build-uri locale pe Mac-urile din birou?