{
"cli": {
"version": ">= 12.0.0",
"appVersionSource": "remote"
},
"build": {
"production": {
"autoIncrement": true,
"ios": {
"simulator": false,
"image": "latest"
}
}
},
"submit": {
"production": {
"ios": {
"appleId": "dev@firma.ro",
"ascAppId": "6471234567"
}
}
}
}Dacă ai publicat vreodată o aplicație iOS prin metoda clasică acum câțiva ani, știi trauma: Keychain Access corupt, Distribution Certificates descărcate manual și Provisioning Profiles care expirau fix când aveai deploy urgent. Cu Expo EAS Build și sistemul de credentials auto-managed, am scos un build de producție pentru un client în fix 18 minute, fără să deschid Xcode măcar o dată.
Secretul nu e vreo magie neagră, ci faptul că lași Expo să comunice direct cu App Store Connect API. Iată pașii exacți și unde te poți împiedica la prima lansare.
1. Pregătirea contului de Apple Developer
Înainte să dai orice comandă în terminal, ai nevoie de un cont plătit de Apple Developer (clasicul abonament de 99$/an). Nu te mai autentifica în CLI cu utilizator, parolă și 2FA prin SMS — e o metodă fragilă care pică frecvent în CI/CD.
Intră în App Store Connect -> Users and Access -> Integrations -> App Store Connect API și generează o cheie nouă cu rol de Admin sau App Manager. Descarcă fișierul .p8 (atenție, Apple te lasă să-l descarci o singură dată) și notează-ți Key ID-ul și Issuer ID-ul. Când rulezi eas credentials, selectezi opțiunea de a folosi acest API Key. EAS îl va stoca securizat și nu vei mai avea treabă cu 2FA niciodată.
2. Configurația din app.json și eas.json
În app.json, asigură-te că ai setat ios.bundleIdentifier corect (format com.companie.numeapp). Bundle ID-ul ăsta este unic și definitiv; dacă îl greșești acum, va trebui să recreezi toată aplicația în App Store Connect.
În eas.json, profilul de producție trebuie configurat simplu. Dacă folosești autoIncrement pe buildNumber, EAS va incrementa versiunea internă automat la fiecare build, scăpând de respingerile de la Apple pentru duplicate build version.
3. Comanda de build și generarea automată
Rulezi comanda din terminal:
eas build --platform ios --profile production
La prima rulare, CLI-ul te va întreba politicos: "Do you want Expo to handle your Apple credentials?". Alegi Yes.
Ce se întâmplă în spate în următoarele 60 de secunde:
- EAS verifică dacă Bundle ID-ul există în contul tău Apple. Dacă nu, îl creează automat.
- Generează un Apple Distribution Certificate nou și îi salvează cheia privată în seiful Expo.
- Creează un App Store Provisioning Profile legat de noul certificat și de bundle identifier.
- Trimite codul tău către o mașină virtuală macOS din cloud-ul Expo pentru compilare.
La ultimul proiect cu vreo 11k useri activi, timpul total de build pe serverele M-series de la Expo a fost de ~12 minute. Odată finalizat, poți trimite binarul direct în TestFlight cu comanda eas submit --platform ios --profile production.
Trade-off-uri reale: când NU merge auto-managed
Ca să fim sinceri, sistemul e impecabil pentru 90% din aplicații, dar are limitările lui:
- Merge brici pentru: aplicații standard React Native, echipe unde nu toți developerii au Mac, flow-uri de CI/CD automate.
- Devine nasol când: ai extensii native complexe (de exemplu un Notification Service Extension pentru OneSignal sau WidgetKit). În cazul ăla, EAS se poate încurca la sincronizarea profilelor multiple de provisioning și va trebui să treci pe configurare semi-manuală prin
credentials.json.
Voi mai țineți certificatele manual în fișiere .p12 locale sau ați delegat complet managementul către EAS?