Cum am scăpat de coșmarul certificatelor iOS cu Expo EAS Build la prima lansare

Adrian Voicu · 2026-08-15T09:43:27.929Z

Ghid direct la țintă pentru prima lansare pe App Store folosind Expo EAS Build și auto-managed credentials, fără să deschizi Xcode sau Keychain Access.

Postat acum 1 zi

json

{
  "cli": {
    "version": ">= 12.0.0"
  },
  "build": {
    "production": {
      "autoIncrement": true,
      "ios": {
        "simulator": false
      }
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "dev@firma-ta.ro",
        "ascApiKeyPath": "./credentials/AuthKey_ABC123.p8",
        "ascApiKeyId": "ABC123XYZ",
        "ascApiKeyIssuerId": "12345678-abcd-1234-abcd-1234567890ab"
      }
    }
  }
}

Dacă ai lansat vreodată o aplicație iOS acum câțiva ani, știi trauma: Keychain Access bușit, certificate de distribuție expirate, provisioning profiles invalide și ore pierdute prin Xcode. Când am pregătit primul release pentru un client cu vreo 12k utilizatori activi pe React Native, am lăsat EAS (Expo Application Services) să se ocupe complet de certificate și am redus timpul de setup de la o zi întreagă la vreo 20 de minute.

1. Pregătirea contului de Apple Developer

Înainte să dai orice comandă în terminal, ai nevoie de contul de Apple Developer plătit (cei 99$/an). Cel mai curat mod de a lăsa EAS să gestioneze certificatele fără să-ți ceară 2FA la fiecare build este să generezi un App Store Connect API Key:

Mergi în App Store Connect -> Users and Access -> tab-ul Integrations (sau Keys).
Generezi o cheie nouă cu rol de Admin sau App Manager.
Descarci fișierul .p8 (atenție, Apple te lasă să-l descarci o singură dată) și notezi Key ID și Issuer ID.

Când rulezi prima dată eas build --platform ios, CLI-ul te va întreba cum vrei să te autentifici. Selectezi varianta cu API Key, îi dai fișierul descărcat și ai terminat. EAS își creează singur Distribution Certificate și Provisioning Profile în fundal.

2. Configurația din eas.json

Nu te complica cu zeci de flag-uri din prima. Ai nevoie doar de un profil de producție bine pus la punct și de configurarea pentru auto-submit dacă vrei ca build-ul să plece direct în TestFlight fără intervenție manuală.

Asigură-te că în app.json ai setat un bundleIdentifier unic (ex: ro.eduardweb.myapp) înainte de primul build, altfel EAS va genera erori la înregistrarea Bundle ID-ului în portalul Apple.

3. Lansarea build-ului și trimiterea în TestFlight

Comanda magică este:

eas build --platform ios --profile production --auto-submit

Ce se întâmplă în spate:

EAS verifică dacă Bundle ID-ul există; dacă nu, îl creează prin API Key.
Generează certificatul de distribuție și îl stochează criptat pe serverele Expo.
Compilează proiectul pe mașinile lor din cloud.
Trimite binarul (.ipa) direct în App Store Connect via Transporter.

După ce build-ul e gata (durează cam 12-18 minute pe planul gratuit), mai aștepți vreo 10-15 minute până când Apple termină procesarea internă. Apoi binarul apare în TestFlight gata de testat sau trimis la review.

Trade-off sincer: EAS Cloud vs Local

EAS auto-manage e genial pentru 95% din cazuri, dar are și limitări:

Timpul de așteptare: Pe free tier prinzi cozi mari la ore de vârf (am stat și 45 de minute la coadă doar să înceapă build-ul). Dacă ai un Mac cu procesor M2 sau M3 la îndemână, un build local via eas build --platform ios --local durează doar 3-4 minute și folosește aceleași certificate descărcate automat de CLI.
Vendor lock-in parțial: Dacă vrei să muți proiectul pe un CI clasic (GitHub Actions cu Fastlane) mai târziu, va trebui să exporți manual certificatele folosind comanda eas credentials.

Voi mai țineți provisioning profiles manual prin Fastlane/Match sau ați trecut complet pe soluțiile cloud managed?