eduardweb.
Publicare Play Store & App StoreIntermediar#react-native#expo#eas-build#app-store#ios

Lansarea pe App Store în 2026 cu Expo EAS: Cum am scăpat de calvarul certificatelor Apple

De Răzvan Matei, 31 mai 2026 · 4 vizualizări · 3 like-uri

Postat 31 mai 2026
json
{
  "cli": {
    "version": ">= 5.0.0"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "production": {
      "ios": {
        "simulator": false,
        "enterpriseProvisioning": null
      }
    }
  },
  "submit": {
    "production": {}
  }
}

Am publicat prima mea aplicație pe iOS acum vreo 8 ani. Atunci, să generezi certificate, profile de provizionare și chei de semnare însemna o după-amiază pierdută prin Keychain Access și portalul Apple Developer, plină de erori ciudate. Luna trecută, la un proiect nou cu vreo 12.000 de useri activi, am configurat totul cap-coadă în fix 20 de minute folosind Expo EAS Build cu auto-manage. Dacă ești în 2026 și încă te chinui manual cu fișiere .p12, pierzi timp prețios degeaba.

De ce să lași Expo să facă toată magia?

EAS (Expo Application Services) are o opțiune genială numită credentials auto-management. Practic, îi dai acces temporar la contul tău de Apple Developer prin App Store Connect API, iar el își generează singur tot ce are nevoie: Distribution Certificate, Provisioning Profile și Push Notification keys.

Marele avantaj? Nu mai ai treabă cu mașinile virtuale de macOS pentru build-uri locale și nu mai exporți manual chei private. Rulezi o singură comandă de pe orice sistem de operare, fie el Windows sau Linux, iar build-ul pleacă direct în cloud-ul lor securizat.

Pașii exacți pentru prima lansare

Înainte de toate, ai nevoie de un cont de Apple Developer plătit (da, clasica taxă de 99$ pe an). După ce ai rezolvat asta, procesul e destul de liniar.

Mai întâi, te loghezi în CLI: eas login.

Apoi inițializezi proiectul cu eas build:configure. Asta îți va genera un fișier eas.json în rădăcina proiectului, unde definim profilul de producție.

Când ești gata pentru build-ul final, rulezi comanda de build. Aici începe magia. CLI-ul te va întreba: "Do you want Expo to handle your credentials?". Răspunzi cu un "Yes" hotărât.

Îți va cere să te loghezi în contul Apple. Recomand să folosești un App Store Connect API Key în loc de user și parolă. E mult mai stabil pentru că sesiunile 2FA clasice expiră repede și îți blochează pipeline-ul de CI/CD dacă vrei să automatizezi procesul mai târziu.

Trade-off-ul sincer: Când nu e bun auto-manage?

Să fim realiști, nimic nu e perfect în producție. Abordarea asta complet automată este ideală pentru 95% din startup-uri și proiecte medii. Însă, am avut un caz la un client din zona enterprise, cu un audit de securitate extrem de strict, unde ne-a fost interzis să lăsăm o terță parte să gestioneze cheile de distribuție.

Dacă lucrezi într-o bancă sau corporație unde echipa de securitate vrea să controleze manual fiecare cheie privată și să nu le urce în cloud-ul Expo (chiar dacă sunt criptate), ești blocat. În cazul ăla, trebuie să folosești manual credentials management, ceea ce devine un chin logistic. De asemenea, dacă ai nevoie de push notifications foarte complexe cu extensii de tip Notification Service Extension, setup-ul automat uneori mai dă rateuri și trebuie să bibilești manual profilul în portalul Apple.

Cum preferi să-ți gestionezi cheile de iOS? Mergi pe varianta "set and forget" de la Expo sau încă ai încredere doar în Keychain-ul tău local?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.