{
"cli": {
"version": ">= 10.0.0"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"production": {
"autoIncrement": true,
"ios": {
"simulator": false
}
}
},
"submit": {
"production": {
"ios": {
"appleId": "dev@domeniu.ro",
"ascAppId": "6471234567",
"appleTeamId": "A123B456CD"
}
}
}
}Am trecut recent un proiect React Native cu vreo 12k useri activi de la build-uri locale în Xcode la Expo EAS. Dacă ai lansat vreodată o aplicație iOS clasică, știi trauma: provisioning profiles expirate, certificate de distribuție încurcate pe Mac-ul colegului și erori criptice la upload. Cu EAS Credential Management, tot procesul e atât de curat încât parcurgi lansarea direct din terminal în sub 30 de minute.
Setup-ul minim în eas.json
Înainte să dai vreo comandă de build, ai nevoie de un fișier eas.json structurat corect în rădăcina proiectului. Nu te complica cu zeci de flag-uri din prima. Îți trebuie o configurare simplă pentru profilul de production și setările de submit automat.
Aici specifici opțiunea de autoIncrement pentru build number (esențial ca să nu-ți respingă Apple upload-ul) și datele de identificare pentru App Store Connect.
Magia auto-manage: Cum funcționează în spate
Când rulezi prima dată eas build --platform ios --profile production, CLI-ul detectează că nu ai certificate generate. Răspunzi cu Y la prompt-ul de autentificare în contul de Apple Developer, iar de acolo EAS preia controlul complet:
- Generează un Distribution Certificate direct pe Apple Developer Portal.
- Creează un App ID unic dacă nu există deja.
- Generează și asociază un Provisioning Profile cu capabilitățile exacte din
app.json.
Am economisit lejer 3-4 ore de configurări manuale la prima lansare pentru că n-a trebuit să export chei .p12 sau să-mi bat capul cu Bundle Identifier-ul în portalul Apple. Expo salvează totul criptat în cloud-ul lor.
Trade-off sincer: Auto-manage e un vis dacă ești solo dev sau lucrezi într-o echipă mică unde vreți viteză. În schimb, dacă ești într-o corporație unde departamentul de securitate interzice stocarea cheilor private de producție pe servere terțe, opțiunea asta cade. Va trebui să generezi certificatele manual și să le imporți prin eas credentials folosind un Vault intern.
Submit direct în TestFlight fără Transporter
După ce build-ul remote s-a terminat pe serverele Expo (durează cam 12-15 minute pentru un proiect mediu), nu mai descarci arhiva .ipa ca să o urci manual. Rulezi direct eas submit -p ios --latest.
Un aspect critic: Apple cere verificare strictă pe Privacy Manifests și SDK-urile terțe folosite (de exemplu Stripe sau Firebase). Dacă folosești un Expo SDK recent, aceste configurări se injectează automat prin Config Plugins la build-ul remote, fără să atingi fișiere native .plist.
Dacă ai pus ascAppId și appleTeamId în eas.json, pachetul ajunge direct în TestFlight. Primești un email de la Apple în 5 minute că build-ul este gata de procesare.
O chestie mică de care m-am lovit
Dacă ai Push Notifications activate în proiect, asigură-te că lasi EAS să-ți genereze și cheia APNs (.p8). CLI-ul te întreabă de asta separat. Dacă dai vedetă și sari peste pas, aplicația se va compila, dar notificările vor crapa silențios în producție și va trebui să dai alt build.
Voi cum publicați pe iOS? Mai folosiți Xcode local cu scripturi de Fastlane sau ați trecut complet pe pipeline-uri cloud?