{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"production": {
"ios": {
"simulator": false,
"distribution": "store"
}
}
}
}De ce să lași Expo să se ocupe de certificate?
Să fim sinceri: managementul certificatelor la Apple este un coșmar istoric. Între certificate de distribuție, profile de provizionare și identificatori de bundle, e foarte ușor să-ți prinzi urechile.
Aici intervine EAS (Expo Application Services) cu opțiunea de auto-manage. Trade-off-ul e simplu:
- Avantaj: Scapi complet de chinul de a genera manual fișiere
.p12sau profile în portalul Apple. EAS face totul în fundal, iar build-ul tău e gata direct pentru TestFlight. - Dezavantaj: Trebuie să le oferi celor de la Expo acces la contul tău de Apple Developer prin intermediul unei chei API. Dacă lucrezi într-o companie cu politici de securitate ultra-stricte, s-ar putea ca echipa de SecOps să strâmbe din nas și să te oblige să faci totul manual.
Pentru 95% dintre noi, auto-manage este singura decizie rațională. Am economisit lejer 3 ore de configurări manuale și potențiale erori de Xcode la cel mai recent proiect.
Pașii exacți ca să lansezi în 2026
Nu ai nevoie de un Mac ultra-performant ca să faci asta, pentru că build-ul se rulează în cloud-ul lor. Iată fluxul curat:
-
Instalează CLI-ul și loghează-te: Asigură-te că ai ultima versiune de EAS CLI instalată global și ești logat în contul tău Expo.
-
Configurează
eas.json: Ai nevoie de un profil de producție în rădăcina proiectului tău. Vezi exemplul de cod de mai jos pentru o structură curată. -
Rulează comanda de build: Execută
eas build --platform ios --profile production. -
Magia auto-manage: Terminalul te va întreba cum vrei să gestionezi credențialele. Selectează cu încredere opțiunea în care lași Expo să se ocupe de tot. În 2026, cel mai curat mod este să folosești un App Store Connect API Key (îl generezi în 2 minute din contul de developer Apple la secțiunea Users and Access -> Keys). Îi dai cheia lui EAS și gata. Nu mai ai treabă cu coduri 2FA trimise pe telefon în mijlocul build-ului.
Ce am pățit și cum am rezolvat blocajele
La un proiect recent cu vreo 1.200 de useri în faza de testare, m-am lovit de o eroare dubioasă la generarea certificatului. EAS se plângea că nu poate crea un nou certificat de distribuție. Problema? Clientul mai avusese un developer în trecut care generase deja numărul maxim de certificate de distribuție active permise de Apple pe un cont individual (limita este de 2).
Am intrat frumos în App Store Connect, am revocat un certificat vechi care nu mai era folosit și am rulat comanda din nou. EAS a preluat fluxul automat, a creat noul certificat de care avea nevoie și build-ul a trecut din prima.
După ce build-ul s-a terminat cu succes în cloud, poți folosi eas submit --platform ios ca să trimiți binarul direct în TestFlight.
Voi cum procedați la proiectele voastre? Mergeți pe mâna EAS-ului pentru credențiale sau preferați să le gestionați manual cu Fastlane?